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

101–110 of 310 posts

Re: Introducing Hooks

#101

Post by Touche »

schneidmaster wrote: post #16
ggregoire wrote: post #4

While I agree that class components has always felt like a workaround to bypass the limitations of function components, and that it's obviously annoying to rewrite a function component to a class component just to add a state or a lifecycle method, the following explanation sounds a bit silly to me: > In our observation, classes are the biggest barrier to learning React. You have to understand how this works in JavaS…

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()}`.

Re: Introducing Hooks

#102

Post by boubiyeah »

sdegutis wrote: post #100
boubiyeah wrote: post #95

Earlier quoted context omitted.

React was never a view-only library. Pete Hunt always said he saw React components as mini MVC modules. it's even less true nowadays with features like Context or suspense to supplement the component states. Redux was kind of a temporary hack.

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.

Re: Introducing Hooks

#103

Post by boubiyeah »

pg_bot wrote: post #36

I know I may be in the minority here, but I can't say that I'm a fan of this feature. I can't envision a scenario where this would be my preferred solution to any of the problems that they detail. Templates should remain stateless, as they are far easier to reason about that way. My gut reaction is that this is a giant step backward.

react is not based on logicless templates. Their very first presentation in 2012 or 2013 made that clear. It's a feature.

Re: Introducing Hooks

#104

Post by nine_k »

brlewis wrote: post #96
nine_k wrote: post #78

Well, okay. Preact exists. Even mithril.js isn't completely dead. Sad, though. A framework can afford a lot of technical debt, but adding more conceptual debt, like React was doing recently, seems to me like a road to oblivion^W legacy status. Features that lack clarity and come bundled with footguns tax developer's brain resources, and increase the rate of errors. These are some of the most expensive resources in IT…

> Even mithril.js isn't completely dead. That's a rather un-generous description of a framework under active development with an active community.

A lot of code is 1-2 years old.

Though I'm happy that mitrhil.js lives and is being developed (not just maintained). I only wish it wider adoption.

The "not completely dead" was meant to be somehow tongue-in-cheek.

Re: Introducing Hooks

#105

Post by dvlsg »

_uhtu wrote: post #42

I have some troubles with the state hook. It may look nice to a novice developer, but when I look at it I just see confusing magic. I read what's happening and I just say wait, there's no closure or class here, how this state is stored is completely hidden from me. I can see uses for the other types of hooks, but the state hook seems like it would be much better served with an HOC like Redux's connectToStore, which w…

I agree. Something about it just doesn't feel right to me. Like state is stored in a global singleton somewhere.

Any of the examples touch on testing components using hooks? Any chance using the same component across multiple tests would result in state collisions? Especially when testing something asynchronous?

Re: Introducing Hooks

#106

Post by sdegutis »

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.

Right, and that's what I'm recommending we in general try to innovate on: better state management than React, but with the ease of writing view components that React has showed works well. Since the view is hierarchical, it makes sense for components to inherently also be hierarchical, but business logic often doesn't match up to React's component hierarchy, so it should not be done inside React or tied to React's hierarchy.

Re: Introducing Hooks

#107

Post by tropshop »

Front-end devs need to first master the vanilla tools, then reach for the frameworks once they understand the why.

I'd like to see a build tool that focuses on plain HTML, CSS, and ES6 modules. It takes the input .html file, parses the elements, and statically analyzes the code to polyfill and re-write output for specified browser compatibility.

I think part of the problem is that the intro tutorials for the fully loaded frameworks look so much simpler at a glance than trying to wrangle something on your own.

Any ideas for youmightnotneedreact.com?

Re: Introducing Hooks

#108

Post by adriancooney »

kiliancs wrote: post #17
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)?

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

I doubt the linter will enforce the same-ordering, that would require state between runs. I think the linter just ensures hooks are run at the top level in the functional component.

Re: Introducing Hooks

#109

Post by maaaats »

needz wrote: post #71
maaaats wrote: post #65

Earlier quoted context omitted.

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.

It's meant for functional components, not classes.

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

Re: Introducing Hooks

#110

Post by ilaksh »

I'm actually most comfortable with object-oriented programming since I started doing that 26 years ago. However, this simplifies the lifecycle business somewhat and results in a slightly cleaner JavaScript syntax than the class based way in my opinion.
Post reply on HN