3 ms·

You can still write simple, understandable React. All the weird, obscure hooks they have added in the recent years are opt-in and are often better left for libr

You can still write simple, understandable React. All the weird, obscure hooks they have added in the recent years are opt-in and are often better left for library maintainers. You probably don't even need useMemo or useCallback. That's not to say I don't see developers (mis)using them all the time, but that's self-imposed convolution and you can only blame React as a footgun supplier.

skydhash 1y ago
I ise hooks all the time, mostly because I write custom hooks that wraps everything external to my view. Makes for a simpler conponent code.
- codemonkey-zeta 1y ago
  I agree that this is the approach that keeps react apps simple. The biggest problems I see in react code are giant components that read like this: useState useState useState ... // 20 more useEffect useEffect useEffect ... // 20 more I think a lot of front-end devs don't realize the necessity of custom hooks for composition and modularization. My personal rule is "Never use react hooks (useState, useEffect, etc.) in component code. All react hooks MUST be wrapped by custom hooks." and it makes for MUCH better code: useSomeData useOtherData useMobileView useScrollToTop useInteractionLogging ... // 10 more hooks This is also what makes TanStack so good and popular. It's all just behavior wrapped in hooks.
  - matsemann 1y ago
    This I disagree on. Unless the hook is to be reused, just chuck it in your component where it's actually used. Yeah, it's pretty if you can decompose it cleanly. But if you end up with calling useX, and passing a statement function from that to useY etc, it's just a mess figuring out what's going on. Just chuck it all in the component and skip the abstractions.
    - skydhash 1y ago
      For very small local state, I can agree. But if you three or more standard hooks that interact together, it’s worth it to wrap it in a custom hook even if it’s going to be in the same file. The semantics will be clearer and working with the code easier. I much prefer to see useFlashyAnimation than its code in the component.

skydhash 1y ago

I ise hooks all the time, mostly because I write custom hooks that wraps everything external to my view. Makes for a simpler conponent code.

codemonkey-zeta 1y ago
I agree that this is the approach that keeps react apps simple. The biggest problems I see in react code are giant components that read like this: useState useState useState ... // 20 more useEffect useEffect useEffect ... // 20 more I think a lot of front-end devs don't realize the necessity of custom hooks for composition and modularization. My personal rule is "Never use react hooks (useState, useEffect, etc.) in component code. All react hooks MUST be wrapped by custom hooks." and it makes for MUCH better code: useSomeData useOtherData useMobileView useScrollToTop useInteractionLogging ... // 10 more hooks This is also what makes TanStack so good and popular. It's all just behavior wrapped in hooks.
- matsemann 1y ago
  This I disagree on. Unless the hook is to be reused, just chuck it in your component where it's actually used. Yeah, it's pretty if you can decompose it cleanly. But if you end up with calling useX, and passing a statement function from that to useY etc, it's just a mess figuring out what's going on. Just chuck it all in the component and skip the abstractions.
  - skydhash 1y ago
    For very small local state, I can agree. But if you three or more standard hooks that interact together, it’s worth it to wrap it in a custom hook even if it’s going to be in the same file. The semantics will be clearer and working with the code easier. I much prefer to see useFlashyAnimation than its code in the component.