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

131–140 of 310 posts

Re: Introducing Hooks

#131

Post by hajile »

nyclowkey wrote: post #44
eric_b wrote: post #41

There are a lot of gotchas with these. Don't call in conditionals, branches, loops. Can only be called from function components. Order of invocation matters (yeck!) If the goal is helping developers "fall in to the pit of success" I think classes are a much better option than this.

yep I see nothing wrong with classes, infact I think I'm going to go back to an older build of React. All this suspense, the messy fiber rewrite and all is just screwing up library. LONG LIVE class based component, there was nothing wrong with them. Don't fix it if ain't broke.

If an older version of react is the goal, maybe infernoJS would be the ticket. It's way more performant than most versions of React while being mostly API compatible (not sure about the most recent react changes).

Re: Introducing Hooks

#132

Post by oldboyFX »

CuriouslyC wrote: post #58
oldboyFX wrote: post #38

Earlier quoted context omitted.

People use Redux way too often and think of features like time travel as nice-to-haves, when in reality they're the main reason why you'd want to use Redux in the first place. Using Redux just to simply set and get data on every page is an overkill. For the majority of applications making API calls directly from the component and storing data in the comp state is the way to go. This is coming from someone who used re…

What do you do when you want to update state in other places in response to a change in a component? How about if you want to make your component's state persistent (particularly when the component is external to your project)? Also, what do you do to generate state dumps for error reporting?

> What do you do when you want to update state in other places in response to a change in a component?

In 90% of the cases one of the parent components. Sometimes redux when the component tree goes super deep, or for things such as currentUser.

> How about if you want to make your component's state persistent (particularly when the component is external to your project)

What do you mean? Give me an example.

> Also, what do you do to generate state dumps for error reporting?

I don't generate state dumps for error reporting.

Re: Introducing Hooks

#133

Post by spankalee »

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)?

It'd be really great for VDOM, builder APIs, and any immediate mode -> retained mode mapping, to be able to get the _callsite_ of a function invocation. Then they could associate state with the callsite unambiguously without resorting to tracking invocations on a stack and disallowing control flow.

Tagged template literals already give us something of a callsite, since the template strings object is cached per callsite. You could do something ugly and use that to associate state:

  const state = useState``();

Re: Introducing Hooks

#134

Post by mhink »

pastelsky wrote: post #64

I like how it makes it possible to re-use behaviour among components, but I also really liked how classes encouraged structure and readability. My hunch is it's only a matter of time before someone creates a helper that would enable `useState` to take complex objects rather than calling it multiple times. Also, custom hooks seem almost too powerful - easy to build multiple abstraction layers and make the API feel mag…

> My hunch is it's only a matter of time before someone creates a helper that would enable `useState` to take complex objects rather than calling it multiple times.

You can already do that, although it's not _exactly_ the same as setState in a class (states aren't merged together... but if you really wanted to, it'd be about five lines to implement a custom hook)

    const [state, setState] = useState({
      foo: "123",
      bar: "abc",
    });

    function updateBar(nextBar) {
      setState({ ...state, bar: nextBar });
    }

Re: Introducing Hooks

#135

Post by kiliancs »

maaaats wrote: post #109
needz wrote: post #71

Earlier quoted context omitted.

It's meant for functional components, not classes.

"This" existed in javascript long before classes. No idea why my relevant question is down voted.

Not in arrow functions, which are very common and any solution should certainly contemplate them.

Re: Introducing Hooks

#136

Post by ergothus »

xab9 wrote: post #124
ergothus wrote: post #89

Earlier quoted context omitted.

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.

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)

Re: Introducing Hooks

#137

Post by anonytrary »

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.

Re: Introducing Hooks

#138

Post by Androider »

No sir, I don't like it :/ I don't see a simple API, I see a completely magic black box that is going to chew up my fingers if I decide to put my hand in it.

Don't fight the language! JS is a still an evolving language, class properties are at Stage 3 draft, and have effectively been usable for years already. I feel the verbosity argument against classes is complete bunk.

When you write "TLDR: There are no plans to remove classes from React... Crucially, Hooks work side-by-side with existing code so you can adopt them gradually... Finally, there is no rush to migrate to Hooks." it doesn't give me the warm and fuzzies, quite the opposite. I can feel the momentum is going to shift to the new hotness and a completely different way of doing things and I'm not sure I want to go where you're heading. Until the next shiny thing.

I wish React would stop adding to the core library. I strongly feel most of the innovation should be happening in libraries surrounding it, even if they're first party libraries, with the core being much slower to change. A good reason to change the core would be taking advantage of new standardized JS features in the future, or (minimally breaking) changes to support big ideas like async rendering. Changing the fundamental way you write React code because "classes are confusing" is just a terrible reason!

Re: Introducing Hooks

#139

Post by paultannenbaum »

renke1 wrote: post #118
paultannenbaum wrote: post #63

Earlier quoted context omitted.

What 'tree' are you referring to? Higher order components are just functional components that accept a component as a argument and return a new component. There aren't any additional nodes added to your VDOM unless you specifically make a HOC that does that.

The component tree.

Then yeah you are incorrect. You are not adding any additional components to the tree. Higher order components are just a design pattern. How you implement that pattern will decide on the component tree, but there is no additional "wrapping" penalty for using them.

Re: Introducing Hooks

#140

Post by linkmotif »

mcphage wrote: post #119
linkmotif wrote: post #70

> Motivation > It’s hard to reuse stateful logic between components Recompose kind of solves this. Why add this to the core API? What am I missing?

Read the comment from today on the top of the recompose readme.

Well then... thank you.

For reference, it says:

> A Note from the Author (acdlite, Oct 25 2018): Hi! I created Recompose about three years ago. About a year after that, I joined the React team. Today, we announced a proposal for Hooks. Hooks solves all the problems I attempted to address with Recompose three years ago, and more on top of that. I will be discontinuing active maintenance of this package (excluding perhaps bugfixes or patches for compatibility with future React releases), and recommending that people use Hooks instead. Your existing code with Recompose will still work, just don't expect any new features. Thank you so, so much to @wuct and @istarkov for their heroic work maintaining Recompose over the last few years.

Post reply on HN