Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The hooks approach is all about making the UI more incremental. I have an easier time reducing the work the computer has to do by using hooks like useMemo and useEffect compared to custom prop diffing. For example, building complex query forms over large amounts of in-memory data that do minimal async requests and re-computations when props change is much easier with hooks. useEffect/useLayoutEffect also makes behavior lifecycle for weird DOM stuff like MutationObserver easier to manage since you don’t need to spread it out in like 6 different lifecycle callbacks.

On the other hand, class components have a better developer experience for components that are mostly dumb renderers that bind a lot of event handlers - `private handleFooClick = () = > { … }` is a lot nicer than `const handleFooClick = useCallback(() = > { … }, […])` and you don’t have to worry about ordering between your methods definitions in classes. Declaration ordering between hooks is annoying, but what you get in return is incremental computation. If you don’t need that stuff, sure - use a class!

I do find more and more frequently as I’m working with class components thinking “dang, this would be much easier with hooks”, especially for tricky problems. I don’t find the opposite to be true in hook components.



It is weird, isn't it? I like class components but with complex functionality or rather a bigger codebase functional components are much easier to work with and adding hooks later on is much easier than updating class components.

But for some reason, picking someone else's class component and working on it feels much easier than someone's functional component.

I 100% agree with the last statement, most problems feel easier to write with hooks than with class components.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: