Web components do not render scripts collected by the script generator

[adriaon]

Hi,

For web components the scripts collected by the script generator are not rendered. I suppose WANilHtmlRoot should take care of that like this:

WANilHtmlRoot>>#closeOn: aDocument

	aDocument scriptGenerator close: self on: aDocument

Although WAScriptGenerator>>#open:on: (and at JQScriptGenerator) is empty, it is probably nice to call them from WANilHtmlRoot>>#openOn: anyway, like:

WANilHtmlRoot>>#openOn: aDocument

	aDocument scriptGenerator open: self on: aDocument

Cheers,
Adriaan

[marschall]

I am not sure:

The script generator mainly exists for load scripts. Since a web component is inline in the body of the page it does not have have access to the root/head the scripts have to be rendered inline. Also I'm sure we can or should hook into DOMContentLoaded or connectedCallback() whould be more appropriate. Maybe that would be an argument for a custom script generator.

Additionally WANilHtmlRoot would have to be renamed. That's not a reason not to do it, just to mention it.

Are you trying to run jQuery in a WebComponent?

I agree the current situation of components having to be slight different to be WebComponents is no optimal.

[adriaon]

Yes, we are creating a WebComponent that will use jQuery.

But you are right. We are using JQScriptGenerator here, but we don't need to. Not even for the CSP. We'll use the default script generator and see how it goes. No need to change anything now.

Cheers,
Adriaan

[adriaon]

An update. It turns out we are using WATagBrush>>#script: which requires a script generator.

[jbrichau]

I think we could remove the use of the onLoad function and directly render the loadscripts at the end of the body. This is already what happens with the load scripts included in an XMLHttpRequest request generated by a jQuery ajax html:, where there is no full html document either (i.e. no root).

While we could only make that change in the context of rendering web components, I believe the onLoad function is even not necessary for full page requests either.

[adriaon]

With the mod mentioned in the opening post the scripts do get rendered. However, they are not executed. Scripts contained in the string used to set innerHtml are not executed for shadow doms. See https://stackoverflow.com/questions/51101473/script-inside-shadow-dom-not-working. JQueryInstance>>#html: is affected by this too.
We are working our way around this and plan to post some snippets soon.

[adriaon]

As I mentionened, setting innerHtml inside a shadow dom will not excute the code from the script tags it might include. This affects WAWebComponentsLibrary>>#seasideWebComponentsJs that has the line "this.#shadowRoot.innerHTML = xhr.response;" and also JQueryInstance>>#html:. To work around this, we created a javascript function that adds the scripts separately to the target:

function loadHtmlForWebComponent (targetElement, htmlString, clearContent) {

	// Create a template element to safely parse the HTML
	const temp = document.createElement("template");
	temp.innerHTML = htmlString;
	const content = temp.content;

	// Extract scripts before cloning
	// (scripts in innerHTML don''t execute, so we handle them separately)
	const scripts = Array.from(content.querySelectorAll("script"));
	scripts.forEach(script => script.remove());

	// Clear element content by default
	if (clearContent ) {targetElement.innerHTML = "";}

	// Append content to target element
	targetElement.appendChild(content.cloneNode(true));

	// Execute scripts by recreating them
	// (recreated script elements DO execute when appended to the DOM)
	scripts.forEach(oldScript => {
		const newScript = document.createElement("script");

		// Handle external scripts (with src attribute)
		if (oldScript.src) {
			newScript.src = oldScript.src;
		} else {
			// Handle inline scripts (script content)
			newScript.textContent = oldScript.textContent;
		}

		// Copy all other attributes (type, async, defer, etc.)
		Array.from(oldScript.attributes).forEach(attr => {
			newScript.setAttribute(attr.name, attr.value);
		});

		// Append to DOM to trigger execution
		targetElement.appendChild(newScript);
	});
};

And a jQuery extension htmlForWebComponent() that uses this function:

// jQuery extension - thin wrapper around loadHtmlForWebComponent
$.fn.htmlForWebComponent = function(htmlString) {
	return this.each(function() {
		window.loadHtmlForWebComponent(this, htmlString, true);
	});
};

In WAWebComponentsLibrary>>#seasideWebComponentsJs one can instead of

...
this.#shadowRoot.innerHTML = xhr.response;
...

do

...
loadHtmlForWebComponent(this.#shadowRoot, xhr.response)
...

And we modified JQueryInstance>>#html: into

JQueryInstance>>#html: aRenderable
	"Set the HTML contents of matched elements."
	
	self session presenter isWebComponent
		ifTrue: [self call: 'htmlForWebComponent' with: (self render: aRenderable)]
		ifFalse: [self call: 'html' with: (self render: aRenderable)]

This works for us hackers and might spark some inspiration for a cleaner solution?

[marschall]

With the mod mentioned in the opening post the scripts do get rendered. However, they are not executed. Scripts contained in the string used to set innerHtml are not executed for shadow doms. See https://stackoverflow.com/questions/51101473/script-inside-shadow-dom-not-working. JQueryInstance>>#html: is affected by this too. We are working our way around this and plan to post some snippets soon.

I created #1536 to track that issue so this issue can remain focused on rendering the scripts.