4 ms·

> "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

• 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.