context

[tombl]

a goal I have for this library is to decouple the data tree and the render tree, or have the data tree drive the rendering instead of the other way around.

this implies little ownership over the data tree, so we can't provide utilities like context for the general data case. however, there are a few cases where the ability to scope data to the render hierarchy is useful, e.g. in a userland suspense/error boundary implementation.

however, many uses of context are actually better suited to the tab or browser scope (current theme, dialog state, query caches, auth, etc.), so maybe we can get away without any context mechanism.

if we can implement those few core use cases in the library itself, we won't need to expose a primitive to do the same.

[tombl]

for the cases I can think of where context is an app logic primitive rather than a way to hide prop drilling (so suspense/error boundaries), we already have a better tool for signaling up the render tree: DOM events.

both of these things are trivial to implement on top of raw events, which means if you want them, you can just build them already.