Hacker News Reader

Comment by teitoklien | Hacker News Reader

Functional Components are 10x easier and cleaner to use in React

Functional Components are not functional in the sense of functional programming. They are shared mutable state.

Function-based components. They have vaguely functional aspects but they are not functional indeed. I think most people say functional because "function-based" is too long.

If I recall correctly we have stateless functional components (not managing any state). Functional in React should mean immutable state.

You could already use functional components before. The main issue with React now is all these hooks and effects.

The whole point of hooks is to substantially simplify "effects stuff", as compared to the total uncomposability of class components.

While the specific implementation of hooks has its bugbears, I think it's pretty telling that nobody else is using class components either, even in projects with fundamentally different engines like Svelte.

> as compared to the total uncomposability of class components

How do you mean? React components were composable from the get-go; this is practically the definition of a component: you take a piece of ui, you encapsulate it in a component, and then you can compose it with other components into more complex UIs.

Class components were reacting to component's life cycle as opposed to hooks that react to data changes; but there was nothing stopping you from extracting reusable pieces of logic into standalone functions and using them in lifecycle methods.

I thought the whole point of hooks was to support the React fiber architecture, because closures are immutable as opposed to class fields.

Hooks make it easy to compose logic and effects. The actual implementation has some serious warts but the fundamental idea is great.

The React compiler looks like it will eliminate a lot of the error prone manual dependency tracking that usually trips people up with hooks.

I didn't like hooks from the get go because it was the first time I found the automagical behavior that web dev was somewhat leaving behind starting to creep back in.

It's insanely hard (nigh impossible?) to debug an aging app that has use useEffect's and useState's everywhere. (This wasn't the case with the class components (not suggesting that class components were the be and end all))

Now the Compiler sounds nice, and sure there is going to be a lot less code. But, at what cost, it does sound like it's just more magic, moved further and further into the React internals. Which I think unfortunately gives the developer less understanding and power.

I'm just ranting, it's not like the React lib itself is yet entirely divorced from it's principles circa half a decade ago, but I fear it may. Perhaps, they could promote and support more sub packages of React itself e.g. rendering, state

I've seen a lot of JS frameworks come and go. Eventually they all become hard to work with as complexity accretes to address more use cases and keep performance up. The same is true of native frameworks. SwiftUI and Compose are great when you're just getting started but as soon as you start building complex apps things get hairy fast.

I think we still just haven't figured out how to build a UI toolkit that is both highly expressive to use and performant for complex UIs.

I think there are some really great ideas in hooks but it might take a new language built around them to make them truly ergonomic. The React compiler is a step in that direction.

Reply on news.ycombinator.com