I 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.

I 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.

not 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

Nah 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.

a date picker would be super annoying to use if you would have all the state in the store. that are probably 40 variables. assume you open the date picker can can move threw the tabs of the month and you are not interested in changing this from outside.

if you have no state in the component that would not be possible. you can also not wrap this with an other component that can hold this state because you don't want components with state. that means all behaviour that requires state would have the state in the store this will just be crazy

You can do it in 3 stored variables

Redux is global state. Adding all local state to a global store will result in a complete mess for any non-trivial app.

Maybe if you're writing it ;)

Most of the time it mirrors the structure of a file system which is the exact way (almost) every program is written.

As with most software projects, keeping organized is like 80% of the battle.

Pardon my ignorance, but is prop drilling a problem once you've bought into Redux or similar?

No it provides helper functions that inject props into your component.

Can you explain what you mean by that? I'm honestly a little lost on what you're saying but I am curious.

I read it as "I don't like hooks."

I 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.

Exemples would be welcome here as I've a strong belief that hooks made react components cleaner / shorter

For 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.

I believe the useRef hook is used for this problem:

https://reactjs.org/docs/hooks-reference.html#useref

The example even uses .focus()

That's just not true: https://reactjs.org/docs/forwarding-refs.html

Maybe I misunderstood, but isn't this what `React.forwardRef` is for?

along with useImperativeHandle for writing your own imperative functions like focus() or whatever

While 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.

I 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.

Yeah 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

I 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.

That'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.