If I have to consider something, give me a hint of what it's about 😄
Anyway, interesting video, very clear. Shawn is excellent at explaining stuff.
But, IMO, the point still remain. A developer could learn those things, but they shouldn't be forced to do so. They're glimpses of the internals of hooks. But, as Shawn says at the end of the video, that's not React - so it's unclear how, for example, removing a component from the tree affects the hooks array. Or why you can't use hooks inside class components. Or why there's a useEffect hook but also a useLayoutEffect and how - or why! - they differ.
This is complicated by the fact that function components do have a lifecycle just like class components, but it's hidden under the rug of hooks.
I also wonder why, at this point, it is the case. I.e., why a lifecycle seems so natural at this point. It's not like someone imposed this concept on everyone - maybe it's just because we usually see something "coming to life", "living" and "dying" that we apply this idea even to application components 😬
Also, React indeed has a "cycle" to make things work - the work loop. Which works well with JavaScript's event loop too.
In the end, I'm unsure if there are solid, evident advantages about hooks that makes us say that they're definitely the better way to create (React) components. They comes with compromises, like basically everything else, and I'm unconvinced that the drawbacks could be nullified by mere habit.
But for now, I still think it's too soon to declare something.
My feeling at the moment is that Hooks is an attempt to solve issues they created themselves by pushing functional programming too far (HOC wrapper hell, etc.).
That's weird because it's pretty easy and elegant to avoid those problems if you use the right OOP patterns (adapters, dependency injection...).
I wish they had improved the class usage rather than introducing those terrible, anti-pattern, useThings.
They are shiny and new, they are nice for small components and todo demo apps, but for large apps, the problems remain.
Consider watching youtube.com/watch?v=KJP1E-Y-xyo
If I have to consider something, give me a hint of what it's about 😄
Anyway, interesting video, very clear. Shawn is excellent at explaining stuff.
But, IMO, the point still remain. A developer could learn those things, but they shouldn't be forced to do so. They're glimpses of the internals of hooks. But, as Shawn says at the end of the video, that's not React - so it's unclear how, for example, removing a component from the tree affects the hooks array. Or why you can't use hooks inside class components. Or why there's a
useEffecthook but also auseLayoutEffectand how - or why! - they differ.This is complicated by the fact that function components do have a lifecycle just like class components, but it's hidden under the rug of hooks.
I personally think it’s only complicated because we’re so steeped in OOP and lifecycle methods this seems so alien.
Yes, that indeed might be the case.
I also wonder why, at this point, it is the case. I.e., why a lifecycle seems so natural at this point. It's not like someone imposed this concept on everyone - maybe it's just because we usually see something "coming to life", "living" and "dying" that we apply this idea even to application components 😬
Also, React indeed has a "cycle" to make things work - the work loop. Which works well with JavaScript's event loop too.
In the end, I'm unsure if there are solid, evident advantages about hooks that makes us say that they're definitely the better way to create (React) components. They comes with compromises, like basically everything else, and I'm unconvinced that the drawbacks could be nullified by mere habit.
But for now, I still think it's too soon to declare something.
My feeling at the moment is that Hooks is an attempt to solve issues they created themselves by pushing functional programming too far (HOC wrapper hell, etc.).
That's weird because it's pretty easy and elegant to avoid those problems if you use the right OOP patterns (adapters, dependency injection...).
I wish they had improved the class usage rather than introducing those terrible, anti-pattern, useThings.
They are shiny and new, they are nice for small components and todo demo apps, but for large apps, the problems remain.
That's an interesting take as they're using closures. Which as you may know isn't new, nor specifically "functional".
HOC wrapper hell is also interesting as in my experience most HOCs issues are down to bad architecture and exhibit similar as inheritance.
"They are shiny and new" - they're old. Only new in React land.