[BreakfastB0b]

  Hooks are the place to segment out effectful code from otherwise pure code

The effectful code shouldn't even be there. It should live separately from the render / view code to make it easier / faster to test without having to simulate a fake DOM. The average call to `render` takes around 100ms. The tests could be orders of magnitude faster and so much easier to test if people would just keep their business logic and effects seperate from their render code. Does no one remember MVC?

[bern4444]

> 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. React is just the view in MVC. Plenty of frameworks exist to help build an MVC with react that provide their own structure and guidelines.

React is incredibly flexible and can be used in many ways. All this shows is the need for strong architecture decisions and guidance because React is so hands off in making recomendations of how it should be used or what tools it should be used with.

That's a strength. It absolutely requires more up front work on yours and mine part to construct an architecture that fits our needs, but it gives us the ability to completely tailor the solution which is the best part.

[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.

[qudat]

What would you test with just a pure react component? What are you actually testing? Given some props it prints certain html?

I’d argue that test is not that useful. Instead what we do in the react world today is focus on integration tests. Testing what happens when you navigate to a page, click on elements, and make sure it does what it is supposed to.

[eyelidlessness]

The usefulness of testing a pure functional stateless component depends on the complexity of what the component does based on its props. And in some cases the testing is valuable but can be abstracted, e.g. with snapshot regression testing.

Just as you probably don’t get much value out of testing a function that increments an input number, but you may get a lot of value out of testing, say, a function that generates a series of smooth quadratic curves over a series of points.

And that’s a much easier thing to test at the unit level than integration.

It seems to me that either:

- your usage of props and rendering isn’t particularly complex, but your interaction model is

- you’re using state to manage that complexity where someone else may model it without state

I’m not passing judgment if it’s the latter, it’s fairly common in the frontend world to model that way. But it’s certainly not my preference.