@yaeunerd I just re-learned React recently, so for me useEffect made perfect sense, specifically as modelling relation between an effect (external system) and some dependencies.
To me it kinda felt a lot like #PureScript's Eff monad? Idk.
Maybe I like it because I don't understand it, but I'm tempted to read the code of useEffect to learn.
I think your approach is definitely more enlightened.
Years ago, I just read the docs,thought I got them, and then promptly shot myself in the foot a few times until I _actually_ got it.
But it's very funny that you picked the hook that has had the most amount of anger and besument thrown at it.
@yaeunerd tbh I just love how they handled hook dependencies! It's just beautiful.
@jonn @yaeunerd So what do you think about signals? Where the dependencies don't need to be declared.
```tsx
useSignalEffect(() => {
// calling `.value` makes this effect run each time signal value changes
const value = signal.value;
// using `.peek()` allows getting signal value without subscribing effect to changes
const anotherValue = anotherSignal.peek();
});
console.log(value, anotherValue);
```
Even better: change in a signal does not necessary mean a render needs to occur.
@jonn
Not sure if your being sarcastic. I think everything _except_ useEffect is sound.
I have to re-explain that hook any time I'm in a react team.
They even changed the meaning on the most recent docs. Used to be that it was "useEffect is to do side-effects of the render function. Runs after mount" (already a bit tricky) now it's for "synchronizing a component with an external system." (???)