[eyelidlessness]

> > The effectful code shouldn't even be there. It should live separately from the render / view code

> If that's your preference React is probably the wrong tool to begin with.

That’s... a strange take, considering that’s how almost everyone wrote React UIs before hooks.

[imbnwa]

How is this and grandparent so heavily downvoted without proper replies? Seeing this a lot in this thread.

I feel like the unspoken difference in this thread is between people who have IO/business in their view code, and people whose taste is to strongly separate them, leaving component state for strict view modeling like animation timers, etc. I had this difference with my former tech lead.

[eyelidlessness]

I’m not sure which side of that you see me on. But to clarify, I’m definitely not a fan of mixing business logic/IO with view code, but I’m also not a fan of hooks for view modeling state either.

The problem I have with hooks is fundamentally that they perform magic side effects that change the semantics of both the call site and its return type: what would otherwise be a pure function of props returning a data structure (referential transparency) is transformed into a constructor/factory type thing that returns a stateful thing which will render differently for the same props when its internal state has changed.

I generally would prefer to avoid state, and model as many changes as possible with functional data flow, but even where I do need to reach for state I’d prefer its initialization be expressed entirely outside the render function body. It would be a very small API change to achieve the same expressiveness of hooks, with just a small bit of additional syntax.