[context] element-based API

[trusktr]

It would be great to have an element-based API, because it would make the context pattern not only usable with any Custom Element authoring patterns whether as function or class (Lit, solid-element, Enhance, Lume, etc), but also usable in any non-custom-element frameworks (React/Vue/Svelte/Solid/Angular/etc).

I wrote all the details and examples here initially:

• feature: element-based API open-wc/context-protocol#25

But maybe it would be more useful as an update to the context protocol here?

The context protocol here documents only the event-based pattern. Would it be useful to also standardize both a mixin pattern and an element-based pattern? (Or at least the element pattern, because that's as stadards aligned as we can get, offering flexibility across all custom- and non-custom-element frameworks)

[Westbrook]

Doesn't not having an element-based API make it easier for non-custom element solutions to leverage this as it is just event dispatching and listening that can happen no matter what your solution for applying those to an application are?

Blessing a single implementation in the form of actual elements feels contrary to the "protocol" concept in that it then becomes a mini-library that would just be another dependency that projects feel forced to take on to "make things work". Outlining how your application could interoperate with any number of other tools feels like a better goal for a "community protocol" than placing the onus on an application to "do it with these tools", which is generally what we see in frameworks already.

If the solution were to "ship an element" or "ship a mixing", how would you see the broader community take on management that? The theory of a central protocol that any library/framework/base class/project can adopt internally also avoids finding a solid solution to that, but if there were good one, maybe it would be worth learning in that direction both with the Context Protocol and other concepts managed in this repo.

[trusktr]

Doesn't not having an element-based API make it easier for non-custom element solutions to leverage this as it is just event dispatching and listening that can happen no matter what your solution for applying those to an application are?

Yeah, but this won't replace the JS event API. This feature is just more aligned with DOM and frameworks that manipulate DOM (React, Vue, Svelte, etc), where in all DOM frameworks we write things declaratively:

return <some-context value=${...}>
  <some-element />
</some-context>

Being able to write declaratively makes it more convenient in the myriad of DOM frameworks. And also in plain HTML:

<some-context value="...some deserializable string value...">
  <some-element />
</some-context>

which would work for SSR solutions.

The JS protocol would still be there for anyone who needs it, and this idea would not replace it (maybe it would be implemented on top of it).

Besides, the DOM is the most standard way to interop everywhere, because note that any DOM elements can be instantiated with JS, so absolutely any JS library or framework can easily do this:

const context = document.createElement('some-context')
context.value = 123

context.append( someAPIThatCreatesATree() )

Another thing is that, because DOM is the standard interoperable interface in the web (and basically all frameworks designed to declaratively manipulate it), defining the protocol for elements (beside events) would still be standard everywhere no matter the type of framework.

That's the beauty of Custom Elements!: define the API for an element, and it can be implemented anywhere and used anywhere (regardless if the implementation is here, or somewhere else).

[Westbrook]

I'm likely blind to the full benefits, particularly in that I would expect something like this to be "implemented on to of" the Context Protocol, but that doesn't mean we shouldn't get more information on what you'd want to make happen here. We've got a Proposal Template, and likely the best next step is to structure a PR for "Proposal status" of such an API for others to get a better idea as to what you're thinking here. Sound good?