Opt-In reactivity for createEffect instead of opt-out

[lunafoxfire]

My Concern

First off I wanna say Solid has been a joy to use. Compared to React I really enjoy the simplicity of the API and how much easier it is to get things done. However I wanna talk a bit about my number one source of bugs so far: createEffect. So 99% of the time that I'm using createEffect, it is to react to changes in one specific prop or piece of state, and execute some side effect when that happens. Take this UI pattern for example:

If I want to react to the user selecting a new option from the dropdown I might do something like this:

createEffect(() => {
  alert(`Selected ${selectedOption()}`);
});

However if I later decide that I want to use some other data in that effect, I might change the code to something like this:

createEffect(() => {
  alert(`Selected ${selectedOption()}\nDescription: ${description()}`);
});

But now I have a bug! Any time I update the description text, an alert will now be triggered, even though that was not my intention. And a situation like this could obviously be much more complicated and easy to miss. My options in this case are to use on or untrack. Imo, untrack is the worse option since I would rather be explicit and list the dependencies precisely:

createEffect(
  on(selectedOption, () => {
    alert(`Selected ${selectedOption()}\nDescription: ${description()}`);
  })
);

This is fine, however this is very noisy syntactically (in my opinion) in order to accomplish what I feel like (in my opinion) should be the default mode of operation for createEffect. And the noise gets amplified when you consider that props must be specified as () => props.foo in the on deps. Again, any time I am using createEffect I am thinking in terms of reacting to changes in props or state. Without on, createEffect has the potential to become very complicated and react to very unclear dependencies. In my code I have gotten in the habit of using on almost every time except for the most trivial uses.

A Solution

So it is probably not reasonable to change the signature and functionality of createEffect. In my code I have created a helper function to combine createEffect and on:

export function createEffectOn<T>(
  deps: AccessorArray<T> | Accessor<T>,
  fn: (value: T, prev: T | undefined) => void,
  options?: { name?: string }
): void {
  createEffect(on(deps, fn), undefined, options);
}

Which is used like so:

createEffectOn([selectedOption], () => {
  alert(`Selected ${selectedOption()}\nDescription: ${description()}`);
});

I have been using this helper to the complete exclusion of createEffect and I feel like it does a much better job of keeping my side effects easy to reason about. It may not seem like a big deal when I could just use createEffect and on together to achieve the same thing, but having a single primitive means that it is easy for me to do the correct (in my opinion) thing and always specify effect dependencies.

Note Vs React

So I get that the decision to remove dependency arrays from Solid was probably inspired by annoyance with React. I think this totally makes sense for things like createMemo, which is obviously much nicer when reactivity is opt-out rather than opt-in. However, I think with React, the useEffect dependency array isn't an annoyance in concept. In theory, the dependency array provides a critical way to see at-a-glance what causes the code to execute, which is extremely important when dealing with non-pure side effects. For pure computations like useMemo, 99% of the time you don't actually care what changes cause re-computation -- you just always want the computed value up-to-date.

However, in practice React's useEffect dependencies become cluttered with junk you don't care about due to React's rerender model. Stuff like callbacks that need to be up-to-date and prevValue for detecting deltas. So much so that there is an entire linter rule dedicated to making sure you don't forget dependencies, and you must specifically opt out of this rule on a case-by-case basis. Basically React's useEffect pretends to be opt-in but it is opt-out in practice. Solid doesn't have this problem, and createEffect dependencies can be specified minimally (via on) to describe exactly what triggers an effect. But again, Solid hides this behind on.

Conclusion

Personally, I think opting in to side effects makes way more sense both from a conceptual and maintainability point of view. createEffect has the potential to generate an immense amount of complexity if dependencies are not explicitly defined. I believe it should absolutely be standard practice to always specify effect dependencies since it can become very difficult to understand what an effect's auto-generated dependencies are, especially as the effect becomes more complex. However, I am not satisfied with the current method of doing this in Solid. Having on as a separate primitive both makes the syntax more noisy and signals to the developer that explicit dependencies should be the exception rather than the rule.

Ultimately I would rather createEffect itself directly support explicit dependencies to make it crystal clear that explicit dependencies are allowed/preferred. However, changing the API of createEffect so drastically is understandably probably not an option at this point. Instead, adding useEffectOn or some equivalent to the API would also be a good option imo. I want effects with explicit dependencies to be a first-class citizen within Solid in order to promote code that is both easier to read and write across the whole community and not just those that spend way too much time thinking about it (cough).

Mostly I would like to hear the thoughts of other developers on these points. As Solid grows in popularity I can forsee this potentially
becoming one of the small nagging things people start to dislike about it. Which would be a shame because I love Solid and will continue to use it!

_{^{Thank you for reading my essay}}

[trusktr]

Sounds reasonable its just a shortcut that combines createEffect and on. We can write that in a few lines.

[guillaumebrunerie]

If you want to react to a specific event, why don’t you simply use an event listener instead of an effect? In this example, you can do the alert in an onChange event listener on the select.

[lunafoxfire]

Well yes in this very specific example I provided, that would work. It was more meant to be a minimal demonstration. But the answer is "the same reason you would ever use createEffect at all". It's not about reacting to a specific event, it's about reacting to changes in state. A lot of the time you have multiple pathways in the application that all mutate the same piece of state, and createEffect gives you a way to not care about the details of how some state changes, only that it does.