Context API

[justinfagnani]

The Lit team has been prototyping a Context-like API based on events.

The basic idea is that components that need some contextual data will fire an event to request the data. The event will carry a callback use the pass the data to the requesting component. Components that can provide the data will respond to the event and call the callback with the data. The callback can then trigger arbitrary work in the requesting component, including a re-render.

The details needed for interop are things like the event name, callback property name and signature, and any keys that are used to identify the context and or data object.

[justinfagnani]

@sorvell might be able to put up a draft PR with a few more details relatively soon

[Westbrook]

preact-custom-element is also relying on a dispatched event to resolve context: https://github.com/preactjs/preact-custom-element/blob/master/src/index.js#L71 so definitely some prior art here. One area that I've struggled with a little bit when thinking of similar is the idea of live data without being tightly coupled to a renderer. I look forward to the PR to see how that might be addressed therein!

[justinfagnani]

@Westbrook

One area that I've struggled with a little bit when thinking of similar is the idea of live data without being tightly coupled to a renderer

This should be pretty well addressed by the event carrying a callback. The provider calls the callback with data, the consumer reacts however it needs to, including triggering a render. If the consumer supports it, the callback can be called multiple times and trigger updates each time, very similar to useContext in React.

[ryansolid]

The one thing I've wondered with this event sort of approach is timing. To use events am I correct the element would have to be connected to the DOM? Would the data be available to us at the time of connectedCallback?

The other thing is whether slotting should have any consideration. Can light DOM children slotted under Shadow DOM Provider still get access to context.

With Solid Element I use a bit of a different approach. I do lookups up the DOM tree traversing in and out of Slots and Shadow roots. Once you are connected you are then attached to the context more or less since it's just using the DOM heirarchy. I realize events probably do the same thing without re-creating this walk but as I said I never was comfortable trusting the timing of things. It's possible things have changed from the heavily polyfilled ecosystem we had here a few years ago.

And I had a second motivation where I wanted to unify context with the non-webcomponent side which does everything before being attached (or even connected to it's parent) so I needed some creativity there.

[justinfagnani]

@ryansolid

The one thing I've wondered with this event sort of approach is timing.

Events are synchronous, so the timing is suitable for data needed synchronously.

To use events am I correct the element would have to be connected to the DOM?

Events work in disconnected DOM trees, so the elements would not necessarily need to be connected to the document, though a provider would need to be an ancestor in the disconnected tree to provide anything. The question there is what signal the element would use to fire the event to request the data? connectedCallback is probably the most natural place, so if you needed something even when disconnected you'd have to fire in the constructor, attributeChangedCallback, etc.

Would the data be available to us at the time of connectedCallback?

Yep, if the provider is ready. One nice thing about firing the event in connectedCallback is that if you are requesting subtree-dependent data, you can re-request if the element is moved to a new subtree.

The other thing is whether slotting should have any consideration. Can light DOM children slotted under Shadow DOM Provider still get access to context.

Event bubble up the flattened tree, so slots and slot ancestors, including the host, could act as providers to slotted children. This can enable use cases where a utility element in a shadow root, maybe like a theme provider, could provide objects to a slotted child.

I think events, their timing, and their scoping are really well suited for this problem.

[LarsDenBakker]

When I was implementing our router I created a context API using events. I abandoned the idea in the end for other reasons, but it worked out reliably cross browsers. Lion also uses events for form registration which needs to be synchronous.

[JosefJezek]

Here is one implementation Polymer/pwa-helpers#64

unistore is waiting for the context developit/unistore#175

[EisenbergEffect]

While I find Context APIs handy, I've found them to not be quite enough in larger applications. In most cases, I've used a more robust Dependency Injection system. Not too long ago, I did some work to integrate a DI system I had written so that it worked on top of React's context. I'd really like to ensure that I can implement DI on top of this Context proposal in a similar way. I imagine that it would work by:

• Using the protocol to locate the container itself, rather than a particular service.
• Having the located container also register for context events and resolve all requests from 3rd party components itself.

The first point should allow 3rd parties to introduce their own container into the DOM hierarchy to resolve services requested through the DI system, while the second point should allow the DI system to resolve requests by components that are based on the raw context API with no knowledge of containers.

Does that make sense?

[DeadWisdom]

The initial event's callback adds the need for an event dispatching mechanism. The provider must act as an observer and has to track consumers (all of the callbacks). Another idea: the provider could simply modify the context event object with the data, a reference to itself, and an event name that it will trigger on itself to update the value. The consumer could then use the data, and then addEventListener() onto the provider, and consume as normal.

Example code

[Westbrook]

@sorvell did you ever get anywhere with your draft of a proposal here? We're looking at formulating a solid "How do I make apps without the context API?" resource for engineers at Adobe moving from React to Web Component projects and would love to shape it around something that was closer to a "community protocol". I'm sure we'll need a good amount of iteration on anything we bring together here, but having something to poke holes in would be a great first step!

[benjamind]

I have begun documenting my current approach to Context here in this repository: https://github.com/benjamind/lit-context

I've outlined my best guess at what the API should be, and also provided some implementations against lit-element v3 style controllers to make it convenient to use.

Would love some feedback on this.

[jarrodek]

Hi,
Too bad I missed this discussion before. This is a problem that was troubling me for some time. After designing 3 ecosystems of WC I came up with a very similar approach to the presented above. There is a significant difference between what I was doing so far and what's in the proposal. I dismissed the idea of using callbacks after few months of testing in favor of using promises. Each event extends CustomEvent and has the mandatory result property defined on the detail object. The result is just a promise returning a value that the context provider produces.
The context request event dispatched from the component describes what kind of context the component is expecting but I use the type instead of the name property. Both have pros and cons. I like using the type property because inside the context provider I can register events for specified types ignoring all other events. It's then easier to understand the context provider is doing by just looking at events registration. It also allow to filter out easily what the provider can listen to. The cons for using this is that a large application can have hundreds of events like this. In a multi-tenant environment (different apps running in the same document) having a single event for all may be considered as a security issue. There's no was to statically analyze that this component coming from this application can request this context.

The proposal also does not specify how to pass arguments to the context provider. I assume this would be passed in the detail object. However, without standardization of this would make it only partially useful as you won't get proper types support. I fixed this by defining a number of events and these events have well defined properties. At least in the declaration file. I tried both defining properties on the event and on the detail object. Both works pretty well but from my experience it's easier to keep it all in the detail object.

If I would to design the architecture for this today I would design a new type of event that extends CustomEvent interface. This event has the result property on the detail object which is a promise resolved by the context provider. The promise is not set automatically when it's created but rather when the context provider handles the event. Missing value (no promise) means that the event was not handled and the component should deal with this somehow.

For an event subscription, when the context provider announces changes in the context, I use separate set of events which I call state events. The context provider dispatches an event when a value change. A component registers event listeners for a specific state change event. When change occurs it requests the changed data from the provider (I usually pass the meta data about the change to this state event containing the identifier of the object, if any, and optional change name).

This way I was able to build rather large applications that work both separately as a standalone application and in a multi-tenant environment. I hope my POV will help understand different use cases and implementations.

[Westbrook]

I dismissed the idea of using callbacks after few months of testing in favor of using promises.

@jarrodek could you give a little more information as to what you found lacking in callbacks during your test period?

For an event subscription, when the context provider announces changes in the context, I use separate set of events which I call state events. The context provider dispatches an event when a value change. A component registers event listeners for a specific state change event. When change occurs it requests the changed data from the provider (I usually pass the meta data about the change to this state event containing the identifier of the object, if any, and optional change name).

I'd love to see this fleshed out a little bit more in code. I'm not sure where the binding responsibilities and patterns for the "state events" occur. It feels like you'd be adding a good amount of decentralized responsibility to the consumer of the context, which might be beneficial for its disconnection from the context generally but feels like it might actually end up being a lot more work that just registering a callback centrally on the context provider.

[justinfagnani]

@benjamind this looks really great. Can't wait to discuss tomorrow!

[benjamind]

I'd definitely like to hear more about what failed you with regard to use of callbacks @jarrodek . One of the benefits for me of this approach is that it is very easy to reason about, and extremely simple protocol. It is also very easy to implement it synchronously, while not closing the door on asynchronous value fulfillment, which I think for many scenarios is quite valuable.

I think I can see what you are driving at in terms of state update, making it an explicit action of the component to 'get' its updated value in response to an event emitted by the state store. I suspect this is not incompatible with the API as proposed above and could be built atop this to provide a different approach to state management.

I've added a few goals/non-goals to the readme in the repo linked above. I've specifically called out wanting to keep this API as simple as possible, a variety of things could be implemented using this protocol, but I think at its core we should strive to keep this as straightforward as we can for maximum compatibility.