Rational: why no effects out of the box?

[NullVoxPopuli]

We've had a number of issues about effects

• https://github.com/tc39/proposal-signals/issues/239
• https://github.com/tc39/proposal-signals/issues/149
• https://github.com/tc39/proposal-signals/issues/136
• probably more.

The gist somewhat comes down to a difference in opinion of the necessity for effects. Also, there are different kinds of effects. In particular, in the js-reactivity-benchmark -- it can only test with synchronous effects -- see this issue on environments without such a concept maybe being unbenchable as a result (or at least, necessitates macro benching).

A summary (of what I can remember right now) of the stances:

• "effects" are a way you synchronize reactive state outside of the reactive statement -- like in a simple CLI program, I may not want to write a whole scheduling system. Perhaps simple demos should work with fewest lines possible.
• we don't want to encourage effects at all, because they're an anti-pattern in userland code, can lead to visual glitches, etc -- these ecosystems may not even have an effect primitive, and instead push their reactive state out to the DOM via a scheduling system (batching only, and still not available to users -- this necessitates a framework (or at least a library) to handle DOM updates)
• users think in cause and effect, and are used to using the concept, and will want to use some form of effect regardless of the hazards of subtle, or the lower level primitives available to them, which is dangerous -- so we should provide something to manage the hazard risk
• effects require an ownership model. Which expands scope of this proposal

[justinfagnani]

I think it'd be nice to expand on "effects require an ownership model", which I think is very tied into "effects should be run by a scheduler" (which is how I would summarize the first point).

Ownership is important because it would be used by the scheduler to order effects so that other side effects of changing state that naturally occur in ownership-tree-order are done in a coherent way. The main example being a UI component tree and needing to run component-associated effects in tree order so that parents render first, and if parents pass data to children that are also responding to signal changes, that the child only renders once.

This is my understand of the technical reason to prefer to push effects out to a library that would presumably also handle scheduling. Clarifying this might make the stance make more sense to some of the people who are asking for built-in effects. It might also outline what would be necessary to have either a good built-in effect, or some kind of hooks for scheduling effects.

[justinfagnani]

I'm not sure how to interpret 👎 on this issue. Are they asking to not state the rationale?

[EisenbergEffect]

I'm not sure either @justinfagnani. I think the request is more than reasonable. Unfortunately, I wasn't present when some of the discussion around this was happening, leading up to the initial proposal. Perhaps @milomg has some insights he can share.