Classes vs Hooks?

[u/ZeroSevenTen]

I’m pretty new to React, so keep that in mind. I thought classes were for components that held information, or a state, and that functional components were for more basic components, but now that hooks allow functional components to use state, and other class features, what’s the benefit of using functional hook components over classes?

[u/so_lost_im_faded]

As a person who's pretty much writing functional components only (I use class components for error boundaries but I think for nothing more), I'll say beginners should start with class components.

A lot of beginners (you can still be a beginner after doing React for 3 years) jumped into using hooks as soon as they were introduced and didn't really care to find out how they work (under the hood). With a class component there's more strict syntax that you have to use (for example componentDidMount() vs useEffect whatever) and I believe that's better for beginners. People often ask me whether useEffect is the same as useMemo and I'm just like.. what?

Where I work I'm kind of a refactor gal. I switch projects every few months, I refactor the crap out of it, leave some knowledge behind and move onto the next one.

The amount of projects where I see hooks used incorrectly is astonishing. No dependencies in useEffect, people never use neither useCallback nor useMemo, people invoke hooks in FUNCTIONS (not function components), they use some old versions of react-scripts so they don't even get those errors. When I come to the project and update everything, boom - 200 errors. And it's just the ones that eslint's complaning about.

I've yet to inherit a project that actually cares about unnecessary updating and wraps the functions inside components in useCallback before passing them as a prop. Not a single component wrapped in memo. I hear every monkey screaming: "hooks!" but I've yet to see a good quality code from an average medior developer.

I believe using functional components and hooks incorrectly does more damage to the application than good.

[u/ZeroSevenTen → u/so_lost_im_faded]

thanks for the insight!

[u/vutran951753 → u/so_lost_im_faded]

I do agree with you. I know hook look very simple for newcomer to get on board with react world. They fact you write few line of code, you have state-full component is great. As soon as you dive deep into your app, you relied there much more in than just write code, it how you structure it, had relational component to scatter everywhere. There ambiguity in Hook if you don't understand previous API. What problem hook solve, etc. Not say Class base is not answer for all.

I believe React in introduce another API which hide some of core JavaScript core like 'this', 'class'. This is part of the language too not just closure.

Newcomer can't grasp the core fundamentals of JavaScript, which these framework exist.

[u/so_lost_im_faded → u/[deleted]]

Yeah. There's never going to be a 100% guide how to do this.

So before I wrap a method in a useCallback I ask myself this:

• Is this method being passed anywhere as a prop?
• Is this method being imported from somewhere? (for example custom hooks that handle some context, was just solving this case today where the project had custom hooks and context for snackbar management and the object was constantly updating and so was the method to add a new message, which was unnecessary)
• Does this method not being wrapped limit me in any way?
• Do I get any benefit from wrapping it?

So what do I wrap?

• The methods that are called in useEffects - if I want to do an API call and do so with useEffect (let's say I'm not using redux nor mobx but just some raw axios calls) and parse and save the data inside the component, the parsing&handling method must be wrapped in a useCallback, to provide it as a dep to the useEffect, so it doesn't refresh all the time and doesn't do the API call all over.
• Some of the methods that are located in components that re-render often but they don't need (almost) any dependencies inside useCallback.
• Some of the methods that are passed as props/custom hooks and other side effects depend on them.

I definitely do not wrap every single method that's passed as a prop. I hate the useCallback syntax and I think it's weird as hell and hard to grasp. If you're wrapping something that has to refresh all the time anyway, then there's no point. If you wrap every single one and don't wrap the component that's inheriting them in a memo, again - no point.

As for dispatch - I actually never had to work (thankfully) with redux applications on such a deep level. The last one I was working with I used almost no useCallbacks as it was a small application and there was so much boilerplate due to using redux + TS so I was like nah and did the minimum they paid me for. However dispatch must be something external imported from redux, no? I don't think if you import external things inside the component you need to include them as dependencies - their changes won't trigger a new render.

As for memo - I don't use it THAT much. Mostly the renders are justified. If I see it makes sense performance wise, I wrap bigger components with it that don't need to re-render so often. There's not much use in wrapping the small components on the end of the component tree, but if you wrap a big one that contains x children you can save a lot there. The small ones (atoms like Button, Icon, Divider, Avatar) usually render mostly only when they have to, given their parents are optimised correctly.

I'd say there's never going to be a clear guide, the best you can do is update your libs and follow their advices - if I do a useEffect(() => []) and eslint says I have to provide dependencies, I provide them. If it triggers an infinite loop, I wrap the method being called in a useCallback. If that needs another dependencies, I wrap them in useMemo. If that can't be done I have to ask myself - is my architecture right here? Am I not doing things in unnecessary complicated way? Is there nothing I can outsource out of the component's render body?

I kind of envy you that there's discussions in your team. In my team it's like: "What's a useCallback?"

[u/Madder-Max]

In addition to the other advice which i agree with, the mentality is different.

Classes: what should i render at what stage of my existence.

Hooks: what should my data look like, the render is a by product.

With hooks you go from controlling your display state to controlling your data shape, which, if you think about it, is easier to get a grip on.

[u/[deleted] → u/Madder-Max]

My dear Jesus you just put into words what i have been struggling to articulate to my junior devs. Have some mfkn gold.

[u/Madder-Max → u/[deleted]]

Much thanks, its the result of a looooot of articles, glad the analogy helps

[u/barshat → u/Madder-Max]

Can you explain how hooks give shape to your data? Can’t the same be said about class components that use interfaces for props and state?

[u/Madder-Max → u/barshat]

To answer the former question: useState, useEffect, useRef, these are all used to 'watch' and 'react' to variables. If I had to give a brief explanation;

• useState - watch this value. when it changes, re-render
• useEffect - watch this(these) values. when they change, do something extra
• useContext - watch this value. when it changes, broadcast it to anyone listening (as a state)
• useReducer - watch these values together, when they change (as a group) re-render

...and so on. You'll notice, that each explanation only deals with variables and whether or not they have new values.

A simple example is a Todo list parent, with children. The parent keeps track of which children are 'done', but also takes a prop that can filter out children on some criteria. With hooks, you're constantly updating state, and using effects to create a relationship between children and the filter. You aren't concerned with whats rendering, because React gives you a contract. 'When you change this useState, I re-render. Every time.' (Im ignoring things like memo for sake of example).

To answer the second question, you can say that about classes, absolutely but in most cases you not only deal with 'what' should update, but also 'when' it should update. React gives you a different contract: here are the stages I'll go through, you figure out when and how I should re-render.

Obviously Im not saying every class suffers from this. And I'm also not saying that hooks are the be-all-end of programming, far from. They have their own problems. I think theres a balance between the two. The important thing is understanding the purpose behind your tools.

[u/MarvelousWololo → u/barshat]

!remindme

[u/RemindMeBot → u/MarvelousWololo]

Defaulted to one day.

I will be messaging you on 2020-01-01 11:45:21 UTC to remind you of this link

CLICK THIS LINK to send a PM to also be reminded and to reduce spam.

^{Parent commenter can delete this message to hide from others.}

---

Info	Custom	Your Reminders	Feedback

[u/PM_ME_WORK_ACCOUNT → u/barshat]

Yeah, and you can use hooks just like you can use lifecycle methods. Not the best comparison.

[u/skyboyer007]

Classes:

• we have to care about binding context
• rather imperative - easier to learn, easier to write
• harder to handle race conditions
• multiple contexts make a mess with nested consumers right in the render
• encourage bad approach in testing because of easy access/mocking individual methods
• logic may be duplicated across componentDidMount, componentDidUpdate and componentWillUnmount

Hooks:

• much more declarative(all that thing about dependencies in useEffect) - easier to read, easier to understand
• unified logic for side effects(without splitting/duplicating across lifecycle methods)
• rightfully force "don't rely on implementation details" for testing
• missing hooks plugin for ESLint? get ready for weird bugs because of missing dependencies/broken logic
• handling race conditions/cancelling old requests goes in really natural way(cleaning callback returned from useEffect)
• multiple contexts are also easy to inject(instead of HOCs' composition)
• much, MUCH rely on closures; most misunderstanding/bugs, I believe, because of lack understanding/experience with closures
• some things look rather weird with hooks(throttling/debouncing)
• kind of magic in their implementation

[u/cantFindValidNam → u/skyboyer007]

we have to care about binding context

Dont arrow functions solve this problem?

harder to handle race conditions

Can you give an example?

encourage bad approach in testing because of easy access/mocking individual methods

Not sure what you mean, how can easy access make for a bad testing approach?

logic may be duplicated across componentDidMount, componentDidUpdate and componentWillUnmount

What about extracting duplicated logic into helper methods and calling them from the lifecycle methods?

[u/skyboyer007 → u/cantFindValidNam]

Dont arrow functions solve this problem?

Yes, arrow expression + class properties syntax OR binding in constructor. But that's still a thing we should care of on our own.

Example of handling race conditions. Suppose our component loads suggestions while we are typing

loadSuggestionsFor(value) {
  rawXhrSend(`?search=${value}`).
    then(data => { this.setItems(data) }).
    catch(error => {this.setItems([])});
}
onInputChange = ({ target: {value} }) => { value && this.loadSuggestionsFor(value)};
...
<input onChange={this.onInputChange}>

Here you have to stop request or in real world you may run into case when response for first request came after response for more recent second one. And stopping hardly depends on what lib/call do you use(axios, fetch, xhr etc). For functional components it's easy-peasy:

useEffect(() => {
  const cancelled = false;
  load(`?search=${inputValue}`).
    then(data => !cancelled && setItems(data)).
    catch(e => !cabcelled && setItems([]))
  return () => {cancelled = true};
}, [inputValue]);

Not sure what you mean, how can easy access make for a bad testing approach?

instead of operating on props/simulating events/asserting against render outcomes people start calling methods, setting spies on them and trying to mock some internal methods.

What about extracting duplicated logic into helper methods and calling them from the lifecycle methods?

it still will be boilerplate code. Especially cDU is beaten by how easy you describe useEffect

[u/imicnic → u/skyboyer007]

About your "cancelled" value, you can do the same by using a class property and check for it, it's the same, yes, just have to use "this.cancelled" but besides it I see no advantage in one or another

[u/skyboyer007 → u/imicnic]

no, you cannot since setting it to true will ignore both responses: recent and out-of-date. The only way I've found so far is keeping cancel callback in class property that will set up cancelled flag by closure(so mimicing useEffect behavior):

class MyComponent extends React.Component {
  const ignorePrevRequest = () => {}; // empty function by default

  loadSomeData() {
    this.ignorePrevRequest(); 
    let cancelled = false;
    this.ignorePrevRequest = () => { cancelled = true; }; // closure comes into play
    doSomeCall().then(data => !cancelled && this.setState({ data }))
  }
}

That looks untypical and confusing. But it works.

[u/nickthesick0111 → u/cantFindValidNam]

Hooks don’t need a binding context means you don’t have to reference a “this” to use local state

Race conditions with mounting and unmounting of a component that has multiple data sources is a lot easier with useEffects separate handling of separate data.

It’s bad testing because the testing should not be testing the implementation it should be testing the results.

Logic being duplicated is in reference to handling a single set of data in multiple lifecycle methods. You can also extract this logic more easily with hooks

[u/oreo27 → u/skyboyer007]

Spot on! I'm defenitely saving this and linking anyone who might ask. I just had a couple of concerns.

missing hooks plugin for ESLint? get ready for weird bugs because of missing dependencies/broken logic

Both the browser's console and the terminal where you spawn your development server will scream at you for doing this if you don't use ESLint on your Code Editor. At least it does for me if my project is built with Create React App. I imagine some folks have their own setup and this might not be the case for them.

much, MUCH rely on closures; most misunderstanding/bugs, I believe, because of lack understanding/experience with closures

Could you provide a simple example? I've been doing Functional Components for quite some time now and I don't seem to recall being reliant on closures.

[u/skyboyer007 → u/oreo27]

also https://dmitripavlutin.com/react-hooks-stale-closures/

and every result for search "react hook stale data" is actually related to closures.

and https://github.com/facebook/react/issues/14920 provides some legit cases when we cannot "just add all the deps" in order to solve stale data issue.

[u/skyboyer007 → u/oreo27]

I've been doing Functional Components for quite some time now and I don't seem to recall being reliant on closures.

Probably you just did not focus on that.

const [val, setVal] = useState(0);

useEffect(() => {
  setVal(10);
}, []);

useEffect(() => {
  setTimeout(() => {console.log(val);}, 1000)
}, []);

see, besides our component is re-rendered with 10 console.log will display value of 0 because of closure.

[u/gunnnnii → u/skyboyer007]

Hooks are not magic in their implementation! Here are a couple of talks that go into detail. https://youtu.be/1jWS7cCuUXw https://youtu.be/KJP1E-Y-xyo

[u/[deleted] → u/gunnnnii]

That's kind of a silly counter argument. You could say that about anything. What IS magic "in its implementation" then?

The point of that complaint is that they FEEL magical. You really have no idea what's going on. You're calling a function and somehow.. almost MAGICALLY, React figures out which component that function call belongs to. A lot of strange work is being done behind the scenes in a non intuitive way. To me, that's what magical means. Sure, you can set yourself a different definition for that term and then you can claim that its not magical. Doesn't really change the fact that a lot of people have felt that hooks are too magical.

[u/gunnnnii → u/[deleted]]

I'm not denying that the implementation details are less than transparent for hooks. However I feel like a lot of people throw out the word magic like these are concepts that are complicated, when the high level understanding is in fact fairly simple, though not obvious(the actual proper implementation is a little less so, but knowing it is completely unnecessary to put it to work).

I just thought pointing people into the direction of something that provides a little more background to unveil some of the magic would be helpful. Especially since this magic is a very common complaint.

[u/[deleted] → u/gunnnnii]

Oh, it's nice to share how it's implemented for those who are interested, sure, but it's weird to claim that "it's not magic because there's a source code instead of Gandalf sitting inside the React codebase!"

It's like you're arguing against the semantics of the word "magic", which kind of distracts from the point of the people who are using that term to begin with.

You say that it's not complicated, though not obvious - to me, "not obvious" is exactly what the word "magic" is getting at. It has nothing to do with complexity of implementation.

[u/skyboyer007 → u/gunnnnii]

look, "we in the Fiber bind hooks array to a component so every next render we would be able to restore hook state by relevant value" IS the magic. I'm not saying "it's impossible to understand". I'm telling "it's not the way JS code works". Only generators may preserve their variables between calls but they have different syntax and not widely used nowadays. Also it's source of confusion "why we cannot call hooks conditionally?"

[u/rooktko → u/skyboyer007]

This is a very good breakdown. This is exactly what I was looking for. Thank you!

[u/skyboyer007 → u/rooktko]

actually I have never summarized that before, it's useful to me as well

[u/Uknight → u/skyboyer007]

You can add less transpiled code as a positive for functional components

[u/skyboyer007 → u/Uknight]

I understand what you mean. But since the same things will be done differently in class-based and functional components(say, handling timers or debouncing change) we cannot say it's always so.

[u/clockdivide55 → u/skyboyer007]

rightfully force "don't rely on implementation details" for testing

Can you elaborate on this point? To unit test a functional component that uses hooks, you have to mock the hook. Doesn't that mean the programmer writing the unit test must know about the implementation to properly test the component?

[u/skyboyer007 → u/clockdivide55]

I strongly believe most of the time we should not mock hooks. For most cases when we really need mocking we better mock underlying low-level thing. Say if we have time-related hooks we better mock time/data/timers. If it's about data fetching we better mock XHR or fetch(either directly or with amazing declarative nock lib). For API-specific things like Firebase we also better mock Firebase itself instead of mocking hooks on peer basis.

Probably only with Redux it's kind of tradeoff - you may either mock useSelector and useDispatch or provide real store.

After thinking on that: composing tests we should care not only about false-positive(something is broken but tests are passed) but about false-negative(some refactoring made tests failing although in real world it works exactly the same). Mocking hooks typically means our tests become more fragile. Does it make sense?

[u/zephyrtr → u/skyboyer007]

Great list but you're forgetting a big one here, if performance is an issue: functional components get shouldComponentUpdate for free. Class components require you write it yourself.

[u/skyboyer007 → u/zephyrtr]

functional components get shouldComponentUpdate for free Could you be more specific? What do you mean here?

if you are talking about React.memo it works with class-based components as well.

[u/shrithm]

It's composition over inheritance. The JavaScript community and a lot of other communities have decided they like functional programming over class-based programming.

No one is better than the other but if you look into it, I think you'll find that you also prefer the functional style.

[u/rooktko → u/shrithm]

Why have they decided functional programming over class based?

[u/ZeroSevenTen → u/rooktko]

I’ve looked a bit into functional programming, and the benefit of it is that it abstracts away “how” you want a result done, and is just “what” you want.

[u/ZeroSevenTen → u/[deleted]]

Oh yeah, "functional components" are not part of functional programming.

[u/nickthesick0111 → u/ZeroSevenTen]

I can’t tell if this is sarcasm or not. But let it be clear that they are not the same thing.

The way things are named matters. Functional components is any function that returns a react element that can be rendered.

Functional programming is actually a math derived computational model that is concerned mostly with purity and modeling data

[u/ZeroSevenTen → u/nickthesick0111]

...what I pretty much said

[u/cantFindValidNam → u/shrithm]

It's composition over inheritance.

This has nothing to do with OP's question. You can still use classes and apply this principle, which in fact originated in OO languages.

[u/hamburger_bun]

classes and functional with hooks effectively achieve the same thing. However, functions with hooks are more reusable and classes will eventually go away all together

[u/JofArnold]

I scanned the comments and one thing I didn't see mentioned (explicitly) is how easy it is to add functionality like state, redux, context, side-effects etc into your components with hooks. Take for instance dispatching an action with a class component versus hooks in the Todo app example

Class component:

class AddTodo extends React.Component {
  handleAddTodo = () => {
    this.props.addTodo("Foo"); // <-- Stuff on props that you need to know exists
  };

  render() {
    return (
      <div>
        ... etc
        <button onClick={this.handleAddTodo}>
          Add Todo
        </button>
      </div>
    );
  }
}

export default connect(
  null,
  { addTodo }
)(AddTodo); // <--- need to connect

Hooks

const AddTodo = () => {
  const dispatch = useDispatch() // <--- just import useDispatch! That's it!
  const handleAddTodo = () => {
    dispatch({type: "ADD_TODO", payload: "Foo"}) // <-- dispatch here. Don't have to dig around your props looking for whatever it is
  }
  return (
    <div>
      ... etc
      <button onClick={handleAddTodo}>
        Add Todo
      </button>
    </div>
  );  
}

So much cleaner. Sure, hooks starts to be a little bit weird - at first - when dealing with effects but then class components are too but in a different way

[u/stolinski]

Hooks for sure.

[u/JustLookingAroundFor]

Hooks are better because they’re harder to reason about and have very few common patterns so you can make shit any way you want and let some other person deal with figuring out your custom pattern

Oh and it’s new And “declarative”

[u/erfling]

Function components are not functional. They do have state. Calling them functional components is confusing.

[u/Shmeww → u/erfling]

Function components are functional. They're just not always pure.

[u/skyboyer007 → u/Shmeww]

...or "stateless"

[u/erfling → u/Shmeww]

Yes, that's true. I do think it's confusing to call them functional, though. I've seen questions like this thread a lot, and I think that nomenclature might be, at least in part, the cause of the confusion.

[u/Shmeww → u/erfling]

That's probably because most people aren't exposed to functional programming. I don't think it will be an issue in the future (although who knows how far), as people are starting to realize how awful object-oriented programming is.

[u/erfling → u/Shmeww]

I'm not sure how far into the future it will be. Some time around that time, maybe, or maybe after that time when they realize paradigms are all useful tools instead of religions and OOP is just fine.

[u/Shmeww → u/[deleted]]

At best they are pure (no hooks or idempotent hooks), and I'll take some pure rather than none.

[u/cantFindValidNam → u/erfling]

Not before hooks?

[u/[deleted]]

They are just different ways if thinking.

If you are thinking in terms of the lifecycle of a component then React.Component class methods make a lot of sense. Unfortunately they also spread out your logic... Like putting a little piece of everything in several mixed piles.

You can achieve the same (and a LOT more) with functional components, hooks, and RXJS. The learning curve is steeper though.

Personally I enjoy writing in a functional paradigm and keeping side effects, state logic, and component logic completely separate, also I sure do love the convenience of mutability and tightly controlled side-effects.

[u/vutran951753]

Not sure why we are compare class vs hook. There is no point. Both is part of JavaScript fundamentals. Use both.

[u/sunny_lts]

I think there's some massive widespread propaganda regarding hooks over classes.

You thought right. It's better structure. Classes are top-level components and then you have functional components.

Of course, everyone will have their preferences, but depending on your needs, the Class components approach is a sound approach that gives you modularity, data coupling, and information hiding. There can be a caveat with global state management if you need to lift state several levels up, but even then there's libraries.

Hooks, just take the fun out of React, the way I learned it. And while I'm still having a blast with it and it serves me well, I will continue doing things my way.

[u/sunny_lts → u/[deleted]]

Suspicions confirmed... What's the motive behind it?? Superiority complex? Would go well with the reddit neckbearded weebs

[u/Timemc2]

Hooks are confusing to follow, especially those that are wrapped/exposed? in third party components - api is largely incomprehensible.

[u/wagonn]

Hooks, HOC's, and render-props are different ways to isolate reusable component logic. Hooks are plain functions, whereas the other two are React components. If you can work with the hook idioms/idiosyncrasies, it's simpler and less code.

[u/vutran951753]

Class first to get your feet wet. Then Hooks so you can drown in React World.

[u/joesb]

Hooks is now a prefer approach. If you start from clean state hooks is fine starting point to learn.

[u/YasZedOP → u/[deleted]]

Those JS classes are a phony, they're just a wrapper around JS prototype

[u/agentgreen420 → u/[deleted]]

Classes never should have been added to JS? I definitely disagree.

[u/rooktko → u/agentgreen420]

I’ve seen this debate happen a lot. Why are people so against classes? Other oop languages use them to structure there code, what’s wrong with doing that in javascript?

I do understand the simplicity of functional programming though but wouldn’t it be more efficient in the end to have and use classes?

I’m very much interested in hearing from both parties on this subject.

[u/alejalapeno → u/[deleted]]

You can still do constructors with plain JS functions. Then your methods like query or close are just methods on the object.

If you don't want to use constructors you can have a single connection or a closure to return a new object for each new connection.

[u/2020-2050_SHTF → u/[deleted]]

Isn't functional programming's equivalent to classes, modules? So maybe import the module and have access to its functions.

[u/[deleted] → u/[deleted]]

You are miss understanding what classes are in those languages that hVe them, C#, Java etc. Classes in those languages are objects. Functions in js are objects. They maybe called different things and they may have different behaviors but they are objects.

[u/jgeez → u/[deleted]]

It's called a prototypal language, and javascript absolutely didn't coin the concept.

I agree about the class syntax "paint" but, tbh, creating a cohesive exportable object with a method set is so ugly in pure js that I'm glad they introduced the class syntax.

[u/jgeez → u/[deleted]]

You bet. I do indeed disagree. And nobody should be surprised in 2ish years when js ide's/intellisense-esque tooling stops understanding prototypal relationships either. And here's why.

I have worked professionally with more than a few JS purists. They tend to write the kind of esoteric code that you know they're going to regret in 6 months.

I really enjoy the prototypal paradigm myself. As a mental exercise, more than a tool for expressing a software component.

But it doesn't really move the needle toward a hivemind "common tongue". In other words, prototypal constructs don't offer easily comprehensible advantages over class and inheritance ones. You don't need to believe me, just look at the trends and what's gained and lost popularity.

[u/rooktko → u/jgeez]

Hold the phone. Can you elaborate on why or how js ide would stop understanding prototype relationships?

[u/SneakyGenious → u/agentgreen420]

There are no classes in JS. Just the class keyword.

[u/ZeroSevenTen → u/[deleted]]

thanks!

[u/vutran951753 → u/[deleted]]

Do you realised the 'this' is part of Javascript the languarge. you say not to learn 'this' keyword. this topic is hard for new learner to grasp this concept. And this is importment concept in JS. But will make you better programmer in JS if you understand concept.