Hacker News Reader

Comment by dylanowen | Hacker News Reader

100% this. Reading complex functional components is challenging because you're creating the functionality of a class with non of the organization.

View on HN

How do you mean? Imo it's easier to organize as you can split up your logic into normal functions and custom hooks (which are also just functions).

I also find functions much easier to read as there is no "this" and you can simply read them top to bottom for order of execution.

So I spent some more time reading through using HOCs in React and I think I'll have to give functional components more of a try. The specific example I was thinking of is https://github.com/graphql/graphiql/blob/50674292c55eadf0e61... but this component will probably always be complex because of the Codemirror interaction.

Nice! I think you might like it.

Ah yeah, that does take a while to unpack. I think a lot of the complexity there is dealing with a non-react library and the dynamic import(s). Binding non-react libraries can be a bit rough.

I do think it's a good example to show the big advantage of hooks, if you look at the use of the hook, super clean: https://github.com/graphql/graphiql/blob/50674292c55eadf0e61...

Great way to contain complexity and make usage really clean and simple!

React functional components are not supposed to be complex. It's easier to split FCs up than in Vue for example. Even React's class based components discourage splitting components by adding more boilerplate.

Reply on news.ycombinator.com