[menssen]

It is possible with React to write an application where components have no internal state, every component is "read only," and all UI changes are state transitions in (something like) a redux store.

This is rarely done, because there are pragmatic reasons (e.g., animations) not to, but it is possible.

The other mistake alternatives make is to try to make components having internal state "easier." It should not be easier! Every single useX() is a statement that "I am violating the proper design pattern of this application," and it's a feature not a bug of React that you have to be obvious and intentional about it.

[dexwiz]

If one of the most popular APIs is a violation, then maybe the pattern is broken.

[gherkinnn]

I agree.

useEffect should have been named useDangerousSideEffectAndThisIsNotALifecycleHook and the js influencers should have never compared useEffect to component lifecycles and the React team should have updated their docs and not wait 4.5 years to do so and the dependency array should absolutely not be optional.

[DougBTX]

It’s a misremembering of history. The point of all the “pure functional” discussion was that rendering the UI now shouldn’t depend on how the UI was rendered earlier. The idea was to move away from the “create then update” paradigm to just “render”. React would be responsible for which elements need to be created and which can be updated in place.

To achieve that, it doesn’t matter whether the state is local to a component or global across the application.

[breadwinner]

> React would be responsible for which elements need to be created and which can be updated in place.

That works for simple, read-only components. The moment the component starts managing its own interactivity you end up needing state, and at that point things break down. If you need to change props, you have to essentially recreate the component by changing key [1], and at that point, what is the benefit of React?

[1] https://legacy.reactjs.org/blog/2018/06/07/you-probably-dont...