7 ms·

Component lifecycle methods to hooks and HOCs, does that ring a bell?

by olliepop 2y ago

ng12 2y ago
Yeah, and I'm not anywhere near as distressed about it as this article implies I should be.
- figassis 2y ago
  As a BE engineer when that happened, I had just started to become proficient in it, coming from Angular. I threw in the towel and went back to my backend world of peace and happiness. So he's not alone, these deprecations are insane.
  - the_other 2y ago
    Front-end dev here. I hear from the b/e people about containers, serverless, lambdas, ORMs, queues, schedulers, caches, pipelines (ok, I use these too), databases, API gateways. Oh, but it's podman now, not Docker. And they're moving everything off AWS to Azure. And there's three versions of the API my f/e needs to talk to still in production. And every micro-service depends on a different version of Node. Apart from the one that's in Ruby and the stuff from that department who only use .NET. I don't believe this promised land of clarity, comfort and purity exists. It's just mess on both sides of the internet connection trying to solve different parts of the problem of turning user needs into money.
    - lezojeda 2y ago
      [dead]
    - skydhash 2y ago
      More often you inherit a stack and rarely you move away from it. And even if you jump on the latest infrastructure trends, there will probably be enough enterprise customers that they will support it for a while.
    - figassis 2y ago
      The beauty of this is that these technologies all tend to be optional, backwards compatible, and interchangeable. You make your choices when architecting depending on what you want to solve. You can build Hussain Bolt or Frankenstein. On the FE, just the landing page is a mission.
- michpoch 2y ago
  Most likely because you work on apps in active development. Wait till someone asks you to add some feature in app that was deployed a few years ago and need something new. Maybe fixing security issues by updating the dependencies? How likely will that happen without you having to rewrite the code of the app?
crab_galaxy 2y ago
Class components and HOCs aren’t deprecated though.
- only-one1701 2y ago
  They're very much not "best practices", and will be deprecated soon (if they're not already).
  - hajile 2y ago
    You still can't add features like error boundaries in React without class-based components somewhere in your app. Even if they added these features to functional components today, it would be years before they'd consider them safe to remove. HOC still exist and builtin features like `React.memo(MyComponent)` along with the like of more functional styles means they aren't ever going away.
  - zero_shift 2y ago
    I'm not aware of any indication that class components will be deprecated.
    - deleted 2y ago
      [deleted]
  - madeofpalk 2y ago
    But they're not deprecated. Where's the forced churn? Every place that I've been at has made the gradual shift to migrate stuff away from class components as new stuff gets built or refactored. Seems like a pretty common development habit.
  - only-one1701 2y ago
    Mea culpa: they’re not being deprecated. But the existence of custom hooks removes the bulk of (if not all of) their utility, and make it much easier to reason about code and make your code well-typed.
  - 2y ago
regularjack 2y ago
The transition to hooks was worth it.
- the_other 2y ago
  I'm not convinced. - they're much harder to learn and understand than the callback hooks from class components - The built in ones hide all the ways React is managing state for you behind obscure names that don't reflect how or when to use any of them - The new-ish `use` built-in doesn't follow the same usage rules as the rest of them (you can use it in places you can't use the others) - the stateful ones create side effects (unless you pretend that state is an argument), so they don't even follow an easy-to-grasp version of the functional paradigm - they have strange quirks (like you basically have to write your component function to use its hooks before you render anything... so you can't early return) - the mental model for how to put them together when you're writing custom ones is a little bit funky too. - the early "advert" for them was that we could put all our domain knowledge together in one place, rather than spread about over multiple callbacks. Given that we usually need to interact with a couple of domains at a time, in time with component lifecycles, I think this makes the code harder to work with rather than easier
deleted 2y ago
[deleted]

Component lifecycle methods to hooks and HOCs, does that ring a bell?

ng12 2y ago

Yeah, and I'm not anywhere near as distressed about it as this article implies I should be.

figassis 2y ago
As a BE engineer when that happened, I had just started to become proficient in it, coming from Angular. I threw in the towel and went back to my backend world of peace and happiness. So he's not alone, these deprecations are insane.
- the_other 2y ago
  Front-end dev here. I hear from the b/e people about containers, serverless, lambdas, ORMs, queues, schedulers, caches, pipelines (ok, I use these too), databases, API gateways. Oh, but it's podman now, not Docker. And they're moving everything off AWS to Azure. And there's three versions of the API my f/e needs to talk to still in production. And every micro-service depends on a different version of Node. Apart from the one that's in Ruby and the stuff from that department who only use .NET. I don't believe this promised land of clarity, comfort and purity exists. It's just mess on both sides of the internet connection trying to solve different parts of the problem of turning user needs into money.
  - lezojeda 2y ago
    [dead]
  - skydhash 2y ago
    More often you inherit a stack and rarely you move away from it. And even if you jump on the latest infrastructure trends, there will probably be enough enterprise customers that they will support it for a while.
  - figassis 2y ago
    The beauty of this is that these technologies all tend to be optional, backwards compatible, and interchangeable. You make your choices when architecting depending on what you want to solve. You can build Hussain Bolt or Frankenstein. On the FE, just the landing page is a mission.
michpoch 2y ago
Most likely because you work on apps in active development. Wait till someone asks you to add some feature in app that was deployed a few years ago and need something new. Maybe fixing security issues by updating the dependencies? How likely will that happen without you having to rewrite the code of the app?

crab_galaxy 2y ago

Class components and HOCs aren’t deprecated though.

only-one1701 2y ago
They're very much not "best practices", and will be deprecated soon (if they're not already).
- hajile 2y ago
  You still can't add features like error boundaries in React without class-based components somewhere in your app. Even if they added these features to functional components today, it would be years before they'd consider them safe to remove. HOC still exist and builtin features like `React.memo(MyComponent)` along with the like of more functional styles means they aren't ever going away.
- zero_shift 2y ago
  I'm not aware of any indication that class components will be deprecated.
  - deleted 2y ago
    [deleted]
- madeofpalk 2y ago
  But they're not deprecated. Where's the forced churn? Every place that I've been at has made the gradual shift to migrate stuff away from class components as new stuff gets built or refactored. Seems like a pretty common development habit.
- only-one1701 2y ago
  Mea culpa: they’re not being deprecated. But the existence of custom hooks removes the bulk of (if not all of) their utility, and make it much easier to reason about code and make your code well-typed.
- 2y ago

regularjack 2y ago

The transition to hooks was worth it.

the_other 2y ago
I'm not convinced. - they're much harder to learn and understand than the callback hooks from class components - The built in ones hide all the ways React is managing state for you behind obscure names that don't reflect how or when to use any of them - The new-ish `use` built-in doesn't follow the same usage rules as the rest of them (you can use it in places you can't use the others) - the stateful ones create side effects (unless you pretend that state is an argument), so they don't even follow an easy-to-grasp version of the functional paradigm - they have strange quirks (like you basically have to write your component function to use its hooks before you render anything... so you can't early return) - the mental model for how to put them together when you're writing custom ones is a little bit funky too. - the early "advert" for them was that we could put all our domain knowledge together in one place, rather than spread about over multiple callbacks. Given that we usually need to interact with a couple of domains at a time, in time with component lifecycles, I think this makes the code harder to work with rather than easier

deleted 2y ago

[deleted]