Why Do React Hooks Rely on Call Order? • Hacker News Board

Re: Why Do React Hooks Rely on Call Order?

#111

Post by WorldMaker » Fri, Dec 14, 2018, 5:37 PM UTC

politician wrote: post #109

WorldMaker wrote: post #108

Earlier quoted context omitted.

> It's a shame that relying on call-order indexing is the solution because it's magical. I've been thinking about this a lot since Hooks were introduced, and I'm increasingly of the opinion that it isn't that magical. Order of operations is incredibly important in the functions we write, especially in a language like JS that makes no effort for strict "pure" side-effect free functions. The order of a console.log or a…

> I still feel like I want a better solution than "lint errors" for things like accidental branches of a Hook. The best I can come up with is Sweet.js (hygenic macros), but can you imagine what outrage that would provoke?

Yeah, macros/DSLs might be a bridge too far for a lot of users.

I keep trying to figure out if there is a way to push it into a type safety problem in Typescript, at least. A compile error would be preferable to a lint error, even if not everyone uses a typing compiler like Typescript.

If there were some way that you could get use* functions to narrow to `never` in any branch or branch-like position, that would be cool. Unfortunately, I can't think of a natural way in the type system to do that that would work in even a plurality of cases. Which drops back to it needing to be a context-sensitive linter rule.

Re: Why Do React Hooks Rely on Call Order?

#112

Post by politician » Fri, Dec 14, 2018, 6:41 PM UTC

WorldMaker wrote: post #111

politician wrote: post #109

Earlier quoted context omitted.

> I still feel like I want a better solution than "lint errors" for things like accidental branches of a Hook. The best I can come up with is Sweet.js (hygenic macros), but can you imagine what outrage that would provoke?

Yeah, macros/DSLs might be a bridge too far for a lot of users. I keep trying to figure out if there is a way to push it into a type safety problem in Typescript, at least. A compile error would be preferable to a lint error, even if not everyone uses a typing compiler like Typescript. If there were some way that you could get use* functions to narrow to `never` in any branch or branch-like position, that would be co…

You might be able to use ES6 annotations to mark use* functions such that a bespoke Babel plugin can assert that the the control flow AST only contains functions so annotated in non-branching positions.

Basically, lint, but at transpile time.

Re: Why Do React Hooks Rely on Call Order?

#113

Post by WorldMaker » Sat, Dec 15, 2018, 12:18 AM UTC

politician wrote: post #112

WorldMaker wrote: post #111

Earlier quoted context omitted.

Yeah, macros/DSLs might be a bridge too far for a lot of users. I keep trying to figure out if there is a way to push it into a type safety problem in Typescript, at least. A compile error would be preferable to a lint error, even if not everyone uses a typing compiler like Typescript. If there were some way that you could get use* functions to narrow to `never` in any branch or branch-like position, that would be co…

You might be able to use ES6 annotations to mark use* functions such that a bespoke Babel plugin can assert that the the control flow AST only contains functions so annotated in non-branching positions. Basically, lint, but at transpile time.

Similarly, tslint operates best as a Typescript plugin and so lint rules in Typescript still can happen at transpile time and aren't necessarily that much different in practice from compiler errors. Still bugs me a little that there's not a higher-kinded type or pattern that I can come up with to do it "for real" in the compilation.

Re: Why Do React Hooks Rely on Call Order?

#114

Post by WorldMaker » Mon, Dec 17, 2018, 10:42 PM UTC

thomasfoster96 wrote: post #63

danabramov wrote: post #55

Earlier quoted context omitted.

>wouldn’t you just pass a Symbol key to useFormInput and it would then pass the key to useState, solving the supposed flaw? Then `useFormInput()` wants to add another state (e.g. `isHovered`). How are you going to compose Symbols? We get to the next flaw (manual composition is annoying and error-prone).

> How are you going to compose Symbols? I would’ve used a WeakMap with Symbol keys that mapped to a list or object containing Symbols. Sorry if I’m just overlooking something obvious, but most of the examples that I’ve seen to explain why Symbol keys aren’t better than the current proposal seem to be just be examples of badly implemented custom hooks, not necessarily flaws with Symbol keys per se.

Small, late technical digression that's been bugging me, but Symbols won't provide the behavior you'd expect from a WeakMap.

A) Symbols often get interned as a part of the modules that own them and may never be garbage collected in the lifetime of an app. Thus the items in the WeakMap may never expire (because modules themselves are currently rarely unloaded/garbage-collected).

B) Primitive data types are actually expressly prohibited from being WeakMap keys in the spec (to avoid issues like [A]), and proper implementations are expected to throw errors if you try. MDN expressly makes this clear that this means that Symbols are not allowed to be WeakMap keys:

> Primitive data types as keys are not allowed (e.g. a Symbol can't be a WeakMap key).

Source: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: Why Do React Hooks Rely on Call Order?

#115

Post by fogetti » Tue, Dec 18, 2018, 7:44 AM UTC

davnicwil wrote: post #25

fogetti wrote: post #7

Beg to differ, yes, implicit call order will result in huge clusterfucks. React+Redux is already causing Frankenstein apps (which is not implicitly caused by those frameworks (ok, maybe except redux) but when you throw in react-redux, react-router, redux-thunk, etc. in the mix it just deteriorates quickly). Well the NPM report showed us the trends. Every major fad peaks around 5 years in the making in JS land and the…

You can write really messy confusing apps with lots of magic and indirection with anything, redux included, but redux by design enforces a single, mono directional and easily traceable chain of events whenever you fire an action. Whether you have 1 action or 100, this doesn't change. It's not, in my view, a pattern which works in the simple case but doesn't scale up. Actually the complexity of understanding redux act…

You are implying that the causation goes like this: redux good -> so the app will be good too. And to make a case in point you are trying to make an argument that because many apps are poorly designed, everyone should use redux.

You really can't see how fundamentally broken is your argument? Really???

And you are not the only one who makes this HUGE fallacy.

All the redux/react fanboys are like you. At this point I already consider those people who make these arguments that they are just following/using redux because it's a religion for them.

Not to mention the fact that some people considers the whole uni-directional message flow a HUGE antipattern. See: https://youtu.be/QM1iUe6IofM?t=1306