Re: [WICG/webcomponents] [templates] A declarative JavaScript templating API (Issue #1069)

justinfagnani left a comment (WICG/webcomponents#1069)

@dariomannu

> You know what I would add to it?
> Support for Promises and Observables/Observers as template parameters

There are a fairly large number of data types that could be natively handled by the template system. I think the important questions about this are:

1. Where are different values handle? In the template layer or the DOM Parts layer?

I think values should just be passed through to the DOM Part created by the templates, with the possible exception of Directives (see 3).

2. What's the criteria for support of a data type?

In my experience with userland libraries of this concept, you want to keep the number of data types you support fairly small and close to what the DOM already accepts. One reason is code size, complexity and bugs - fewer data types is less of all. Another is having standard semantics and familiarity to the existing DOM.

The important exceptions have been primitives, iterables, and nested templates. These are needed for very basic control flow and binding types.

Being native changes the code size and familiarity considerations, but not necessarily complexity and bugs.

One criteria I think I think is important is to not natively support asynchronous data types unless there is a story for scheduling and batching their updates. I do think there should be a story for that though, and that async types like Signals, Observables, and Promises should enqueue a batch update so that the DOM is coherent.

3. How do users add support for new data types?

The native system can't handle all useful data type, and it can't handle non-standard userland interfaces. And a good system for adapting new data types into templates takes pressure for the template system to accept too many data types.

One way to do this is to have one primitive types that's a good target to adapt other values to. Signals might be a good candidate here. Any async value-producing type can be piped to a Signal and update its value, and the DOM Part can respond to that update.

Directives are another way. A Directive is a stateful object that has direct access to the underlying DOM Part. Directives essentially customize expression value handling in a very generic way. A Directive can subscribe to a container value, such as a Promise, Observable, Stream, Async Iterable, etc. and write new values to the DOM Part. Directives can also get access to the DOM controlled by a DOM part, so they can do other complex operations like moving DOM. 

> I'm behind [rimmel.js](https://github.com/reactivehtml/rimmel), probably the closest working "userland" match you can find to this proposal, except it directly challenges Signals and promotes an improved use of Observables instead.

Cool! I love seeing more template literal based systems - it proves their suitability for this domain.

I think that currently, [lit-html](https://lit.dev/docs/libraries/standalone-templates/) is the closest thing to a working prototype of this idea. It was designed after the initial proposal and discussion of Template Instantiation and internally has many of the same concepts, including DOM Parts. lit-html was designed as if it were an API that the DOM could realistically have natively, so it tries to hew very closely to DOM concepts and data types.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/1069#issuecomment-2763067475
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/1069/2763067475@github.com>