[declarative-custom-elements] how would SSR work?

[trusktr]

SSR!

It is one of the things people say can't be done with custom elements, but this is not true. It's just that the elements must adhere to a non-standard set of conventions like they do with Stencil.js or things built on SkateJS SSR. You can stick just any 3rd-party custom elements into either of those systems and expect them all to work with their SSR implementations.

Is it possible that with declarative custom elements we can have HTML payloads that render something up front, and let JS take over later, in a more standard way so that any elements built with DCE can work in the same SSR system?

[sashafirsov]

declarative custom elements we can have HTML payloads that render something up front, and let JS take over later

The concern is completely invalid in the light of Declarative Web Application which assumes functional app without JS whatsoever. Why DCE should have any JS?

The basic use of custom element is to render template with slots payload.
More advanced use would be

• the state sync into own slots/parts
• state/slots driven UI fulfilment
• emit event ( bound aside to the data transformation into another dataset/element state )

^^ also could (and should for DWA) be defined declaratively.

As of SSR in DCE, that matches server mode of web components hydration proposal, no need to invent the wheel.

[bahrus]

Thanks for raising this important question. I think the ground breaking work getting streaming declarative shadow DOM on the table makes this fairly doable.

This is my suggestion for how it would work . For inline binding for template instantiation to work along with it, it would be most effective if it adopts comment-based placeholders

[bahrus]

Other options to be able to "reverse engineer" rendered HTML to a binding template, compared to comment placeholders, are template elements, and other special tags (for example xslt based tags that have no impact on rendering).

Between comments and template elements (if anyone is considering that option), I think the decision should be based on which performs better first. Templates may have the advantage that they are easier to query on, maybe easier to read. I learned recently it is possible to query on comment tags using xpath, so that's probably not a huge factor. I suspect search engines could be trained to use either, as far as detecting types of data (like itemprops provide).

Templates and comments seem like they wouldn't cause serious changes to rendering protocols (in particular, table elements, which are quite finicky about allowed children, don't object to templates, and of course comments are ignored). That would be a bigger issue for xslt based tags (for example).

[sashafirsov]

In the DCE POC the data state is a part of DCE itself. If it is rendered on SSR stage, along with rendered DOM it has to include the state and data.

The POC doe not cover the data slice (de-) serialization mechanism yet. I keen to propose the SLOT-like DOM inclusion which instead of slots, would keep the named slice content.

[keithamus]

WCCG had their spring F2F in which this was discussed. You can read the full notes of the discussion (WCCG had their spring F2F) in which this was discussed, heading entitled "Declarative Templating & Custom Elements".

This was briefly discussed as part of that topic. The consensus from present members of the WCCG was that more use cases need to be captured around this area, in order to clarify what these proposals solve.