Discrepancy between @lwc/engine-dom and @lwc/engine-server static parts application

[jmsjtu]

Currently, our SSR implementation is not compatible with how we apply dynamic attributes to statically optimized elements in the browser.

In #4056 we've expanded static content optimization to allow attributes with expressions.

In the browser, we rely on cloneNode to create the DOM elements, loop through those elements and apply the dynamic attributes to them.

However, in SSR, the cloneNode function just returns the string value in vnode.fragment.

The main issue is the vnode.fragment used in mountStatic has already been assembled by buildParseFragmentFn during the mount process.

As a work-around, in SSR, we insert the expression values at the time the string is being built.

In #4056 we've created a token that serves as an index to map the string to its corresponding static part.

Long-term this should be resolved with a dedicated SSR compiler, see (#3880).

As an alternative to the solution in #4056 we could replicate the cloneNode behavior in SSR, which would require some form of HTML parser.

[nolanlawson]

Alternatively, we could do disableStaticContentOptimization entirely for SSR (it doesn't really add anything), but this would require a separate SSR compile target similar to the dedicated SSR compiler.