|
|
|
|
|
by eyelidlessness
2016 days ago
|
|
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. |
|