[SSR] FAST elements with @lit-labs/ssr

[nicholasrice]

Hey! We've been playing with the @lit-labs/ssr package over in the FAST repo to see if we can get it working and wanted to share an update with ya'll and maybe get some thoughts/discussion on one of the issues we're running into.

I was able to get many templating features for a FAST element working using the ElementRenderer from @lit-labs/ssr, but am running into a hurdle trying to bind IDL attributes to an element. In a nutshell, FAST's templating system works as follows:

1. Template is compiled once per template, where template bindings are replaced with placeholder strings, resulting in a pure string template with a collection of Bindings to be evaluated for each element instance.
2. Placeholders are then removed and mapped to indexed Node locations for later evaluation.
3. During custom element creation, the template string is converted to elements through DocumentFragment.innerHTML assignment, and all bindings are then evaluated for the custom element instance.

What this means is that there isn't an easy way to convert a FAST template with bindings to a yielded SSR string without using the real element to render. To render out the shadow DOM of the element then, we're creating the custom element in the ElementRenderer constructor and yielding the innerHTML of the element from ElementRenderer.renderShadow(). This poses two related problems:

1. Yielding a shadow DOM with shadowed FAST elements results in redundant creation of elements, because @lit-labs/ssr will find the yielded shadowed element (that was already created by the host during FAST element creation) and provide it to ElementRenderer for re-creation.
2. IDL attribute bindings don't leave artifacts on the yielded innerHTML string, so the redundant creation of these elements actually loses information during this process.

I'm still investigating some workarounds involving element instance caching, but I thought I would get in touch and get your thoughts / see if there is something I'm missing from @lit-labs/ssr that might help address this.

Thanks!

[kevinpschaaf]

Hi! Awesome to hear you're trying this out.

For problem (1), it looks like that's happening because you're running lit-ssr's render back over the innerHTML you're going to yield: https://github.com/microsoft/fast/blob/users/nirice/ssr-invesigation/examples/ssr/element-renderer.ts#L33. We basically envisioned that an ElementRenderer implementation would be responsible for completely owning the serialization of the element's shadow root, including looking up a matching ElementRenderer for any custom elements found in its shadow root and calling setProperty()/setAttribute() from the renderAttributes() and renderShadow() on the ElementRenderer instance for each custom element.

During custom element creation, the template string is converted to elements through DocumentFragment.innerHTML assignment, and all bindings are then evaluated for the custom element instance

lit-html does something fairly similar on the client, in terms of replacing placeholders with strings, using innerHTML to have the browser parse that into template DOM, and then finding the placeholders in the DOM to set the bindings to. However, in order to avoid needing a full DOM shim on the server, we re-implement just the key parts of that process needed to incrementally serialize a template, which in addition to interpolating JS expressions into the template, includes finding custom elements, looking up an element renderer, and calling out to it. However, what's key here is that this is done with knowledge of the template context, so that we can properly call setProperty() on the ElementRenderer for properties that the lit-html template would have set to that node. As you noted in (2), by doing a two pass -- having FAST do the templating on live dom, and then passing the innerHTML of that DOM back to lit-ssr's render as a string -- there's no way to get the non-attribute values (properties, aka IDL attributes) to the ElementRenderer.

This is all to say, we didn't envision that a different templating library would use lit-ssr's server render as the mechanism to find custom elements and run their ElementRenderer, we'd envision e.g. FAST to make their own server version of render that would be called from the FAST ElementRenderer to serialize FAST templates, and which would call back out to the ElementRenderer registry to hand off rendering to other libraries as they were encountered with knowledge of the properties/attributes that should be passed to that custom element in the template context.

[kevinpschaaf]

Happy to chat more about this. While the approach we took meant we needed to duplicate a bit of lit-html's templating logic for the server render implementation, we felt that was a good tradeoff because it means we have a lot more control over yielding out portions of a template incrementally versus using a real DOM and using innerHTML, since that requires building up the entire string before you can emit anything. That said, even for libraries that want to use use more of their client-side logic and jsDOM to do the heavy lifting, we want to figure out the right pattern there so that we can keep the streaming nature of this architecture, so I think it's worth continuing to push on the approach you've taken and see if we can make it work.

It seems like after you've built up the DOM tree using jsDOM, rather than taking innerHTML, if you instead did a treewalk over that DOM and yielded out the strings for each node individually (re-implementing a bit of innerHTML, but it's not too bad; would be similar to the logic here, but yielding out strings from a generator vs. concatenating), and when you got to a custom-element looked up and created an ElementRenderer for it, then you have a chance to call e.g. setPropety()/setAttribute() on the ElementRenderer with any own properties/attributes of the jsDOM node, and then yield out the renderAttributes() and renderShadow().

[justinfagnani]

I don't think they should use jsdom at all. It'll result in lots of innerHTML work per element render and be slower than processing the template once. Fast is so similar to Lit that I think they should fork render-lit-html.ts and make it work for Fast templates.

[nicholasrice]

I appreciate the responses! Clarifying that the expectation wasn't that other templating libraries should use render() helps a lot. I was under the impression they were, but it makes sense that that function is specific to lit's templating infrastructure. I'll continue to jam on this and follow up again with questions / findings. Thanks!