Shay Lewis

For additional color here about bubble-reactivity: - The big idea is **ready state propagation**: it has a bit field on all signals (both computed and state) for its loading/reloading(/error) status....

@dead-claudia Hah, yeah, this is almost exactly the core construction of the [bubble-reactivity](https://github.com/bubblegroup/bubble-reactivity/blob/main/src/index.ts) approach that @modderme123 and I were fleshing out a while back, and which I tried to describe...

@wycats Do you have a particular low-level design in mind here? I'm definitely sympathetic to these concerns, and I think we might well be able to find some lower-level more...

This seems to be two similar but separate issues: 1. Should a watcher strongly retain its sources? 2. Should a watcher that isn't referenced, except through the graph, be disposed...

@alxhub That's all true of Compteds, but Watchers in this proposal don't have a tracked body like that -- they can add/remove edges with `watch` and `unwatch` however they like....

I think the "next weakest" useful alternative here is something like this: ```typescript namespace Signal { namespace subtle { const context = Symbol("context"); function currentContext(): unknown; } interface Options {...

If you pass a constant value you have to construct a new one for each Computed -- even if you wanted to expose the entire Computed, since you can't pass...

First question: yes, no restrictions -- what constraints would you have expected? Second question: I think this is a mistaken impression of how Computed works. They're not push based; they...

What would we expect from this? ```javascript const f = createComputed(() => x.get()) createEffect(() => { x.set(Math.random()) console.log(f.get()) }) ``` Are we looking for something that avoids these sorts of...

> When multiple errored computed signals are data dependencies of another computed, and this results in an AggregateError, the order of the errors Are we doing AggregateError there? I thought...