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

271–280 of 310 posts

Re: Introducing Hooks

#271

Post by styfle »

iEchoic wrote: post #203

> Hooks allow you to reuse stateful logic without changing your component hierarchy. Why haven't ES7 decorators been more widely adopted for this? We've been using them for over a year for this purpose now and they've ended up being far cleaner, more powerful, and more composable than the proposed interface.

Decorators haven't been adopted because they are not specced or shipped.

There is no decorator feature in the ES7 (ES2016) spec.

However, there is a proposal for decorators that it is not finalized yet.

https://github.com/tc39/proposal-decorators

Re: Introducing Hooks

#272

Post by thatswrong0 »

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.

There’s a useCallback hook for this

Re: Introducing Hooks

#273

Post by wild_preference »

xab9 wrote: post #263
engineeringwoke wrote: post #260

Earlier quoted context omitted.

You wish we went back to bind and apply? And not being able to trace logic, state, and DOM through a labyrinth of Backbone views? We have come so far How is static typing "mental laziness"?

The article says bind as a negative point - I perefer the new non-bound class method syntax: ``` private handleClick = (event) => {} ``` By "mental lazyness" I mean that people (as in people I have met with) piss on javascript and praise typescript and in the process they never bother to learn about javascript. I do like vue, react, angular of course, but I don't think that you become a frontend developer from one da…

So you involved yourself in a faction war because of... some things some interviewers said? Please, spare us next time.

Re: Introducing Hooks

#274

Post by Illniyar »

ascagnel_ wrote: post #267
Illniyar wrote: post #265

Earlier quoted context omitted.

The magic isn't what React.Component itself does, really it's the use of global variables (or close enough), because there is no other way in js to know inside useState what component called it. The only way I can see this implemented is that when react calls your component function, it then keeps it a note of it in somekind of globally shared variable and then when useState is called it access that same shared varia…

React has some knowledge of a given component through the use of `createElement` (or its JSX equivalents), so it's not even using global variables. https://reactjs.org/docs/hooks-faq.html#how-does-react-assoc... The "memory cells" the FAQ mentions sounds awfully like a map structure where React uses some internal identifier generated on first render to map any state handlers. The only "magic" bit is that it relies on…

It is a globally shared variable.

Really either react notifies or registers the component to the module to exports useState, or more likely useState goes to some react internal api and retrieves the currently running component.

It's as much a global variable as the singleton pattern.

Re: Introducing Hooks

#275

Post by dceddia »

DougBTX wrote: post #246
scq wrote: post #234

Earlier quoted context omitted.

I think those rules only apply to useState and useEffect themselves, and not to the setState function you get back when you call useState.

Yes, I think you’re right, there are different restrictions on when useState and setState, though it is worrying seeing confusion straight away about it. I wonder about a case where there is an expandable panel in a UI, and when expanded it should fetch then display data from a web service. Easy enough to do with this API by splitting the content of the panel out into a second component, but it is going to be very te…

I think the recommended pattern if you need a "conditional effect" would be to just move the `if (expanded)` inside the effect instead of wrapping it.

Re: Introducing Hooks

#276

Post by theothershoe »

On the positive side hooks provide a lot of options for declarative abstractions. I expect that to a large extent the built-in hooks will be used as building blocks for new libraries. I think it is likely that this will outweigh the negatives.

On the other hand, hooks rely on hidden side effects so that each hook invocation returns something different depending on which component instance in the component tree is being rendered when the hook is called, and the number of times the hook has already been called while rendering that instance. This introduces semantics that are unlike anything I know of in the language. A redditor, u/hardwaregeek, pointed out that hooks behave kinda like a state monad, albeit emulated with imperative side-effects.

Re: Introducing Hooks

#277

Post by Illniyar »

On the one hand I'm not sure if I like how this paradigm hides it's implementation so thoroughly - abstractions whose core is invisible to the developer is how simple libraries turn into monstrosities.

On the other hand, this will finally make functional component viable, and actually let us get mixin functionality.

I think it's a good idea, maybe even a great idea after a few adjustments, but it doesn't really belong in core IMO.

Re: Introducing Hooks

#278

Post by tln »

spankalee wrote: post #217
tln wrote: post #206

Earlier quoted context omitted.

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.

The strings object doesn't seem to differ based on call site.

    > f = l => l
    [Function: f]
    > f`hi` === f`hi`
    true

Re: Introducing Hooks

#279

Post by slashdev »

tree_of_item wrote: post #268
eloff wrote: post #158

Earlier quoted context omitted.

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…

> A class is something everyone can read and understand. This is simply not true. Your post is very strange, you just assume classes are simple and boring but everything else is 10-20 files with fancy magic and blah blah blah. The truth is that Dan is wrong about what makes code boring. Immutability is boring. Dan just likes Go.

A class has all the related code in one place in one file (some languages excepted, base classes excepted, but true enough for React purposes where inheritance hierarchies are quite limited and rare in my experience.)

I like immutability. It can make code easier to read and understand if done well. But within reason.

It's not that I'm creating some strawman where the alternative to a class is 10-20 functions across as many files - but that's actually mild compared to some things I've really seen.

To give an example, about a month ago I had to read a co-workers implementation of a feature and it was literally a maze of some 30 functions many of which returning closures, some of which return other closures. With state scattered all over in withStateHandlers, etc. I spent two hours on a Saturday trying to understand it and make the changes I needed to make before I gave up and assigned the ticket to my coworker who wrote it all. Basically he's the only one now who can modify that code easily (and incidentally he's away now on leave, if we have to modify that code again, we're screwed.)

So immutability of data is awesome. Immutability of code is not. If it was a couple boring classes I could have read the code and made all the changes I needed to make in less than an hour.

Simple an predictable and boring is fantastic where code is concerned. I love Go not because of the features it has, but specifically because it's limited enough that the code written in it is almost always easy to understand.

Re: Introducing Hooks

#280

Post by lilactown »

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.

In the small world of the CLJS ecosystem, we use some very elaborate wrappers around React (for good and bad reasons). I'm excited to have many of the features we have had to implement and maintain in user land be moved into React proper, so that we can remove swathes of code that were filling in gaps in the React framework.

In general, I am much more confident in the React team supporting these concerns - simply because there's WAYYY more time, money and mindshare involved - than the CLJS ecosystem shouldering the burden.

Post reply on HN