Westbrook
commented
1 month ago 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.
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
functionorclass(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:
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)