5 ms·

I've been doing React for 4-5 years now. My opinion on these best practices: 1. Strongly agree. I'd add a note or two there about styled components or your fav

I've been doing React for 4-5 years now. My opinion on these best practices: 1. Strongly agree. I'd add a note or two there about styled components or your favourite CSS library, and how thinking in components and the tree instead of html vs stylesheets is very useful. 2. Strongly disagree. This indeed seemed like a best practice when I was getting started, but that Action then keeps growing and growing until nobody knows exactly how it works or how to tame it. It's better to keep components small (point 1!) and focused, so let buttons be Buttons. 3. Cannot comment. I haven't worked on so many "just a CRUD app" so this might be useful for those. I can see the value of it if you have e.g. an admin panel or CMS editing a DB or similar. I would leave this repeating logic only to that though, not to the general logic of all the app. 4. Agree, but also use context to your advantage. e.g., instead of `useToggle()`, name it `useVisible()` or whatever is the appropriate name. 5. Strongly agree, it's very powerful to first write the high-level API you want by typing first the desired component tree, and then define the components themselves. 6. Yes we can try different things depending on our apps' needs, but then it's not a "React Best Practices", maybe just a useful tip? :)

pigcat 6y ago
I disagree with 4 as well Maybe the author just used a poor example, but his useToggle is actually less readable to me. The initial example with just useState is super obvious to understand what's going on in that component. With his useToggle example, if I'm in this codebase I'm now asking myself - does toggle() fire some hidden side effect? Now I need to go check out the hook to make sure.
- franciscop 6y ago
  Well that's the goal, that you should not really care (too much) how it's exactly implemented to use it, right? It could be very simple or very complex, it could be in Redux or a simple state hook. In the case of more serious side effects like if it persists through localStorage, you read it once (hopefully through some docs!) and then you know how to use it anywhere. I agree with you that in the author use case it's waaay too simple and the best case is to use it inline, but I believe what they meant to do (hopefully!) is use that as an example of a potentially more complex hook and how you can/should use custom hooks instead of shoving all the logic in the component.
  - pigcat 6y ago
    Fair point.
tshaddox 6y ago
> 2. Strongly disagree. This indeed seemed like a best practice when I was getting started, but that Action then keeps growing and growing until nobody knows exactly how it works or how to tame it. It's better to keep components small (point 1!) and focused, so let buttons be Buttons. I'll reiterate strong disagreement here. This approach is very tempting to reduce code duplication, but in my experience you end up essentially building a "JSX" component that takes an arcane combination of props and returns some specific bit of JSX. So you end up invoking <JSX type="button" buttonColor="blue" buttonLabel="Continue" />. Why not just invoke <Button color="blue">Continue</Button>?

pigcat 6y ago

I disagree with 4 as well Maybe the author just used a poor example, but his useToggle is actually less readable to me. The initial example with just useState is super obvious to understand what's going on in that component. With his useToggle example, if I'm in this codebase I'm now asking myself - does toggle() fire some hidden side effect? Now I need to go check out the hook to make sure.

franciscop 6y ago
Well that's the goal, that you should not really care (too much) how it's exactly implemented to use it, right? It could be very simple or very complex, it could be in Redux or a simple state hook. In the case of more serious side effects like if it persists through localStorage, you read it once (hopefully through some docs!) and then you know how to use it anywhere. I agree with you that in the author use case it's waaay too simple and the best case is to use it inline, but I believe what they meant to do (hopefully!) is use that as an example of a potentially more complex hook and how you can/should use custom hooks instead of shoving all the logic in the component.
- pigcat 6y ago
  Fair point.

tshaddox 6y ago

> 2. Strongly disagree. This indeed seemed like a best practice when I was getting started, but that Action then keeps growing and growing until nobody knows exactly how it works or how to tame it. It's better to keep components small (point 1!) and focused, so let buttons be Buttons. I'll reiterate strong disagreement here. This approach is very tempting to reduce code duplication, but in my experience you end up essentially building a "JSX" component that takes an arcane combination of props and returns some specific bit of JSX. So you end up invoking <JSX type="button" buttonColor="blue" buttonLabel="Continue" />. Why not just invoke <Button color="blue">Continue</Button>?