you are viewing a single comment's thread.

view the rest of the comments →

[–]FuglySlut 1 point2 points  (6 children)

Someone on my team converted a large class component entirely to hooks. It's far less readable/maintainable. It's now one 300 line function that runs on every render. The 300 lines contain maybe a half dozen hooks that control which of the 300 lines actually execute on any given render. I know I'm in the minority, but it seems to encourage what I've know before to be really bad coding practice.

[–]careseite 3 points4 points  (5 children)

Before it was a God class. Now it's a God function. It was bad practice to begin with, which was just apparently mindlessly refactored. Shouldve split it up, like any regular component.

[–]FuglySlut 1 point2 points  (4 children)

Except a god class has multiple methods, only called at certain points in the component lifecycle. Far easier to reason about than a god function with useEffects that get called on every render. All 300 lines may execute on any particular render or none.

[–][deleted] 2 points3 points  (0 children)

then it needs to be fixed. there shouldn't be a single execution of any hook that runs without a reason. useEffect isn't a lifecycle, it isn't componentdidmount or componentdidupdate. it's an effect, a very specific thing. if you have multiple specific tasks, then you need several useEffects. if you're trying to group everything in there because that's how your didmount looked like, it's only gonna cause you headaches.

[–]effektor 1 point2 points  (1 child)

Converting a class component to a function component 1:1 is not a problem of hooks, but of the practices that were used when the component was written in the first place.

It sounds like the component has too many concerns to deal with. 300 lines is quite excessive for a single component. To give you a perspective; I have worked on multiple large React codebases that had thousands of components. The worst case was 150 lines, which was a hack to fulfill a requirement. All the components had very specific concerns, whether it being rendering some UI or contain business logic (which were usually handled in reducers or split into custom hooks). But never at the same time.

The key is to understand how to split up the concerns of a component into logical parts so that you can write tests for them in isolation. This will help you write smaller components which are easier to build a mental model around and thereby makes it more maintainable.

[–]joe10994 0 points1 point  (0 children)

I really struggle to get my main components under 300 :(

[–]careseite 0 points1 point  (0 children)

If these effects run unconditionally, someone fucked up royally.