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

111–120 of 310 posts

Re: Introducing Hooks

#111

Post by lilactown »

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!

Re: Introducing Hooks

#112

Post by jf- »

boubiyeah wrote: post #102
sdegutis wrote: post #100

Earlier quoted context omitted.

I distinctly remember the phrase "V in MVC" being prominently displayed somewhere on the official React website(s). Found it: https://web.archive.org/web/20140329114924/http://facebook.g... > JUST THE UI > Lots of people use React as the V in MVC. Since React makes no assumptions about the rest of your technology stack, it's easy to try it out on a small feature in an existing project. So I was mistaken. It didn't sa…

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.

Re: Introducing Hooks

#113

Post by jotaen »

Touche wrote: post #101
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…

You can just do `onChange={() => this.handler()}`.

This would create a new inline function on every render though, which potentially might cause rendering performance issues.

Re: Introducing Hooks

#114

Post by rpeden »

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…

I don't think it's quite the same, is it?

In the Reagent example, you declare the atom outside of the component function, and that atom would end up shared if there were multiple instances of the counting component.

In the react example, each instance of the component would have its own separate state.

Reagent will let you put the atom inside the component, too, so you can do something very similar to the React example. Just wanted to point out that the two examples you've got now do different things.

Re: Introducing Hooks

#115

Post by dbbk »

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…

Component lifecycle methods are easy to grasp conceptually. At different stages of rendering the component, React will call one of these methods. Easy.

With `useEffect`, I have no idea what is actually happening here, and I've tried re-reading it a few times.

Re: Introducing Hooks

#116

Post by [deleted] »

krapp wrote: post #91
beatgammit wrote: post #9

Earlier quoted context omitted.

To be fair, JavaScript has been a moving target and things like classes are quite new. Then again, it doesn't make sense to avoid features just because they're new. I think the point is that they want to provide two ways to do simple things: classes and functions. Functions have better performance, classes are more flexible.

>I think the point is that they want to provide two ways to do simple things: classes and functions. At the risk of seeming like an old man complaining about new things, what problem would "classes" solve in javascript that the existing object syntax, which allows for inner functions and variables, doesn't?

[deleted]

Re: Introducing Hooks

#117

Post by mcphage »

baddox wrote: post #5

This is interesting. I'll have to spend some time mulling over this before the benefits sink in. It seems like a much more confusing and less composable API than recompose, which is how I add state, lifecycle, and other React class features to functional components. I've been completely avoiding React classes for a while now and using stateless components with recompose for over a year now, and I find it to be a wond…

The author of recompose just end of life'd it today in favor of Hooks. Read his comment on the top of the recompose readme.

Re: Introducing Hooks

#118

Post by renke1 »

paultannenbaum wrote: post #63
sktrdie wrote: post #10

Earlier quoted context omitted.

Right but with recompose you get extra wrapping components in your tree which is what they were trying to avoid.

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.

Re: Introducing Hooks

#119

Post by mcphage »

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.

Re: Introducing Hooks

#120

Post by emmanueloga_ »

rpeden wrote: post #114
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…

I don't think it's quite the same, is it? In the Reagent example, you declare the atom outside of the component function, and that atom would end up shared if there were multiple instances of the counting component. In the react example, each instance of the component would have its own separate state. Reagent will let you put the atom inside the component, too, so you can do something very similar to the React examp…

hmmm yeah here's a better example:

    (defn timer-component []
      (let [seconds-elapsed (r/atom 0)]
        (fn []
          (js/setTimeout #(swap! seconds-elapsed inc) 1000)
          [:div "Seconds Elapsed: " @seconds-elapsed])))
Now the atom is defined inside the component function, and is captured by lexical scope in the returned function. Any timer-components on page will have their own `seconds-elapsed` state.
Post reply on HN