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.