4 ms·

>I think hooks is what finally pushed me over the edge towards saying to myself, enough with this insanity. Did you actually build anything with Hooks? I was p

>I think hooks is what finally pushed me over the edge towards saying to myself, enough with this insanity. Did you actually build anything with Hooks? I was pretty turned off by it at first sight as well. It doesn't jive with the sensibilities of a class based OOP developer's natural instincts. But once you start using pure functional components it all makes sense and your code becomes so much cleaner and easier to reason about. No more component lifecycles and massive class files.

jtdev 6y ago
> "once you start using pure functional components it all makes sense and your code becomes so much cleaner and easier to reason about" This is the "Emperor's new clothes" argument that the FP zealots march out over and over again. I guess I'm among the ranks that can't see the clothes.
- aphextron 6y ago
  > This is the "Emperor's new clothes" argument that the FP zealots march out over and over again. I wouldn't call myself a zealot. We chose functional components for a new project on my team as a direct response to problems we were having with maintainability of larger React applications. Specifically that class components tend to get massively bloated over time with business logic, lifecycle based rendering logic, and local state. I was skeptical at first as well. But it turns out that once you start fully separating things out into reducers and actions, the class becomes little more than boilerplate. When you enforce that there are no class members or local state allowed in UI components, it pushes people into proper separation of concerns. The project becomes much more maintainable as you don't have to dig around through components to find out what's going on.
  - awesomepeter 6y ago
    Couldn't you do the same thing with class components though? From what you've mentioned it seems you've mostly moved complicated logic into reducers. I may misunderstand though.
    - aphextron 6y ago
      >Couldn't you do the same thing with class components though? Sure. But the point is that the entire class syntax becomes superfluous once you do that. Everything becomes a pure functional component, and you can just throw in a `useEffect` wherever the need for lifecycle based side effects arises.
  - flowerlad 6y ago
    > Specifically that class components tend to get massively bloated over time with business logic You have been doing it wrong. Don't put business logic into visual components. UI technologies tend to be a fad. Business logic needs to live longer than UI technologies, and needs to be separated from UI components for testability, maintainability, reusability and longevity.
pzuraq 6y ago
When hooks first came out and I started playing with the API, I had the same feeling! It felt refreshing, but I couldn't quite nail down why. I don't think it's that you don't have to worry about lifecycles, in the end. You still do - you have to understand the lifecycles of your functions which are different than those of a component class, but they are lifecycles in there own way. What I think really makes hooks feel nice is you can _close over_ the small, self-contained lifecycles, and introduce them at any point in the program in a composable way. That's pretty neat actually, and what we've taken away from hooks currently. Maybe that's not the only benefit they have, but it's a pretty large one, so I'm glad hooks decided to explore this new direction, even if I'm not completely sold on it (as in, wouldn't introduce it in Ember just yet).
lhorie 6y ago
Isn't that just comparing old code (i.e. code that has grown organically) vs new code (code that hasn't yet)? Surely given enough time you'll end up with just as large/complex a function as an olden class? The proposition of hooks is that they do accomplish the same things as class lifecycle methods do, just in a different way, so all the underlying complexity must still be there by definition. This discussion reminds of this little parable[1] > The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures." Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress. > On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened. [1] https://news.ycombinator.com/item?id=926140 https://news.ycombinator.com/item?id=926140
nobleach 6y ago
What I like about hooks: They ask us to question some long-standing "best practices". I feel like we should do this every so often as it promotes progress in our thinking. What I dislike: They promote patterns that go against long-standing "best practices". (Should we really be defining functions over and over and over again?) So, the biggest advantage, is also my biggest gripe.

jtdev 6y ago

> "once you start using pure functional components it all makes sense and your code becomes so much cleaner and easier to reason about" This is the "Emperor's new clothes" argument that the FP zealots march out over and over again. I guess I'm among the ranks that can't see the clothes.

aphextron 6y ago
> This is the "Emperor's new clothes" argument that the FP zealots march out over and over again. I wouldn't call myself a zealot. We chose functional components for a new project on my team as a direct response to problems we were having with maintainability of larger React applications. Specifically that class components tend to get massively bloated over time with business logic, lifecycle based rendering logic, and local state. I was skeptical at first as well. But it turns out that once you start fully separating things out into reducers and actions, the class becomes little more than boilerplate. When you enforce that there are no class members or local state allowed in UI components, it pushes people into proper separation of concerns. The project becomes much more maintainable as you don't have to dig around through components to find out what's going on.
- awesomepeter 6y ago
  Couldn't you do the same thing with class components though? From what you've mentioned it seems you've mostly moved complicated logic into reducers. I may misunderstand though.
  - aphextron 6y ago
    >Couldn't you do the same thing with class components though? Sure. But the point is that the entire class syntax becomes superfluous once you do that. Everything becomes a pure functional component, and you can just throw in a `useEffect` wherever the need for lifecycle based side effects arises.
- flowerlad 6y ago
  > Specifically that class components tend to get massively bloated over time with business logic You have been doing it wrong. Don't put business logic into visual components. UI technologies tend to be a fad. Business logic needs to live longer than UI technologies, and needs to be separated from UI components for testability, maintainability, reusability and longevity.

pzuraq 6y ago

When hooks first came out and I started playing with the API, I had the same feeling! It felt refreshing, but I couldn't quite nail down why. I don't think it's that you don't have to worry about lifecycles, in the end. You still do - you have to understand the lifecycles of your functions which are different than those of a component class, but they are lifecycles in there own way. What I think really makes hooks feel nice is you can _close over_ the small, self-contained lifecycles, and introduce them at any point in the program in a composable way. That's pretty neat actually, and what we've taken away from hooks currently. Maybe that's not the only benefit they have, but it's a pretty large one, so I'm glad hooks decided to explore this new direction, even if I'm not completely sold on it (as in, wouldn't introduce it in Ember just yet).

lhorie 6y ago

Isn't that just comparing old code (i.e. code that has grown organically) vs new code (code that hasn't yet)? Surely given enough time you'll end up with just as large/complex a function as an olden class? The proposition of hooks is that they do accomplish the same things as class lifecycle methods do, just in a different way, so all the underlying complexity must still be there by definition. This discussion reminds of this little parable[1] > The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures." Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress. > On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened. [1] https://news.ycombinator.com/item?id=926140 https://news.ycombinator.com/item?id=926140

nobleach 6y ago

What I like about hooks: They ask us to question some long-standing "best practices". I feel like we should do this every so often as it promotes progress in our thinking. What I dislike: They promote patterns that go against long-standing "best practices". (Should we really be defining functions over and over and over again?) So, the biggest advantage, is also my biggest gripe.