Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Does React Tell a Class from a Function?

overreacted.io

Post reply on HN
Print view View original

91–100 of 142 posts

Re: How Does React Tell a Class from a Function?

#91

Post by prossercj »

danabramov wrote: post #72
quietbritishjim wrote: post #66

Earlier quoted context omitted.

I absolutely agree with you. This makes me very skeptical about the proposed feature in React, called "hooks", which is linked to in the article. It lets you add state to your functional components, and it looks like you end up bundling all your code into one function rather than having a separate constructor to initialise the state (to me, separating out that function is a good thing). I would be interested in the m…

>to me, separating out that function is a good thing To us, too, and that's exactly the point of Hooks. They let you extract logic into functions in a way that wasn't possible before. I suggest to read more than a single page -- in particular, extracting custom Hooks is largely the point of the proposal. https://reactjs.org/docs/hooks-custom.html I also wrote about this here: https://medium.com/@dan_abramov/making-se…

That post has changed my opinion about hooks. I find this gist especially compelling:

https://gist.github.com/gaearon/cb5add26336003ed8c0004c4ba82...

Without hooks, that example would require adding a method (or two) to the component class. With custom hooks, that code can go into a separate module.

Component bloat has been a problem for us, and if hooks can enable components to focus solely on render logic, I'd say that's an improvement.

Re: How Does React Tell a Class from a Function?

#92

Post by econnors »

hoppelhase wrote: post #84
masklinn wrote: post #80

Earlier quoted context omitted.

> What's the rationale for allowing the components to be defined as functions in the first place? Intent: it makes clear that the component is stateless in a way a class-based component does not.

This is why I don't like the hooks concept introduced in the post. It breaks these semantics.

These semantics didn’t exist, anyway. Functional components can hold state through higher order components (eg connected to redux store), render props of children components, etc.

Re: How Does React Tell a Class from a Function?

#93

Post by perfunctory »

wz1000 wrote: post #17

I have written maybe 200 lines of JavaScript in my life, and this article has strongly reinforced my desire to never have to write a single one more. The next time someone asks me what the problem with JavaScript is, I will send them this article. "Scheme for the browser" what a joke. Some excerpts for those that didn't have the strength to sit through the entire thing without pulling their hair out: > If you called…

I guess your downvoters have some sort of Stockholm syndrome.

Javascript is a giant mess and all attempts to fix it seem to make it even worse. Having a sane language in the browser would be the single biggest boost to overall productivity. That alone would push the global gdp up by 5%. At the very least.

Re: How Does React Tell a Class from a Function?

#94

Post by perfunctory »

danabramov wrote: post #78
wz1000 wrote: post #17

I have written maybe 200 lines of JavaScript in my life, and this article has strongly reinforced my desire to never have to write a single one more. The next time someone asks me what the problem with JavaScript is, I will send them this article. "Scheme for the browser" what a joke. Some excerpts for those that didn't have the strength to sit through the entire thing without pulling their hair out: > If you called…

Author here :-) I don't think I disagree with you. JS has its warts and some of them are... weird. The web delivery mechanism has always been its killer feature, not the language. And for web delivery mechanism to work, it needs to maintain backwards compatibility. In practice, however, I think a lot of these things become irrelevant because JS subcommunities carve out reasonable subsets of the language. For example…

> If you limit yourself to avoiding some features then it's not such a bad language after all.

Unfortunately that's not possible unless you never interoperate with other code.

Re: How Does React Tell a Class from a Function?

#95

Post by aaaaaaaaaab »

ttty wrote: post #71
adjkant wrote: post #29

Earlier quoted context omitted.

I really don't get how JS on the client and the server is any real advantage - besides sharing some syntax, the models and paradigms are so drastically different it might as well be two different languages. Why make the server so bad when you don't have to? I think JS has its place despite it's flaws, but for the sake of sanity I can't imagine ever using it on the backend by choice. If you want the ease of express, u…

My code is barely coupled with any server engine. My code is just agnostic. Everything is a function. Then I put some wrapper to connect my function to express API or sockets. My code probably is not aware is running on the client or server, nor should be aware of that. For me works amazingly. I couldn't see myself using anything else on server. It's not hard to pick up a new language, but changing every 5 minutes it…

>My code probably is not aware is running on the client or server, nor should be aware of that.

Client- and server-side are very different in terms of network connectivity, CPU and other resources. On the backend you can get by with N+1 queries if the DB is running on the adjacent VM. On the client side, hardly.

Re: How Does React Tell a Class from a Function?

#96

Post by sametmax »

quietbritishjim wrote: post #66
IMTDb wrote: post #64

Earlier quoted context omitted.

To me it's all about intent. By using a function instead of a class, you are basically saying "future reader, this component is nothing more than a simple mapping from those values to that DOM tree, don't try to look for internal states or any complex treatment here". Sure you could write a "normal React component without state" and do the same, but having those properties baked in the way you defined the component i…

I absolutely agree with you. This makes me very skeptical about the proposed feature in React, called "hooks", which is linked to in the article. It lets you add state to your functional components, and it looks like you end up bundling all your code into one function rather than having a separate constructor to initialise the state (to me, separating out that function is a good thing). I would be interested in the m…

I have this doubt as well.

Hooks will allow people to use "class like" features and behavior, but with none of the conventions forced by syntax, plus some pitfalls.

To me it seems a good way to ensure most devs (espacially unexperienced casual ones, which are legions in JS by nature of the market) will dump their logic wherever it works with as little structure as it allows. It's a technical debt catalyser, and will make sure nobody feels at home in someone else's code. The community will pay the price in a year.

It's also yet another way to do the same thing, and JS has already a lot of those. React as well. Documentations, tutorials and examples will suffer from it. But again, it's very common in JS land where learning anything requires gathering scattered puzzle pieces then assembling them, hoping they are from the same set this time. It allows me to bill more, so I'm not complaining, but it's not fair to newcommers.

Note that I can see some nice things about hooks. I just strongly think they don't outweight the cost by an order of magnitude.

FB idea of ergonomics and user friendliness, in API and UI, has always been to force their way into things, until it blocks, back down, and fix things when possible or use a workaround.

Having been training people in web tech for years, the consequences of such policy show in the classroom. But, hey, more money for me :) Plus when I dev, I have the experience to avoid the pain, mostly knowing when not to do or use things. But I can tell than many of my younger colleagues don't, and a few of my not so young ones too.

Still, I wish they gave a bit more though to this aspects of their products: their are brillant technicians, so it's not that they can't, it's just a matter of culture.

Re: How Does React Tell a Class from a Function?

#97

Post by city41 »

cozos wrote: post #61
arry wrote: post #60

What's the rationale for allowing the components to be defined as functions in the first place? As far as I can see, it has a single thing going for it: saving a line of code, at the expense of jumping through the JavaScript hoops to implement the class/function distinction described in the post. Besides, when the function component evolves and acquires the need for state or other features, the saved line of code goe…

Functions are stateless and I believe can be better optimized. Enforcing statelessness is also a win in itself.

This is true in theory but the React team has not optimized them directly. React.memo is the only way to optimize them thus far.

Re: How Does React Tell a Class from a Function?

#98

Post by orf »

city41 wrote: post #97
cozos wrote: post #61

Earlier quoted context omitted.

Functions are stateless and I believe can be better optimized. Enforcing statelessness is also a win in itself.

This is true in theory but the React team has not optimized them directly. React.memo is the only way to optimize them thus far.

I think he's referring to the optimizations the JIT/engine will do.

Re: How Does React Tell a Class from a Function?

#100

Post by jakelazaroff »

dakom wrote: post #55
reificator wrote: post #41

Earlier quoted context omitted.

While I agree with your point, your example of React literally adds a DSL that requires a pre-compilation step. It's not required[0], I get that, but it's still a new language. [0]: It may not be required, but it was created for a reason....

JSX is not only not required, it's sugar that breaks referential transparency: https://medium.com/@david.chambers/jsx-violates-referential-... Personally I still use it, but I think it's fair to say that as much as JSX was created for a reason, it's made optional for a reason too.

JSX doesn't violate referential transparency. A component either is referentially transparent, or it isn't; nothing about how it's invoked changes that.

Put another way: React calls your components, not you. You pass the component function itself to React.createElement, not its result.

Post reply on HN