Proposal: Reactive controllers protocol

[splitinfinities]

Recently, we've been exploring Lit's reactive controllers (ionic-team/stencil#3162) and this PR on lit was referenced. This seems interesting to explore to create a community protocol, so I wanted to open that conversation here. It seems there's some prior art around this too, linked here: lit/lit#1682

[justinfagnani]

Yes, this would be great!

There are a couple of reasons we haven't proposed this ourselves quite yet:

1. While [labs] Reactive controller adapters for other frameworks lit/lit#1682 shows that reactive controllers can apply to many of the major frameworks, it's not clear yet exactly how general this model is. Frameworks with fine-grained reactivity (where they track individual changes and only update affected parts of the DOM) might have some impedance mismatches. In the WC ecosystem, I think Fast is probably most like this, so it'd be good to investigate there. It'd also be good to check in on non-class-based WC libraries like Haunted and others.
2. I'm a little worried about premature standardization - specifically we still need some experience with controllers in real-world SSR scenarios. Those might drive additional lifecycles that separate DOM-safe from non-DOM-safe callbacks. I might be overly concerned here and we can work on those over time in this CG.
3. Because this is a pure JS interface and not an event-based protocol, we could just make interfaces in a package like reactive-controller. The governance model we come up with in the WCCG will be helpful though.

Very happy to work this one out though!

If people are already trying to use controllers across frameworks we could get the current Lit interfaces into a common location and iterate from there.

[leobalter]

From a broader perspective this is interesting. I'll try to bring this for internal discussion to see how LWC can benefit of this as a native option.

[bennypowers]

Haunted and atomico implement useController. Hybrids has a force function in use by the controller factory at https://github.com/apollo-elements/apollo-elements/blob/main/packages/hybrids/factories/controller.ts

[EisenbergEffect]

FAST would be interested in working together on this. @justinfagnani I think you've identified the primary challenge as being that FAST takes a fine-grained update approach. There's no "re-render this view" in FAST. So, we'd have to somehow shape the API to enable that.

[justinfagnani]

Coming back to this after a while, and with some experience with working with Signals... I think there likely is a path forward for fine-grained reactivity systems with reactive controllers, but would need some feedback from the other libraries.

What we've done for Lit is to synchronize the reactive lifecycle (which updates the entire template) with pin-point signal changes. So we batch the signal changes and flush them together with any changes that require running the template, if any. This means that we do have before/during/after lifecycle points even with signals. And those are what can drive controllers.

I assume that most signals libraries are doing batching of DOM updates triggered by signals? If so, hopefully they could tie controller lifecycle callbacks into the batch execution. A possible difference that might matter would be whether batching is global vs per component.

[bennypowers]

does that mean that this.host.requestUpdate() can take params in a future version?