[schwartzworld]

> what if you only want to perform a side effect when a particular value changes?

https://react.dev/reference/react/useEffect

That is literally what useEffect is for! Describe your side effect, provide a list of values that you want the hook to watch for when they change. `useEffect(someEffect, [value1, value2, value3])`

> the very natural, and often inevitable, concept of side effects

React uses a functional programming model. Always has. Watch the Honeypot React documentary and notice how many times the earliest adopters say they were excited to have way to express UIs functionally. Functional programmers believe in minimizing side effects. If you don't like the paradigm, there are 1000 other UI frameworks that use an imperative model. Complaints like yours read like someone complaining that their screwdriver isn't a hammer.

[azangru]

> That is literally what useEffect is for!

No, sorry; for useEffect to fire, a prop or a state needs to change; which means that the component is going to re-render. My point is that sometimes we want to observe properties passed to the component for side-effect purposes without re-rendering the component.

> Functional programmers believe in minimizing side effects.

In order to do something — anything — in the real world, we need side effects. Even Haskellers know this :-)

[schwartzworld]

>> Functional programmers believe in minimizing side effects.

> In order to do something — anything — in the real world, we need side effects. Even Haskellers know this :-)

Hence the use of the word "minimize"

[johtso]

Sounds like the prop shouldn't be getting passed to the component then if the component isn't using it to render itself? Maybe it should be getting sent straight to your "store" perhaps? Let the components take care of the rendering, let your "store"/"state machine"/whatever take care of the side effects.

[brucou]

I beg to differ here. Or let's say that the React "functional programming" model has very little to do with the actual functional programming done by actual functional programmers. What is true is that React components are functions. But functional programming and programming with functions are two different things.

Second, side effects are just about in every React component where you use a hook.

Third, (hypothesis) `useEffect` is probably a misnomer that stick there because it would be a breaking change to rename it to something more proper.

Words and bickering aside, you can write great applications with React, that's fact. It is also a fact that a lot of folks are using it wrong, which shows either a problem with React learnability itself, or with its documentation, or well, with the programmers themselves.

[schwartzworld]

> side effects are just about in every React component where you use a hook.

I would expect most of your side effects to happen as a result of user interaction, i.e. in an event handler. Data fetching would probably be at the top of the tree. What side effects are you including in every component?

> a problem with React learnability itself, or with its documentation, or well, with the programmers themselves

All three!

- Most programmers dont learn FP before adopting React, which means they aren't going have a more difficult time working with React's functionalish model.

- Lots of blog posts, tutorials and even docs of popular libraries feature poorly written React code. It's just reality. Lots of people use this library, and there's no barrier to entry to write a tutorial post. IMO, the new React docs are a step in the right direction and should be a primary learning material for most.

[ttfkam]

useEffect is an abstraction leak. You're defending boilerplate that a compiler can identify and eliminate for you.

Let computers do what they're good at so that we devs can concentrate on the actual problems being solved.