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

121–130 of 310 posts

Re: Introducing Hooks

#121

Post by munchbunny »

ergothus wrote: post #83
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 can see both sides. I teach React to newish coders, and classes are easy for them to grasp...and then immediately create labyrinthine monoliths. At work where I do React, we emphasize small components with limited and segmented logic (ideally pulling as much logic out of the React parts as possible - and this is most easily done by avoiding classes). At the same time, I've a passion for trying to make code more mai…

I can see both sides. I teach React to newish coders, and classes are easy for them to grasp...and then immediately create labyrinthine monoliths.

To be fair, that's pretty much what happens to all newish coders who are learning classes. Learning to use classes responsibly is really just part of the learning, though that seems to be the part that instructors pawn off to the next guy.

Once you learn how to use them judiciously, classes become extremely useful tools for encapsulation/abstraction where you need encapsulation/abstraction.

Re: Introducing Hooks

#122

Post by jf- »

maaaats wrote: post #57

> React doesn’t offer a way to “attach” reusable behavior to a component I know the angular resentment here is high, but some things Angular 1 got right. Directives added as attributes to another component was very powerful and allowed this in better ways than HOCs in React. Im looking forward to try this out.

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.

Re: Introducing Hooks

#123

Post by adriancooney »

My gut reaction is that Hooks isn't the greatest addition to React. One thing I've always pitched about React is the clean and extremely explicit API (with `dangerouslySetInnerHTML` being my favourite example). The hooks API is taking the dangerous road down to implicitness and magic which can only ever mean bad things in my book.

It's really not clear to me how calling the setter for these individual pieces of state triggers a render. It seems the `useState` call is implicitly linked to the calling component no matter how far down the call stack (with only a linting check keeping the safety on this footgun). I was also surprised to see the concept of reducers making their way to the API. We're being told the "classes are the biggest barrier to learning React" yet the notoriously difficult concept of reducers has its own method. Don't get me wrong, I _love_ Redux however I'm not sure I can get behind the shade for classes.

I'll have to play around with hooks before I can make a final call though because I have the utmost respect for everyone behind this project.

An interesting observation: I think this is the first piece of API that contains the word "assumes" [1].

[1] https://www.google.ie/search?q=site%3Areactjs.org%2Fdocs+%22...

Re: Introducing Hooks

#124

Post by xab9 »

ergothus wrote: post #89
bendavis381 wrote: post #29

Earlier quoted context omitted.

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.

I don't think the issue is "what is a class". It's more that the lifecycle functions get tied into the class, and you end up with a ball of highly conditional logic. It's easy for newbies to just add stuff to make it work, but end up with a mess. React is the view layer, so the class concept of "here's some data and methods to alter it" doesn't really match with what happens - I don't know that components every shoul…

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.

Re: Introducing Hooks

#125

Post by pavlov »

danenania wrote: post #90
pavlov wrote: post #67

Am I getting this right: it’s an implicit global stack for the render loop? Sounds like a combination of the worst design features of OpenGL and Forth, to be honest... OTOH, React has been pretty good about taking discredited design ideas — like Adobe Flex’s style of mixing XML declarations into ECMAScript code — and injecting them with new vigor. So maybe this one too is better than the initial impression.

Personally, I loved Flex’s mxml/actionscript combo. Its main (fatal) flaw was targeting the flash player. At the time, moving to html/js felt like a big step backwards on developer experience.

Yeah, MXML (and in fact most of Flex) had a lot of good about it. “Discredited” was too strong a choice of word in my post — I meant something closer to “unfashionable”.

Re: Introducing Hooks

#126

Post by mhink »

Fellshard wrote: post #94
hliyan wrote: post #15

"You might be curious how React knows which component useState corresponds to since we’re not passing anything like this back to React. We’ll answer this question and many others in the FAQ section." While I appreciate the functional usage of state, this type of magical behavior worries me a bit. Wasn't more straightforward semantics possible (even if the syntax wasn't similarly straightforward)?

This is where I'm falling on it. What started as initial excitement over a lens-like addition started to feel more like black magic once I realized that it relies _a lot_ on implicit ordering just to preserve a seemingly simple usage pattern. While it may _look_ nice to be able to just call `useEffect` and have it infer the rest, it just ends up masking the flow of a hidden parameter into that component, and convolut…

I think people are getting too hung up on the "implicit ordering" thing. The only thing that really matters about the ordering of hooks is that the call pattern remains stable between render passes. This code:

    const [foo, setFoo] = useState("abc");
    const [bar, setBar] = useState("123");
...is functionally the same thing as

    const [bar, setBar] = useState("123");
    const [foo, setFoo] = useState("abc");
The feature is _declarative_ in the same way element rendering is declarative.

Re: Introducing Hooks

#127

Post by xab9 »

munchbunny wrote: post #121
ergothus wrote: post #83

Earlier quoted context omitted.

I can see both sides. I teach React to newish coders, and classes are easy for them to grasp...and then immediately create labyrinthine monoliths. At work where I do React, we emphasize small components with limited and segmented logic (ideally pulling as much logic out of the React parts as possible - and this is most easily done by avoiding classes). At the same time, I've a passion for trying to make code more mai…

I can see both sides. I teach React to newish coders, and classes are easy for them to grasp...and then immediately create labyrinthine monoliths. To be fair, that's pretty much what happens to all newish coders who are learning classes. Learning to use classes responsibly is really just part of the learning, though that seems to be the part that instructors pawn off to the next guy. Once you learn how to use them ju…

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.

Re: Introducing Hooks

#128

Post by mhink »

wichert wrote: post #56
lacker wrote: post #49

This looks like a nice but not enormous improvement to React. First, I really like how these hooks are optional. You can still use the current class-based mechanisms wherever you want. Existing code will keep working the exact same way. For the specific hooks they provide: `useState` seems like a slight improvement over using `this.state`, at least for simpler use cases. You save about 5 lines of object-oriented setu…

I can see the benefit being enormous if you use typescript. Currently it is often a struggle to come up with the magic combination of generic parameters and HoC ordering to make things work, which might still fail if your HoC has an incomplete typing specification. Using a couple of very simple easily typed functions makes things much easier to reason about and to specify correctly.

This was one of the first things I thought about when I read the docs. This is primarily meant to replace render props and HOCs, which solve a legitimate problem but are a royal PITA to use, especially with Typescript.

This is going to make it about a million times easier to use Typescript with React.

Re: Introducing Hooks

#129

Post by nathan_f77 »

This is really interesting. I'm a big fan of any abstractions that reduce the amount of code I have to write. Just a personal preference. Other programmers like to avoid "magic", but I love it.

`useEffect` feels much cleaner than the component lifecycle methods, and I could add some abstractions on top of those. e.g. a higher-order function that adds/removes a window event listener, and you can just pass the event and your callback.

Maybe `useState` could take a second argument that gives the state a "key", so that it can be called in any order. I can imagine breaking up the `useState` calls into different functions, and then skipping one of the functions if something changes. So it might be handy if there was an escape hatch where you could label each call with an integer or a string.

EDIT: Wow, it would be awesome to use this pattern for my Redux reducers. Instead of having to connect up all the actions in my container and then prop-drilling all of the dispatching functions down into my components, it would be great if I could just import the action creator directly and use it anywhere I want. Maybe I could add some similar hooking magic to find the store from the Provider and call dispatch with the action, instead of manually wiring everything up. Although actions are usually called after the render is finished, in onClick handlers, etc.

Or maybe I could do this with Context. I'm just really tired of prop-drilling all these action dispatch functions down to my components. There must be a better way to automate all of the boilerplate with actions and reducers, even if it's a Babel plugin.

Re: Introducing Hooks

#130

Post by zwily »

maaaats wrote: post #65
kiliancs wrote: post #17

Earlier quoted context omitted.

> React assumes that if you call useState many times, you do it in the same order during every render. Note they also say: > We provide a linter plugin to enforce these rules automatically. Makes me feel a little better.

Why couldn't one just pass in `this` to useState, a key, or something similar? Like, if I have two state variables, pass in a name for both, instead of relying on the order being the same.

And what would `this` be in that function?
Post reply on HN