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

Introducing Hooks

reactjs.org

Post reply on HN
Print view View original

241–250 of 310 posts

Re: Introducing Hooks

#241

Post by xab9 »

wild_preference wrote: post #159
xab9 wrote: post #124

Earlier quoted context omitted.

According to the article yes, the issue is "what is a class": "You have to understand how this works in JavaScript, which is very different from how it works in most languages. You have to remember to bind the event handlers." etc.

Eh, even in the same paragraph it says "The distinction between function and class components in React and when to use each one leads to disagreements even between experienced React developers." Also, bits of class issues show up in the other complaints. So, no, it's not just "what is a class" and it's a weird hill to die on. I feel like most of these responses to hooks in general just focus on the most trivial detai…

I'm focusing on classes, because it seems to me that to "React" classes are a necessary evil (or they are treating them like they were).

Hooks, suspense, context wormholes - I'm not sure if these features should be part of a view engine. React, to me, did one thing and did it well, but now... I don't know.

Re: Introducing Hooks

#242

Post by xab9 »

munchbunny wrote: post #154
xab9 wrote: post #127

Earlier quoted context omitted.

Maybe newish coders should learn the language they are using. And of course there is typescript (and a gazillion of languages that can be transpiled to js these days), which synergizes very well with enterprise people and java/dotnet devs who never did a line of frontend before.

Maybe newish coders should learn the language they are using. It's not a language thing. OOP discipline is a coding thing in general. And of course there is typescript (and a gazillion of languages that can be transpiled to js these days), which synergizes very well with enterprise people and java/dotnet devs who never did a line of frontend before. You sound like you don't actually understand why people like Typescr…

I "don't actually understand why people like Typescript", or lemonade, or skiing, or eating fish. I know why I like it, including static typing, and how I can find a balance with using its features (and not using some).

On the other hand I'm not trying to hide that I'm bitter about the mental lazyness around typescript - I had some bad experience with interviewers who praised ts (without ever bothering to learn the core principles of javascript) a bit too much for my taste (but again, this may just be dismissed as anecdotal evidence, which it is).

Re: Introducing Hooks

#243

Post by nahfamwegood »

Man, they really ruined React.

I remember when it was AWESOME, back in 2013 when only me and like 10 people were using it and the API was simple because it was brand new.

ugh, now I have to read a bit more and have all these new features. I'm an engineer, I only like things when they're simple.

I wish it was back in the simpler days when JQUERY was hot. Man, miss those days for sure.

Re: Introducing Hooks

#244

Post by boubiyeah »

schneidmaster wrote: post #16
ggregoire wrote: post #4

While I agree that class components has always felt like a workaround to bypass the limitations of function components, and that it's obviously annoying to rewrite a function component to a class component just to add a state or a lifecycle method, the following explanation sounds a bit silly to me: > In our observation, classes are the biggest barrier to learning React. You have to understand how this works in JavaS…

In the live talk, Sophie also discussed how Javascript classes are difficult for machines: minifiers aren't able to shorten the names of methods (because it's apparently hard to work out all the ways that the method could be invoked), and they cause stability problems with hot code reloading. So there are benefits beyond ease of use for humans. (Also, I'm pretty fluent in Javascript and I still forget to bind event h…

Of course it's unintuitive. I see dev veterans make the mistake all the time.

JS was so poorly designed. An implicit (not passed as an arg), dynamic this parameter. You couldn't be more cheeky than that really.

something like console.log.bind(console.log) is beyond silly. It's what we're stuck with but I will minimize the occurences of that kind of crap any single time I can.

Re: Introducing Hooks

#245

Post by visarga »

ergothus wrote: post #136
xab9 wrote: post #124

Earlier quoted context omitted.

According to the article yes, the issue is "what is a class": "You have to understand how this works in JavaScript, which is very different from how it works in most languages. You have to remember to bind the event handlers." etc.

Can't argue with the text of the article. I do, however, stand by why _I_ have found that classes are a bad match for this need, and watching the video of the demo did a much better job of suggesting the benefits and reasoning...reasons that don't really match the parts of the article you've quoted. https://www.youtube.com/watch?v=kz3nVya45uQ&t=39m (from elsewhere in the comments here)

>Video unavailable. This video contains content from WebTVAsia (Music), who has blocked it on copyright grounds.

LOL, did they just block a video presentation for some incidental random music in the background?

Re: Introducing Hooks

#246

Post by DougBTX »

scq wrote: post #234
badestrand wrote: post #226

Earlier quoted context omitted.

The problem is that the hooks seem to be much more restricting than setState. You can `if (condition) this.setState({x: 1})` but you can not with hooks because React keeps track and doesn't allow you to break out of a very narrow usage. Look at the rules from the docs: > Only call Hooks at the top level. Don’t call Hooks inside loops, conditions, or nested functions. > Only call Hooks from React function components.…

I think those rules only apply to useState and useEffect themselves, and not to the setState function you get back when you call useState.

Yes, I think you’re right, there are different restrictions on when useState and setState, though it is worrying seeing confusion straight away about it.

I wonder about a case where there is an expandable panel in a UI, and when expanded it should fetch then display data from a web service. Easy enough to do with this API by splitting the content of the panel out into a second component, but it is going to be very tempting to wrap that useEffect fetch call in an `if (expanded)` condition.

On the other hand, there are lots of positives about this design too, the correctly written code does look very elegant and I can see it solving real problems.

Re: Introducing Hooks

#247

Post by Vinnl »

acemarke wrote: post #168
wereHamster wrote: post #167

Earlier quoted context omitted.

The 'this' in 'this.setState()' tells react which component queued the setState. With the new API that information is collected by react through.. ehm.. some kind of magic. I understand why the react developers chose not to make the component an explicit argument in the new API, as it would open doors to misuse. But magic never seems to work out in the long run, IME.

I'd agree it's "magic" in the sense that it's not entirely visible to the end user. But, the key is that React is _already_ tracking _which_ component it renders as it traverses through the component tree. It's just now also keeping track of some additional data as it goes through the process of rendering that component. So in that sense, it's not any more "magical" than any of the existing render algorithm.

> I'd agree it's "magic" in the sense that it's not entirely visible to the end user.

I didn't dive into hooks to completely yet to have a proper opinion on it, but the primary disadvantage of "magic" is that the end user can not deduce what's going on just by looking at the code. If magic is therefore "only" restricted to the end user, that's not much of a restriction...

Re: Introducing Hooks

#248

Post by Vinnl »

bendavis381 wrote: post #29
sadturnip wrote: post #27

> In our observation, classes are the biggest barrier to learning React. As someone who struggled hard with some aspects of learning react, i felt this to be the absolute opposite. Watching people to combine and spread logic over dozens of functional components, and drag in other external libraries like recompose to do stuff like lifecycle hooks, and using HoC's, just to avoid classes makes my head hurt. > Only call…

I agree. Optimizing a developer library for developers who struggle to understand what a class is seems like a good way to build something very convoluted.

It's not just having to understand what a class is, it's also having to know and remember to add a constructor to your class just to call `this.handleSomeEvent = this.handleSomeEvent.bind(this)`.

Sure, I know what it does and why it is needed, but it is ugly, cumbersome, and I keep forgetting it nonetheless.

Re: Introducing Hooks

#249

Post by jf- »

markmark wrote: post #182
jf- wrote: post #122

Earlier quoted context omitted.

I think the Angular resentment is a little behind the times, the days of Angularjs 1 and the beta versions of Angular 2 are behind us. The new Angular is worth a look, especially if react is now having various extras bolted on ad hoc.

> the days of Angularjs 1 and the beta versions of Angular 2 are behind us There is still a _heap_ of Angular 1 code out there since the 1 -> 2 move basically meant you couldn't upgrade without a full rewrite. Both my last two jobs have involved re-writing Angular 1 apps.

Sure, there are lots of Angular 1 apps still in production, as there will be with most legacy systems. My point is that Angular 1 is no longer the current version, and with the latest version it’s much better to use. I think the main issue is the learning curve, but you just have to bite the bullet.

Re: Introducing Hooks

#250

Post by jf- »

tracker1 wrote: post #197
jf- wrote: post #112

Earlier quoted context omitted.

Out of curiosity, have you actually tried the latest version of Angular to see if your preference does hold up? It’s come quite a way since the bad old days.

I can't speak for GP, but have used angular up through 4.x (not quite current) and don't find it better than React's ecosystem imho. With React I can often bring in additional components and libraries without friction. With Angular it feels like doing anything means significant friction. And heaven help you if you want to change the way something internal works, or work around things.

I can’t say I’ve had that much trouble bringing in third party libraries, nor have I had a need to change how the framework works internally. I think this is the same as with most frameworks, you tend to just use them rather than doing stuff under the hood. Can you give an example?
Post reply on HN