[context] Event namespace

[loganvolkers]

Thanks for putting together a formal specification @justinfagnani

I tried (and failed) at pushing for some centralization some years ago via dom-context

Two things to share:

1. Please see the below list of related projects. In writing dom-context one of the design goals was to be compatible with existing libraries, so I think such an audit would be helpful for moving the proposal forward.
2. Consider making the event name flexible. The spec now considers everything as context-request. Other libraries use other event names. It might aid centralization and standardization if we can support polyfills for existing components and libraries (both providers and subscribers).

Related projects

• blikblum/wc-context - uses the same event handler approach, includes integrations with other Web Component libraries, and is well tested, but doesn't support retries/polling. Uses the context-request-${name} event namespace. Exposes a core library, so it can be used in other web component compilers.

• askbeka/wc-context - uses the same event handler approach with the request-context-${contextName} namespace. Only works with custom elements, so incompatible with Stencil.

• petermikitsh/stencil-context - uses the same event handler approach, but does not support having different context names (everything uses the same shared mountConsumer event name)

• ionic-team/stencil-state-tunnel - doesn't support nested providers (see issue #8) and requires javascript props on components to wire them up.

• mihar-22/stencil-wormhole - uses the same event handler approach with openWormhole and closeWormhole event names. Only supports using a single object as context, spreads that object to it's children properties.

• @corpuscule/context - uses the same event handler approach, but uses decorators so it is incompatible with Stencil

• haunted - uses the same event handler approach with haunted.context event name, but relies on detail.Context objects for handling multiple context types. Only exposes Provider as custom HTML elements, so doesn't support global providing, or connecting providers into non-custom elements.

[justinfagnani]

I think a standard event name is an important part of the protocol. It's what allows for interoperability between providers and consumers from different implementations, and allows for generic utilities that can buffer, replay, etc., context request events.

[loganvolkers]

I think a standard event name is an important part of the protocol. It's what allows for interoperability between providers and consumers from different implementations, and allows for generic utilities that can buffer, replay, etc., context request events.

I would see supporting the existing ecosystem of context solutions as a goal, but maybe that ecosystem is too small to be consequential? Some of the libraries I listed have been abandoned for years, and others are only getting hundreds or low thousands of downloads on NPM. @lit-labs/context (and @lit/context) has grown in popularity, so it might just be the most popular context solution, so the winner by default.

As one of the maintainers of dom-context I would like to support this standard, but that path seems unclear and I would love a migration path discussed in the Open Questions / Previous considerations for all library authors and maintainers to work from.

[matthewp]

@loganvolkers I agree that supporting the ecosystem should be a goal. Would you mind submitting a PR that allows flexibility of the event name?

[justinfagnani]

What is the specific goal of allowing different event names? What would it actually mean to use a different name and how would that enable any interop with other context systems? How would consumers and providers that chose different names work together?

There is more to the context protocol than the event name. The events have to adhere to the ContextEvent interface. Providers must call the callback, respect the subscribe property, etc. The protocol allowing for a different event name would not make dom-context or any of the other similar packages compatible with WCCG Context implementations. But if existing packages change their events and event handlers to adhere to the protocol, why wouldn't they change the event name too?

As one of the maintainers of dom-context I would like to support this standard, but that path seems unclear and I would love a migration path discussed in the Open Questions / Previous considerations for all library authors and maintainers to work from.

I think the only path is to support dispatching and listening to Context protocol compatible events, including the event name. You can do that in addition to the events and listeners you already use.

[loganvolkers]

There is more to the context protocol than the event name. The events have to adhere to the ContextEvent interface. Providers must call the callback, respect the subscribe property, etc. The protocol allowing for a different event name would not make dom-context or any of the other similar packages compatible with WCCG Context implementations. But if existing packages change their events and event handlers to adhere to the protocol, why wouldn't they change the event name too?

Thanks for the feedback @justinfagnani and sorry for the delayed response. I came to the same conclusion but didn't respond.

I think the only path is to support dispatching and listening to Context protocol compatible events, including the event name. You can do that in addition to the events and listeners you already use.

Sorry @matthewp I agree with Justin. I think that backwards compatibility is not possible at the specification layer, and has to be poly-filled differently in each implementation.

For subscribers:

1. Try dispatching a context-request event
2. If that fails, fallback to the backwards-compatible event type

For producers:

1. Listen to context-request events
2. Also listen to the backwards-compatible event type

[matthewp]

The goal of allowing different event names is to dramatically simplify the API, which requires you filter context types that you care about. Using event names instead would mean that you only listen to the events you care about, and the whole thing could be done with a small amount of code and likely libraries wouldn't even be needed. I understand that the current proposal's primary goal is mirroring the React context API and for that reason another proposal is likely necessary to achieve simplicity.

[justinfagnani]

Because you cannot add an event listener for wildcard event names, basing the protocol around custom event names would significantly reduce the flexibility and power of the protocol.

Many custom elements already do send context-like events with different event names and different ways of passing data back through the event to the dispatcher. This is fine. This protocol isn't saying not to do that if you wish.

[matthewp]

I'd recommend adding those goals to the proposal, it's pretty unclear to me what is powerful about that.