[ervine]

So your argument is that instead of explicit class component methods, hooks are implicit based on understanding the react rendering model?

I guess so - but react could also change (and I think did at some point) how their class methods work, how often they're triggered, and when.

I don't understand the stateless comment - hooks are as stateful as you make them, using useState or useContext or any of the other ways of maintaining data between renders.

[halflife]

Classes are inherently stateful. A class instance is a long lived object. Functions are not, a functions internal state is thrown the moment the function returns. What react ask you to do is to attach to external state inside the function, in other words, an un pure function, forego idempotency.

In class based components, you didn’t care how react works under the hood, except for the render method which is called by react. So the surface of code controlled by react was only what you included inside that method. In function components, the entire function is owned by the renderer, so you need to deeply understand how it works.

[ervine]

I guess I think it's table stakes to need to deeply understand how the framework you're using works. Lifecycle methods vs. hooks, you still gotta know what's doing what and why.

[halflife]

Of course, but that really depends on the level of expertise and the type of programmer you are, and to some extent, the attitude of the organization your in to code and refactoring.

When everyone around writes shit code, you don’t care. In hooks, it becomes much more critical.

[ervine]

No, writing shit in react is gonna be a nightmare regardless of paradigm. HoC, Class Components, render props, whatever - if you don't know what you're doing and react internals are magic to you, it's game over. Anyway, we can agree to disagree on hooks vs. classes. Cheers.

[halflife]

Agreed. In the end, I always say that every line of code has deadline in which it will be removed.