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

211–220 of 310 posts

Re: Introducing Hooks

#211

Post by metamet »

eloff wrote: post #158
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 feel the same way! Maybe I'm just getting older, but I like code to be boring. A class is something everyone can read and understand. If you have to navigate a maze of HOCs withStateHandlers, enchancers, redux actions, reducers and connectors you end up needing to open 10-20 files and jump around between as many functions to build a picture of how a component works. Considering code is read more often than written…

Mmm pointers.

Re: Introducing Hooks

#212

Post by tracker1 »

fiatjaf wrote: post #191
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.

If you aren't interested in 3rd party components or React 16+ features... you could try Inferno or Preact as alternatives with JSX and a similar API.

Re: Introducing Hooks

#214

Post by asragab »

eloff wrote: post #158
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 feel the same way! Maybe I'm just getting older, but I like code to be boring. A class is something everyone can read and understand. If you have to navigate a maze of HOCs withStateHandlers, enchancers, redux actions, reducers and connectors you end up needing to open 10-20 files and jump around between as many functions to build a picture of how a component works. Considering code is read more often than written…

What's actually funny here, is that maybe you aren't old enough. The "Super-cool" functional way has been around as long as types and functions, Lisp and ML have been around since the what...50's and 70's respectively. Immutable state and referential transparency are boring. Get off MY LAWN kid!

Re: Introducing Hooks

#215

Post by see-dante »

dceddia wrote: post #192
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.

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, setter] = this.useState(...)

Re: Introducing Hooks

#216

Post by tangent128 »

jnbiche wrote: post #201
munchbunny wrote: post #154

Earlier quoted context omitted.

Maybe newish coders should learn the language they are using. It's not a language thing. OOP discipline is a coding thing in general. 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. You sound like you don't actually understand why people like Typescr…

> 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.

Re: Introducing Hooks

#217

Post by spankalee »

tln wrote: post #206
spankalee wrote: post #133

Earlier quoted context omitted.

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 callsi…

I don't think this will work, when I just tried to add a property in a template function I get: TypeError: Cannot define property foo, object is not extensible Cool idea though

You don't add properties to the strings object, but use is as a key into a WeakMap.

Re: Introducing Hooks

#218

Post by ajcodez »

Very cool feature. It reminds me of MobX where changing the observable value auto queues a render. It’s super productive. With hooks calling the setter auto queues a render too.

I’ve had a few embarrassing bugs in the past where the page route changes but it’s the same component so it doesn’t call componentDidMount and doesn’t fetch the new data. It looks like hooks default to fetching data too often instead of not enough which feels correct. Instead of users wondering why the page is broken your team is wondering why the server is getting 1000x more requests.

Re: Introducing Hooks

#219

Post by baddox »

codefined wrote: post #157
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…

> because it's apparently hard to work out all the ways that the method could be invoked Simple example case of a statement that makes it impossible to minify function names: class Test { static func() { /* function code */ } } test[prompt('function to call')]()

Doesn’t that example also make it impossible to minify the names of anything? Perhaps other than JavaScript modules, since AFAIK the popular module builders like Webpack do compile-time module importing (I believe that even the dynamic import function is recognized at compile time and doesn’t support throwing in a prompt).

Re: Introducing Hooks

#220

Post by baddox »

acconrad wrote: post #8

A demonstration of Hooks is live right now at ReactConf and looks very cool: https://www.youtube.com/watch?v=kz3nVya45uQ (go back about 1.5 hrs into the past to see the start of the demo).

Unfortunately the video has been blocked due to copyright. My guess is they played music during downtime.
Post reply on HN