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

231–240 of 310 posts

Re: Introducing Hooks

#231

Post by bschwindHN »

lilactown wrote: post #111
emmanueloga_ wrote: post #99

Looks like the default way of writing react components in ClojureScript (with Reagent [1]). Compare: CLJS, Reagent: (def click-count (r/atom 0)) (defn counting-component [] [:div "The atom " [:code "click-count"] " has value: " @click-count ". " [:input {:type "button" :value "Click me!" :on-click #(swap! click-count inc)}]]) JS, React + Hooks: function Example() { const [count, setCount] = useState(0); return ( You…

Yep. It looks like React is eating Reagent's lunch and I'm super excited about it!

This is a bizarre comment to me. React is already used _way_ more than Reagent. Even Reagent itself uses React internally. What "lunch" is there to eat? People who enjoy ClojureScript will still use Reagent/Re-Frame because it's not JavaScript.

Re: Introducing Hooks

#232

Post by techsin101 »

I wish they'd work on global event based system to pass state, like redux but built in and steam line it for all use cases like promises. React state propagation sucks.. what Vue is doing with events is basically imitating redux but easier. Context API is very lacking and similar boilerplate as of redux

Re: Introducing Hooks

#233

Post by ec109685 »

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.

If you don’t put this in conditional, branches or loops, by definition they will always be called in the same order.

Re: Introducing Hooks

#234

Post by scq »

badestrand wrote: post #226
acemarke wrote: post #168

Earlier quoted context omitted.

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.

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.

Re: Introducing Hooks

#235

Post by mlsarecmg »

lexicality wrote: post #97

Oh great. Another React feature that relies on creating anonymous functions every time your component renders. I presume this is now adequately fast in the various JITs in use, because I seem to remember this being one of the major bottlenecks React developers were instructed to avoid doing at all costs.

Nah, this has nothing to do with that. If you pass an anonymous fn to a pure-component its shouldComponentUpdate part flags it for re-rendering since the property is new every time, which can be a problem depending on how large its payload is.

Creating a function costs you a few clock ticks, there is no bottleneck, rendering a component and its entire sub tree for no reason on the other hand can be critical.

Re: Introducing Hooks

#236

Post by acemarke »

baddox wrote: post #208
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’m guessing that React is keeping track of the current component instance that is executing when the hook is called, instead of JavaScript keeping track of what ‘this’ is bound to when ‘this.setState’ is called. One could say that both systems are “magic,” but it looks like the React team considers the behavior of ‘this’ in JavaScript to be a source of confusion for React developers.

Yes, yes, and yes.

You can see the current implementation in react-dom@16.7.0-alpha.0 - see https://unpkg.com/react-dom@16.7.0-alpha.0/cjs/react-dom.dev... for the actual code. Do a search for some of the effect names, like `useLayoutEffect()`, to see the implementation details.

React already knows which specific component it's rendering, regardless of whether it's a class component instance, or a specific function component. Looks like what it's ultimately doing is just tracking some additional metadata added to React's internal bookkeeping - search for instances of things like `workInProgressHook.memoizedState`.

And as someone who spends a large portion of my time answering questions from new React devs, I can confirm that the behavior of `this` in classes is an _endless_ source of confusion. Mitigating that is going to be a big improvement long-term.

Re: Introducing Hooks

#237

Post by acemarke »

Aeolun wrote: post #227
AlexCoventry wrote: post #223

Earlier quoted context omitted.

> in practice people shove all their business logic in there, mostly because React makes it incredibly hard to do anything else. I'm not an expert by any means, but I wrote a fairly substantial react app recently, and I found that redux not only made this straightforward, but made it hard to do anything else. I did have to learn redux and redux- saga on top of react, but it wasn't hard.

Just a FUCK-TON of boilerplate :P

People use the word "boilerplate" a lot, but everyone seems to have something different in mind when they say it. What specific concerns do _you_ have? I'm a Redux maintainer, and I'm always happy to try to help offer possible solutions.

Re: Introducing Hooks

#238

Post by acemarke »

see-dante wrote: post #215
dceddia wrote: post #192

Earlier quoted context omitted.

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.

Yeah -- I'm saying it's dubious that there's magic here "doing the setState queue for you" -- notice the function call isn't bound and there's no passing of "this", so it's gotta' got some magic under the hood with some global context. I do, however, like the concept for the react style of render -- being able to grab a getter/setter from that is awesome. They can remove the magic by simply doing: const [getter, sett…

It's nothing more than React already knowing exactly _which_ component it's working on rendering. See my other comment here: https://news.ycombinator.com/item?id=18306957

Re: Introducing Hooks

#239

Post by fnordsensei »

bschwindHN wrote: post #231
lilactown wrote: post #111

Earlier quoted context omitted.

Yep. It looks like React is eating Reagent's lunch and I'm super excited about it!

This is a bizarre comment to me. React is already used _way_ more than Reagent. Even Reagent itself uses React internally. What "lunch" is there to eat? People who enjoy ClojureScript will still use Reagent/Re-Frame because it's not JavaScript.

I think it refers to adopting a pattern from Reagent.

Throughout its lifetime, React does seem to have had a mutually beneficial relationship with the ClojureScript ecosystem, with select ideas from Reagent, Om and others being adopted in core React, or as JS libraries around it.

Re: Introducing Hooks

#240

Post by xab9 »

tangent128 wrote: post #216
jnbiche wrote: post #201

Earlier quoted context omitted.

> You sound like you don't actually understand why people like Typescript, or, more specifically, static typing. Eh, in my experience, there are two types of Typescript users: 1) those users who appreciate the safety that type systems provide when used properly, and 2) those enterprise users of the language who have mostly only coded Java and C# and who like Typescript because it lets them write Java-style code for t…

Typescript doesn't do anything ES6 & Webpack don't already do; Javascript already lets you write Java-style code if you really want to.

I know, but lately during frontend interviews I was surprised how many times I met with "I'm a developer I can do anything" type interviewers - some of them were dotnet, others were java devs and they preferred typescript, because 1. javascript is a terrible language 2. with typescript they feel right at home 3. they can use a "proper ide" (please, don't ask, I already had an argument and a rejection when I tried to ask about webstorm)
Post reply on HN