3 ms·
Each case and each person is different, maybe dependencies arrays just work better for you. Potentially huge effects that read a couple of signals shouldn't exi
by fabiospampinato 4y ago
Each case and each person is different, maybe dependencies arrays just work better for you. Potentially huge effects that read a couple of signals shouldn't exist, because you can always read the signal at the top and pass their values to an external function containing this huge amount of code.
> What do you mean by conditional dependencies?
Random example:
useEffect ( () => {
if ( !supportsThemes () ) return;
if ( darkMode () ) {
doSomething ( darkTheme () );
} else {
doSomething ( lightTheme () );
}
}
In a reactive system this is all you have to write, if the first check never passes you only read "supportsThemes" so you will only be listening to that. If that passes in the future then maybe you'll start listening to "supportsThemes", "darkMode" and "darkTheme", but not "lightTheme". If "supportsThemes" becomes false again you'll automatically stop listening for "darkMode" and "darkTheme".
In React this works differently, all those signals now become dependencies in the dependency array, the entire array will be diffed each time, whenever any of them change your effect will be re-executed, even if something you don't care about in that moment changed.
Basically the same problem exists for hooks too, all hooks must be called all the time, which also as a side effect implies that some hooks calls need to become non-sensical, like if I don't have an onChange function what do I need to call useDebounce for it for? Should the hook support receiving a non-sensical null argument? Should I call it with a pointless noop function? This problem doesn't exist either in a reactive system, fundamentally because dependencies are dynamic, if you don't want to call a hook you can just not call it. If you want to nest effects you can do that.
- ZephyrBlu 4y ago> you can always read the signal at the top and pass their values to an external function Which is basically re-inventing a dependency array... except it's not explicit and now I have to look at another function as well. I don't understand how you are supposed to reason about complex effects with the signals model. > Random example Why would I want to complicate things with conditional effects though? It makes it so much harder to debug and reason about. > the entire array will be diffed each time, whenever any of them change your effect will be re-executed, even if something you don't care about in that moment changed An array diff on the order of ~10 elements isn't an expensive operation and I can implement conditional logic in React just like you've demonstrated here. What is different about signals in regards to conditional flows? > if you don't want to call a hook you can just not call it. If you want to nest effects you can do that I'm not convinced this is desirable. Complex implicit reactive effects seem fragile and difficult to debug and reason about. This is somewhat mitigated with React because of the Rules of Hooks, which gives you expectations about how your code/system should behave but even then people have complained about them being difficult to understand. This feels like a step backwards in terms of complexity. Without better tooling/observability (E.g. easily trackable effect history, value history, etc that is integrated into the dev env) implicit reactive dataflow based systems feel like they will be way harder to manage.
- dreamlifelike 4y agoYou’ve basically presupposed your conclusions re: the reactive approach, so yeah, if I were you I wouldn’t bother. Incidentally the “rules of hooks” are frustrating precisely because the expectations they impose around hook use are confusing and unintuitive.
- ZephyrBlu 4y agoI think dataflow mechanisms are really interesting, but I don't see them as being something easy to build a complex system on. I stated this very clearly, saying "complex implicit reactive effects seem fragile and difficult to debug and reason about". If you're building something that is heavily focused on computing values rather than more event driven effects I could see a reactive system being more useful and appropriate though. I'd love to hear from developers/teams who have built complex systems with a reactive framework (Solid, Signals, etc) to hear about the upsides and downsides of doing so.
- localvoid 4y ago> I stated this very clearly, saying "complex implicit reactive effects seem fragile and difficult to debug and reason about". It is definitely easier to reason about dataflow in a good incremental library with dependency autotracking ("Self-Adjusting Computation"[1]) than to reason about nondeterministic concurrent rendering in React :) 1. https://www.cs.cmu.edu/~rwh/students/acar.pdf https://www.cs.cmu.edu/~rwh/students/acar.pdf