5 ms·
I would argue that writing a React component with a hook is a mistake. There is usually an easier/clearer way to solve the problems that hooks are intended to s
by pg_bot 6y ago
I would argue that writing a React component with a hook is a mistake. There is usually an easier/clearer way to solve the problems that hooks are intended to solve with the existing React primitives.
- duxup 6y agoCan you explain what you mean by that? I'm honestly a little lost on what you're saying but I am curious.
- dgritsko 6y agoI read it as "I don't like hooks."
- duxup 6y agoI wondered the same but the text was also confusing so I thought maybe there was something else there. At least for me hooks dramatically clean up the code. Outside of error boundaries (I think those still have to be classes) any new component for me is a function component and if it needs state, has hooks. Granted I still maintain a lot of class components back from before the days of hooks.
- esquevin 6y agoExemples would be welcome here as I've a strong belief that hooks made react components cleaner / shorter
- flowerlad 6y agoFor one thing you may not use the ref attribute on function components because they don’t have instances. That means the component can't have a .focus() method for example. For simple components hooks may be fine. For more complex ones I prefer classes.
- Octoth0rpe 6y agoI believe the useRef hook is used for this problem: https://reactjs.org/docs/hooks-reference.html#useref https://reactjs.org/docs/hooks-reference.html#useref The example even uses .focus()
- cnity 6y agoThat's just not true: https://reactjs.org/docs/forwarding-refs.html https://reactjs.org/docs/forwarding-refs.html
- avery42 6y agoMaybe I misunderstood, but isn't this what `React.forwardRef` is for?
- evan_ 6y agoalong with useImperativeHandle for writing your own imperative functions like focus() or whatever
- fendy3002 6y agoI haven't use hooks and don't prefer it, however I must say that there isn't alternative to hooks that is shorter in syntax, and maybe easier.
- jordanwallwork 6y agoYeah I wasn't sold on hooks at first, mainly because I was having to re-think stuff that I already knew, but man now I'm used to them I'm so much more productive and I absolutely love it
- WesleyJohnson 6y agoI echo this statement. I use Django a lot for my backends and I was very, very against moving to class-based views. I'm not sure why, I love OOP, but I was so used to function-based views. I finally made the switch (well, I use both when appropriate) and I love them. During this time, I started playing around with React and I thought, I learned my lesson, it's class-based components all the way. Yet again, the community started going to "other" way with function-based components and I was steadfast in my attachment to classes - refusing to budge. Of course, I eventually made the switch and wish I had done so sooner. Once you get the hang of hooks, they're so much easier to reason about and, as you said, make me much more productive.
- fendy3002 6y agoThat's not without reason, javascript class is infamous for being weird with 'this' gotchas, and class is 2nd class citizen there (not as good / powerful as one in java). Meanwhile function based view is neat. However without hooks, only class based component has side effects and lifecycle, so you like it, then made switch to hooks because it's neat.
- qudat 6y agoI get what you're saying but disagree. Hooks are essential and make life much easier for the react developer, especially when using something like `react-redux` or `react-router`. Prop-drilling or HoC might seem like a better design until you actually have to work in a system that leverages them and realize it's an indirection nightmare.
- jrvidal 6y agoPardon my ignorance, but is prop drilling a problem once you've bought into Redux or similar?
- kls 6y agoNo it provides helper functions that inject props into your component.
- pg_bot 6y agoI would go a step further and say that React Components should not manage their state internally. (this.state was a mistake to add to the project) You can create every single UI in the world using pure functional components. They are easier to understand since they act like every other function, and they are simpler to test. Keep your state externally and just grab what you need on each subcomponent with the `connect` function from `react-redux`. Easy peasy front-end development.
- LorenzA 6y agonot sure i understand you correctly, but keeping all state external just clutters up the store i feel. if the state is not used anywhere else and you also don't need to change it externally i would not move state out of the component. also if your state is always outside of your component they will only be reusable if you hook up the store in all your projects the same way
- pg_bot 6y agoNah you can get reusability by creating shared components that you just pass props into. For example, you can have a date picker that just accepts variables to display the current state and parent component that reads data from the store and passes it into the date picker component. This method is also great for debugging, since you can just replay the state transitions over again if there is an application error. If the component holds the state, then it can be cumbersome to reproduce the error.
- kelchm 6y agoWhile I don't agree that writing a component with a hook is always a mistake, I have seen them used in situations where it wasn't warranted. In the end, they are just another tool -- knowing how to use the tool appropriately is the critical part.