[notpachet]

This 100%. I still don't understand why React devs are so infatuated with colocating business logic with the UI that presents the result of that business logic. Sure, in the small (a todo list app? a weekend project?) it's probably a lot easier to reason about if you just jam everything into the same file. But why is it so difficult for people to see that the reason their large application is bloated, untestable, unmaintainable, etc is directly due to the blatant violation of separation of concerns that they're parroting?

I feel like part of this is due to some devil's bargain on the part of the React maintainers. They want mindshare, and they know that it's easier to gain mindshare if the behaviour of the app appears simpler, and that appearance of simpler is easier to achieve if the behaviour is relegated to a smaller number of files...

[nfRfqX5n]

but hooks allow you to easily move business logic outside of your component. most business logic is simple so people use it inline. isolating it makes it pretty easy to test and reuse

[notpachet]

That's true. But to echo the underlying theme of the original blog post, it is difficult to ensure that a large team of developers (of varying skill levels) maintains a consistent approach to this. Different developers likely have different opinions of where that "simple" threshold is that warrants factoring out the business logic. And, when the push of a deadline comes to shove, it is tempting to just throw all the shit in the component with the promise that we'll refactor it at a later date.

More fundamentally, I feel like putting business logic hooks in a component (even simple ones) sacrifices the cleanliness of components as simple stream transformers: input some scalar props, output some HTML. As soon as you start calling hooks within a function component, it's no longer purely functional. You have side effects. And those side effects result in a component that's trickier to debug and trickier to test.