18 ms·

> In our observation, classes are the biggest barrier to learning React. As someone who struggled hard with some aspects of learning react, i felt this to be t

> In our observation, classes are the biggest barrier to learning React. As someone who struggled hard with some aspects of learning react, i felt this to be the absolute opposite. Watching people to combine and spread logic over dozens of functional components, and drag in other external libraries like recompose to do stuff like lifecycle hooks, and using HoC's, just to avoid classes makes my head hurt. > Only call Hooks at the top level. Don’t call Hooks inside loops, conditions, or nested functions. I really don't like this, and to me this feels really finicky, and unfortunately the explanation doesn't make me feel warm and fuzzy ether. While it is great they are adding a linter plugin for it, i feel like this is going to be really easy to shoot yourself in the foot, and feels like it is relying on behind the scenes magic too much.

bendavis381 8y ago
I agree. Optimizing a developer library for developers who struggle to understand what a class is seems like a good way to build something very convoluted.
- ergothus 8y ago
  I don't think the issue is "what is a class". It's more that the lifecycle functions get tied into the class, and you end up with a ball of highly conditional logic. It's easy for newbies to just add stuff to make it work, but end up with a mess. React is the view layer, so the class concept of "here's some data and methods to alter it" doesn't really match with what happens - I don't know that components every should have been classes in the first place.
  - xab9 8y ago
    According to the article yes, the issue is "what is a class": "You have to understand how this works in JavaScript, which is very different from how it works in most languages. You have to remember to bind the event handlers." etc.
    - ergothus 8y ago
      Can't argue with the text of the article. I do, however, stand by why _I_ have found that classes are a bad match for this need, and watching the video of the demo did a much better job of suggesting the benefits and reasoning...reasons that don't really match the parts of the article you've quoted. https://www.youtube.com/watch?v=kz3nVya45uQ&t=39m https://www.youtube.com/watch?v=kz3nVya45uQ&t=39m (from elsewhere in the comments here)
      - visarga 8y ago
        >Video unavailable. This video contains content from WebTVAsia (Music), who has blocked it on copyright grounds. LOL, did they just block a video presentation for some incidental random music in the background?
    - wild_preference 8y ago
      Eh, even in the same paragraph it says "The distinction between function and class components in React and when to use each one leads to disagreements even between experienced React developers." Also, bits of class issues show up in the other complaints. So, no, it's not just "what is a class" and it's a weird hill to die on. I feel like most of these responses to hooks in general just focus on the most trivial detail aka bikeshedding.
      - xab9 8y ago
        I'm focusing on classes, because it seems to me that to "React" classes are a necessary evil (or they are treating them like they were). Hooks, suspense, context wormholes - I'm not sure if these features should be part of a view engine. React, to me, did one thing and did it well, but now... I don't know.
- tracker1 8y ago
  There are other ways to approach an issue beyond shoving everything into a class. I'm not sure I really like the new hooks over the state methods at that level since I tend to separate global state (redux) vs component state (class) vs component state rendering (functional component). In the end it depends on your style. I think this might be useful in a way that can be more pure than some other methods might be.
  - AlexCoventry 8y ago
    I don't know what you mean by pure. There is nothing reverentially transparent about the new API. (Nor can there be, really.)
    - tracker1 8y ago
      And nothing that requires you to use the new API.
- Vinnl 8y ago
  It's not just having to understand what a class is, it's also having to know and remember to add a constructor to your class just to call `this.handleSomeEvent = this.handleSomeEvent.bind(this)`. Sure, I know what it does and why it is needed, but it is ugly, cumbersome, and I keep forgetting it nonetheless.
  - beaconstudios 8y ago
    there are babel solutions to this pain: - https://www.npmjs.com/package/babel-plugin-autobind-class-methods https://www.npmjs.com/package/babel-plugin-autobind-class-me... - https://www.npmjs.com/package/babel-plugin-transform-class-properties https://www.npmjs.com/package/babel-plugin-transform-class-p...
paultannenbaum 8y ago
While I do agree that higher order components are not the most beginner friendly pattern, to state that they are being used just to avoid classes completely misses the points of why they are used. They are a functional pattern that help one create pure components.
- pgrizzay 8y ago
  Yup! they can be tested separately and introduce a separation of concerns that is much better than a "simple" class that "just has everything in it". (Which usually leads to mounds of copy-paste code)
btown 8y ago
You also can call functions that call functions that set up hooks. What if those functions have control flow? Must we build linters that recursively taint any hook-touching code segments? Since Fiber, React has become difficult to reason about. There is a stateful crawler that is going up and down and sideways in your hierarchy, running code with side effects and telling you that it will isolate those side effects. The golden brick road is surrounded by briars, because you cannot know the nuances of that renderer’s contracts, because you cannot read the code of that renderer, because it’s too dense to understand. I miss the days when React was a simpler “dive” than Angular in this regard, and I could boast about its simplicity. In the interest of efficiency, we have forgotten how to climb the walls of our garden.
- circlesguy 8y ago
  >> React has become difficult to reason about Absolutely. React started off simple but with things like Redux added on, it has become unnecessarily complex. The performance benefits of React is overrated. Javascript is so fast these days that you can rerender the whole page on navigation and no one will know the difference. I built a whole social network site based on a simpler alternative, UIBuilder, and you can see for yourself that it is performant: https://circles.app https://circles.app UIBuilder is here: https://github.com/wisercoder/uibuilder https://github.com/wisercoder/uibuilder
- engineeringwoke 8y ago
  But they needed Fiber to make AsyncMode possible And once it's well baked enough, it works very cleanly with universal rendering strategies. It means you don't have to separate logic into components where it doesn't belong because the server render ignores loading logic in componentDidMount. It's suddenly all first class And, then, theoretically you can remove Redux and just use Context It has gotten really wacky along the way. I hope they don't lose sight
taternuts 8y ago
> and using HoC's, just to avoid classes makes my head hurt I don't know if it's just something I don't see that often and aren't that familiar with, but I also can't stand the overuse of HoC's for this purpose. Seen some very clever and very, very unreadable HoC's so far and I hate working on codebases that use them liberally.
- tracker1 8y ago
  I think it depends on the use... I think some can be ugly... right now react-loadable and a custom InRoles component are the two I'm using the most. One is for loading state and code-splitting, the other is for allow/deny state... <InRoles roles={[...]} allow={() => <Component ...props />} deny={'/route' /* or a render, or skip */} /> InRoles works for a router redirect, displaying alternate content or no content. In the end it depends on what you're trying to accomplish. HoC's are pretty useful. Also, it really helps in terms of unit testing your more functional components.
  - taternuts 8y ago
    I think the HoC's that get me the most are the ones written by JS devs who think 100% functionally. Actually a lot of the hard ones to grok were written by Jason Miller of the Preact fame, who seems to think out JS in a minified, functional fashion. I've had to step through and re-write several things just to see what was actually happening, then pare it back to it's original form before I "get it". It's super clever, but man did it take me a while to distill it's logic.
ergothus 8y ago
I can see both sides. I teach React to newish coders, and classes are easy for them to grasp...and then immediately create labyrinthine monoliths. At work where I do React, we emphasize small components with limited and segmented logic (ideally pulling as much logic out of the React parts as possible - and this is most easily done by avoiding classes). At the same time, I've a passion for trying to make code more maintainable - which often means avoiding too much abstraction and keeping logic plain and up-front, where it can be found and followed, so I share some of your concerns. But I'm excited about this. One of the best parts of React has been that the same logic that makes a good program makes for a good react app. Treat your components like functions (regardless of whether they are classes or not) - small, single purpose, decoupled from state - and you'll have an easier time. Hooks look to help that.
- munchbunny 8y ago
  I can see both sides. I teach React to newish coders, and classes are easy for them to grasp...and then immediately create labyrinthine monoliths. To be fair, that's pretty much what happens to all newish coders who are learning classes. Learning to use classes responsibly is really just part of the learning, though that seems to be the part that instructors pawn off to the next guy. Once you learn how to use them judiciously, classes become extremely useful tools for encapsulation/abstraction where you need encapsulation/abstraction.
  - xab9 8y ago
    Maybe newish coders should learn the language they are using. And of course there is typescript (and a gazillion of languages that can be transpiled to js these days), which synergizes very well with enterprise people and java/dotnet devs who never did a line of frontend before.
    - munchbunny 8y ago
      Maybe newish coders should learn the language they are using. It's not a language thing. OOP discipline is a coding thing in general. And of course there is typescript (and a gazillion of languages that can be transpiled to js these days), which synergizes very well with enterprise people and java/dotnet devs who never did a line of frontend before. You sound like you don't actually understand why people like Typescript, or, more specifically, static typing.
sdegutis 8y ago
React is intended to be a view-only library but in practice people shove all their business logic in there, mostly because React makes it incredibly hard to do anything else. Because of this, innovations in React are going in the wrong direction. This Hooks feature is meant to solve a portion of this, but it's going in the wrong direction. A better bigger-picture innovation would be to have a React-alike that is actually only the view layer, and makes it significantly easier to write your business logic using plain old JavaScript functions/classes. Ideally it would have an API that encourages you to write your business logic as a hierarchy of state machines, because that's what apps really are. But the state management should definitely be done outside React, similar to what Redux has done, where your actual state is transformed into props and passed into React. Also, screw you HN for always penalizing my account so that my content shows up at the bottom instead of the top and has no chance of being seen. My content is good, your algorithms suck.
- boubiyeah 8y ago
  React was never a view-only library. Pete Hunt always said he saw React components as mini MVC modules. it's even less true nowadays with features like Context or suspense to supplement the component states. Redux was kind of a temporary hack.
  - sdegutis 8y ago
    I distinctly remember the phrase "V in MVC" being prominently displayed somewhere on the official React website(s). Found it: https://web.archive.org/web/20140329114924/http://facebook.github.io:80/react/ https://web.archive.org/web/20140329114924/http://facebook.g... > JUST THE UI > Lots of people use React as the V in MVC. Since React makes no assumptions about the rest of your technology stack, it's easy to try it out on a small feature in an existing project. So I was mistaken. It didn't say that's what it's only intended for, but that's what many people use it for. Either way, it's not great at the M or C parts of MVC. Context does very little to ease that pain. Redux was more manageable but also overly complex, but it's only React's design that forced it to be so complex.
    - 8y ago
pier25 8y ago
> i felt this to be the absolute opposite I completely agree. When I started using React a couple of years ago, the only thing that made sense were the classes. The bad aspect about React and JSX is that in general there are way too many JS acrobatics which alienates everyone from the codebase who isn't a JS ninja.
eloff 8y ago
I feel the same way! Maybe I'm just getting older, but I like code to be boring. A class is something everyone can read and understand. If you have to navigate a maze of HOCs withStateHandlers, enchancers, redux actions, reducers and connectors you end up needing to open 10-20 files and jump around between as many functions to build a picture of how a component works. Considering code is read more often than written - that seems like a huge step backwards. Hi, I'm Dan. I write boring code. I love Go because it's super boring. I like to read boring code, write boring code, and then get on with my day. I don't like long walks through the codebase trying to understand how everything is wired up in a super-cool functional way. Get off my lawn kids.
- dstroot 8y ago
  OMG. I am Dan also. I am getting older also. I LOVE Go also! Too funny but we are living parallel lives. Now get off MY lawn!
- kickpush1 8y ago
  Amen!
- metamet 8y ago
  Mmm pointers.
- asragab 8y ago
  What's actually funny here, is that maybe you aren't old enough. The "Super-cool" functional way has been around as long as types and functions, Lisp and ML have been around since the what...50's and 70's respectively. Immutable state and referential transparency are boring. Get off MY LAWN kid!
- beaconstudios 8y ago
  functional javascript can increase code clarity if written well. Certainly ramda is usually a huge improvement when making mutations in a reducer. compose()'ing a bunch of HOCs is essentially the same as having mixins (and it's exactly the same as @decorators), just with a slightly different syntax. I think it's mostly down to the paradigm you're most familiar with. Classes are normal to OO developers, functional composition is normal to FP developers.
sophiebits 8y ago
(I work on React.) I think we’re on the same page here. Having a pile of recompose helpers and HOCs is exactly what we think/hope Hooks will help avoid.
christopherscot 8y ago
In my experience classes are one of the few boring, easily understood parts of react for almost everyone I mentor/work with.

bendavis381 8y ago

I agree. Optimizing a developer library for developers who struggle to understand what a class is seems like a good way to build something very convoluted.

ergothus 8y ago
I don't think the issue is "what is a class". It's more that the lifecycle functions get tied into the class, and you end up with a ball of highly conditional logic. It's easy for newbies to just add stuff to make it work, but end up with a mess. React is the view layer, so the class concept of "here's some data and methods to alter it" doesn't really match with what happens - I don't know that components every should have been classes in the first place.
- xab9 8y ago
  According to the article yes, the issue is "what is a class": "You have to understand how this works in JavaScript, which is very different from how it works in most languages. You have to remember to bind the event handlers." etc.
  - ergothus 8y ago
    Can't argue with the text of the article. I do, however, stand by why _I_ have found that classes are a bad match for this need, and watching the video of the demo did a much better job of suggesting the benefits and reasoning...reasons that don't really match the parts of the article you've quoted. https://www.youtube.com/watch?v=kz3nVya45uQ&t=39m https://www.youtube.com/watch?v=kz3nVya45uQ&t=39m (from elsewhere in the comments here)
    - visarga 8y ago
      >Video unavailable. This video contains content from WebTVAsia (Music), who has blocked it on copyright grounds. LOL, did they just block a video presentation for some incidental random music in the background?
  - wild_preference 8y ago
    Eh, even in the same paragraph it says "The distinction between function and class components in React and when to use each one leads to disagreements even between experienced React developers." Also, bits of class issues show up in the other complaints. So, no, it's not just "what is a class" and it's a weird hill to die on. I feel like most of these responses to hooks in general just focus on the most trivial detail aka bikeshedding.
    - xab9 8y ago
      I'm focusing on classes, because it seems to me that to "React" classes are a necessary evil (or they are treating them like they were). Hooks, suspense, context wormholes - I'm not sure if these features should be part of a view engine. React, to me, did one thing and did it well, but now... I don't know.
tracker1 8y ago
There are other ways to approach an issue beyond shoving everything into a class. I'm not sure I really like the new hooks over the state methods at that level since I tend to separate global state (redux) vs component state (class) vs component state rendering (functional component). In the end it depends on your style. I think this might be useful in a way that can be more pure than some other methods might be.
- AlexCoventry 8y ago
  I don't know what you mean by pure. There is nothing reverentially transparent about the new API. (Nor can there be, really.)
  - tracker1 8y ago
    And nothing that requires you to use the new API.
Vinnl 8y ago
It's not just having to understand what a class is, it's also having to know and remember to add a constructor to your class just to call `this.handleSomeEvent = this.handleSomeEvent.bind(this)`. Sure, I know what it does and why it is needed, but it is ugly, cumbersome, and I keep forgetting it nonetheless.
- beaconstudios 8y ago
  there are babel solutions to this pain: - https://www.npmjs.com/package/babel-plugin-autobind-class-methods https://www.npmjs.com/package/babel-plugin-autobind-class-me... - https://www.npmjs.com/package/babel-plugin-transform-class-properties https://www.npmjs.com/package/babel-plugin-transform-class-p...

paultannenbaum 8y ago

While I do agree that higher order components are not the most beginner friendly pattern, to state that they are being used just to avoid classes completely misses the points of why they are used. They are a functional pattern that help one create pure components.

pgrizzay 8y ago
Yup! they can be tested separately and introduce a separation of concerns that is much better than a "simple" class that "just has everything in it". (Which usually leads to mounds of copy-paste code)

btown 8y ago

You also can call functions that call functions that set up hooks. What if those functions have control flow? Must we build linters that recursively taint any hook-touching code segments? Since Fiber, React has become difficult to reason about. There is a stateful crawler that is going up and down and sideways in your hierarchy, running code with side effects and telling you that it will isolate those side effects. The golden brick road is surrounded by briars, because you cannot know the nuances of that renderer’s contracts, because you cannot read the code of that renderer, because it’s too dense to understand. I miss the days when React was a simpler “dive” than Angular in this regard, and I could boast about its simplicity. In the interest of efficiency, we have forgotten how to climb the walls of our garden.

circlesguy 8y ago
>> React has become difficult to reason about Absolutely. React started off simple but with things like Redux added on, it has become unnecessarily complex. The performance benefits of React is overrated. Javascript is so fast these days that you can rerender the whole page on navigation and no one will know the difference. I built a whole social network site based on a simpler alternative, UIBuilder, and you can see for yourself that it is performant: https://circles.app https://circles.app UIBuilder is here: https://github.com/wisercoder/uibuilder https://github.com/wisercoder/uibuilder
engineeringwoke 8y ago
But they needed Fiber to make AsyncMode possible And once it's well baked enough, it works very cleanly with universal rendering strategies. It means you don't have to separate logic into components where it doesn't belong because the server render ignores loading logic in componentDidMount. It's suddenly all first class And, then, theoretically you can remove Redux and just use Context It has gotten really wacky along the way. I hope they don't lose sight

taternuts 8y ago

> and using HoC's, just to avoid classes makes my head hurt I don't know if it's just something I don't see that often and aren't that familiar with, but I also can't stand the overuse of HoC's for this purpose. Seen some very clever and very, very unreadable HoC's so far and I hate working on codebases that use them liberally.

tracker1 8y ago
I think it depends on the use... I think some can be ugly... right now react-loadable and a custom InRoles component are the two I'm using the most. One is for loading state and code-splitting, the other is for allow/deny state... <InRoles roles={[...]} allow={() => <Component ...props />} deny={'/route' /* or a render, or skip */} /> InRoles works for a router redirect, displaying alternate content or no content. In the end it depends on what you're trying to accomplish. HoC's are pretty useful. Also, it really helps in terms of unit testing your more functional components.
- taternuts 8y ago
  I think the HoC's that get me the most are the ones written by JS devs who think 100% functionally. Actually a lot of the hard ones to grok were written by Jason Miller of the Preact fame, who seems to think out JS in a minified, functional fashion. I've had to step through and re-write several things just to see what was actually happening, then pare it back to it's original form before I "get it". It's super clever, but man did it take me a while to distill it's logic.

ergothus 8y ago

I can see both sides. I teach React to newish coders, and classes are easy for them to grasp...and then immediately create labyrinthine monoliths. At work where I do React, we emphasize small components with limited and segmented logic (ideally pulling as much logic out of the React parts as possible - and this is most easily done by avoiding classes). At the same time, I've a passion for trying to make code more maintainable - which often means avoiding too much abstraction and keeping logic plain and up-front, where it can be found and followed, so I share some of your concerns. But I'm excited about this. One of the best parts of React has been that the same logic that makes a good program makes for a good react app. Treat your components like functions (regardless of whether they are classes or not) - small, single purpose, decoupled from state - and you'll have an easier time. Hooks look to help that.

munchbunny 8y ago
I can see both sides. I teach React to newish coders, and classes are easy for them to grasp...and then immediately create labyrinthine monoliths. To be fair, that's pretty much what happens to all newish coders who are learning classes. Learning to use classes responsibly is really just part of the learning, though that seems to be the part that instructors pawn off to the next guy. Once you learn how to use them judiciously, classes become extremely useful tools for encapsulation/abstraction where you need encapsulation/abstraction.
- xab9 8y ago
  Maybe newish coders should learn the language they are using. And of course there is typescript (and a gazillion of languages that can be transpiled to js these days), which synergizes very well with enterprise people and java/dotnet devs who never did a line of frontend before.
  - munchbunny 8y ago
    Maybe newish coders should learn the language they are using. It's not a language thing. OOP discipline is a coding thing in general. And of course there is typescript (and a gazillion of languages that can be transpiled to js these days), which synergizes very well with enterprise people and java/dotnet devs who never did a line of frontend before. You sound like you don't actually understand why people like Typescript, or, more specifically, static typing.

sdegutis 8y ago

React is intended to be a view-only library but in practice people shove all their business logic in there, mostly because React makes it incredibly hard to do anything else. Because of this, innovations in React are going in the wrong direction. This Hooks feature is meant to solve a portion of this, but it's going in the wrong direction. A better bigger-picture innovation would be to have a React-alike that is actually only the view layer, and makes it significantly easier to write your business logic using plain old JavaScript functions/classes. Ideally it would have an API that encourages you to write your business logic as a hierarchy of state machines, because that's what apps really are. But the state management should definitely be done outside React, similar to what Redux has done, where your actual state is transformed into props and passed into React. Also, screw you HN for always penalizing my account so that my content shows up at the bottom instead of the top and has no chance of being seen. My content is good, your algorithms suck.

boubiyeah 8y ago
React was never a view-only library. Pete Hunt always said he saw React components as mini MVC modules. it's even less true nowadays with features like Context or suspense to supplement the component states. Redux was kind of a temporary hack.
- sdegutis 8y ago
  I distinctly remember the phrase "V in MVC" being prominently displayed somewhere on the official React website(s). Found it: https://web.archive.org/web/20140329114924/http://facebook.github.io:80/react/ https://web.archive.org/web/20140329114924/http://facebook.g... > JUST THE UI > Lots of people use React as the V in MVC. Since React makes no assumptions about the rest of your technology stack, it's easy to try it out on a small feature in an existing project. So I was mistaken. It didn't say that's what it's only intended for, but that's what many people use it for. Either way, it's not great at the M or C parts of MVC. Context does very little to ease that pain. Redux was more manageable but also overly complex, but it's only React's design that forced it to be so complex.
  - 8y ago

pier25 8y ago

> i felt this to be the absolute opposite I completely agree. When I started using React a couple of years ago, the only thing that made sense were the classes. The bad aspect about React and JSX is that in general there are way too many JS acrobatics which alienates everyone from the codebase who isn't a JS ninja.

eloff 8y ago

I feel the same way! Maybe I'm just getting older, but I like code to be boring. A class is something everyone can read and understand. If you have to navigate a maze of HOCs withStateHandlers, enchancers, redux actions, reducers and connectors you end up needing to open 10-20 files and jump around between as many functions to build a picture of how a component works. Considering code is read more often than written - that seems like a huge step backwards. Hi, I'm Dan. I write boring code. I love Go because it's super boring. I like to read boring code, write boring code, and then get on with my day. I don't like long walks through the codebase trying to understand how everything is wired up in a super-cool functional way. Get off my lawn kids.

dstroot 8y ago
OMG. I am Dan also. I am getting older also. I LOVE Go also! Too funny but we are living parallel lives. Now get off MY lawn!
kickpush1 8y ago
Amen!
metamet 8y ago
Mmm pointers.
asragab 8y ago
What's actually funny here, is that maybe you aren't old enough. The "Super-cool" functional way has been around as long as types and functions, Lisp and ML have been around since the what...50's and 70's respectively. Immutable state and referential transparency are boring. Get off MY LAWN kid!
beaconstudios 8y ago
functional javascript can increase code clarity if written well. Certainly ramda is usually a huge improvement when making mutations in a reducer. compose()'ing a bunch of HOCs is essentially the same as having mixins (and it's exactly the same as @decorators), just with a slightly different syntax. I think it's mostly down to the paradigm you're most familiar with. Classes are normal to OO developers, functional composition is normal to FP developers.

sophiebits 8y ago

(I work on React.) I think we’re on the same page here. Having a pile of recompose helpers and HOCs is exactly what we think/hope Hooks will help avoid.

christopherscot 8y ago

In my experience classes are one of the few boring, easily understood parts of react for almost everyone I mentor/work with.