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

191–200 of 310 posts

Re: Introducing Hooks

#191

Post by fiatjaf »

anonytrary wrote: post #137

Unpopular opinion: There are too many cooks. I used React two years ago because the API was tiny, simple and elegant. They are adding new API features left and right, and the framework feels very uncoordinated now. The surface area is way bigger than it needs to be. This is my cue to finally explore other frameworks.

I agree with you, but I've also tried other frameworks and there isn't a single one that is all-around better than React.

Unless you're willing to migrate to other compile-to-js languages.

Re: Introducing Hooks

#192

Post by dceddia »

see-dante wrote: post #74

I don't dig what they're doing, but I do kind of like the idea of a deconstructed getter/setter: [ get, set ] = getterSetter(defaultValue) as a wrapper around some stateful, immutable value (mutating the result of the get won't be tracked, that is)

That's pretty much what useState does. (or maybe you were already saying you liked that -- sorry, if that's what you meant) The only difference being that the "getter" has already been "executed" in a way: useState returns a value and a setter. Changing the value won't get tracked, and a call to the setter will overwrite the old value and re-render.

Re: Introducing Hooks

#193

Post by fiatjaf »

Everybody is complaining. I like this. Classes should be abolished, though. And perhaps this should be published as a different React version, like "React Classless" or whatever.

Classes with special method names, manual binding of methods, mixed ways of doing things (inlining a function or defining it separatedly?) are a mess already, and this will arguably add more to the mess, but the intentions are good.

Re: Introducing Hooks

#194

Post by tracker1 »

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.

There are other ways to approach an issue beyond shoving everything into a class. I'm not sure I really like the new hooks over the state methods at that level since I tend to separate global state (redux) vs component state (class) vs component state rendering (functional component).

In the end it depends on your style. I think this might be useful in a way that can be more pure than some other methods might be.

Re: Introducing Hooks

#195

Post by tracker1 »

taternuts wrote: post #79
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…

> and using HoC's, just to avoid classes makes my head hurt I don't know if it's just something I don't see that often and aren't that familiar with, but I also can't stand the overuse of HoC's for this purpose. Seen some very clever and very, very unreadable HoC's so far and I hate working on codebases that use them liberally.

I think it depends on the use... I think some can be ugly... right now react-loadable and a custom InRoles component are the two I'm using the most. One is for loading state and code-splitting, the other is for allow/deny state...

     }
             deny={'/route' /* or a render, or skip */}
    />
InRoles works for a router redirect, displaying alternate content or no content.

In the end it depends on what you're trying to accomplish. HoC's are pretty useful. Also, it really helps in terms of unit testing your more functional components.

Re: Introducing Hooks

#196

Post by tracker1 »

sdegutis wrote: post #88
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…

React is intended to be a view-only library but in practice people shove all their business logic in there, mostly because React makes it incredibly hard to do anything else. Because of this, innovations in React are going in the wrong direction. This Hooks feature is meant to solve a portion of this, but it's going in the wrong direction. A better bigger-picture innovation would be to have a React-alike that is actu…

Well, you usually have more than one layer of state... a holistic application state, and a control/component state.

It's possible to completely separate out your state machine and use it separately from rendering... It's also possible to integrate it all. Best practices are generally somewhere in between and having your state where needed... if it can be contained, contain it... if multiple controls need it, globalize/context it.

Re: Introducing Hooks

#197

Post by tracker1 »

jf- wrote: post #112
boubiyeah wrote: post #102

Earlier quoted context omitted.

But managing state is quite hard in general. Angular proudly advertises it solves all problems you can have on the frontend but I would take react state + utils over angular's magic templates, rxjs and bindings any day.

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.

Re: Introducing Hooks

#198

Post by tracker1 »

dstroot wrote: post #174
sdegutis wrote: post #88

Earlier quoted context omitted.

React is intended to be a view-only library but in practice people shove all their business logic in there, mostly because React makes it incredibly hard to do anything else. Because of this, innovations in React are going in the wrong direction. This Hooks feature is meant to solve a portion of this, but it's going in the wrong direction. A better bigger-picture innovation would be to have a React-alike that is actu…

> React is intended to be a view-only library but in practice people shove all their business logic in there, mostly because React makes it incredibly hard to do anything else. Because of this, innovations in React are going in the wrong direction. This Hooks feature is meant to solve a portion of this, but it's going in the wrong direction. A better bigger-picture innovation would be to have a React-alike that is ac…

You can literally use React for JUST the view layer... you don't have to maintain any state inside react if you don't want to. Early on, many did use it for just a view layer.

Re: Introducing Hooks

#199

Post by azangru »

adpirz wrote: post #87
schneidmaster wrote: post #16

Earlier quoted context omitted.

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…

It may have been on purpose (came off as a sincere mistake), but Dan Abramov forgets to bind them in this talk while giving an example. It's a very common problem, even for the authors of React itself :)

It did come off as a sincere mistake, but remember, they had a dry run of the talks a day or so before. So could have easily been staged. But was hilarious anyway.

Re: Introducing Hooks

#200

Post by codingdave »

anonytrary wrote: post #137

Unpopular opinion: There are too many cooks. I used React two years ago because the API was tiny, simple and elegant. They are adding new API features left and right, and the framework feels very uncoordinated now. The surface area is way bigger than it needs to be. This is my cue to finally explore other frameworks.

I tend to agree, but you don't have to move at the same speed as the framework. If you have a version that is working well for your needs, stick with it for a year. Then decide when and where to upgrade. You can let the dust settle on new features, let other people learn the harsh lessons and come up with best practices, and then you follow in their footsteps, stably upgrading your codebase to exactly the point that makes sense.

Or, if you prefer a business cliche, prefer leading edge over bleeding edge.

Post reply on HN