171–180 of 181 posts
Earlier quoted context omitted.
Apparently React's internals have been doing similar order-based magic for a while already.
That's also the reason why you have to make sure you're passing an update function to `setState` sometimes.
Earlier quoted context omitted.
That's not really a syntax problem, though. Also, hidden state/context is also not that weird? Do you need to know the exact location of the memory/stream that `console.log()` writes to in order to log the console? The physical details of how `navigator.compass.getHeading()` gets its information to use a compass heading? Both of those trampoline off into native code and the details of what the actual "explicit" locat…
Alright, weird semantics then. The hooks calls are unusual compared to normal Javascript code. If you read the other comments on this thread you'll see that I'm not the only one saying that. It comes down to the fact that it's a call, inside a render function, that has different behaviour on each call to said parent function. It's very magical - and the React team admit that, so I'm not sure what exactly you are argu…
In JS call order always matters (it's an imperative language full of side effects), and many calls have side effects that very much differ based on the order you call them.
Even if the gut reaction to hooks is that they "feel" magical or quirky, it's not that different from how a lot of black box function calls already work in the language, it's just maybe more obvious with hooks because they are more explicit in the rules on when you should call them.
Which isn't to denigrate feeling weird about hooks. Again, even I still feel weird about them sometimes. Just that it is less unusual than that initial gut reaction seems to think it is.
Earlier quoted context omitted.
That is being unfair to React. React changed the way developers reason about UI/DOM from imperative to declarative, the holy grail here is that a declarative API allows you to move up your state and have a "single source of truth" and so makes it easy to reason about your application's state at the cost of having more plumbing, for example consider incriminating the value of an input with jQuery (imperative) vs React…
You misunderstood the parent.
Hooks seem to be a drastic change in how we're going to write React components in the future. I'm quite satisfied with the current way of writing components which is to me is very explicit (with no magic). With Hooks React is taking a different direction from their original motto of explicit design patterns. From the looks of it, Hooks seems like a counter-intuitive design pattern but traditionally that's how most of…
Glad to read that as the top comment, because when they came out, I expressed strong doubts about this new features, and I mostly received mad comments in return. The alienated react fans stated that I didn't understand what modern code was, what a great idea those were and how from now on, everything will be better. Now hooks are certainly a technically interesting pattern. I can see why it can be desirable by some.…
I don't understand how hooks add complexity or cognitive load. Simple cases stay simple (even more so, and it's harder to mess up with useEffect than with lifecycle methods, for example), and complex cases are less so.
From the point of view of someone with years of experience writing large applications with React, hooks are a very pragmatic move that solves real problems precisely by simplifying what was already possible. The more complex the scenario, the more obvious the gain is. I venture to say the same thing about the upcoming suspense and related features.
I don't think React itself has a big cognitive load anyway. You might be attributing to it the difficulty some aspects of functional programming might present to some, or of some libraries you might have been using with React. I found this to be the case often. Forgive me if I'm guessing incorrectly.
Earlier quoted context omitted.
Glad to read that as the top comment, because when they came out, I expressed strong doubts about this new features, and I mostly received mad comments in return. The alienated react fans stated that I didn't understand what modern code was, what a great idea those were and how from now on, everything will be better. Now hooks are certainly a technically interesting pattern. I can see why it can be desirable by some.…
> could add a lot of complexity to a react, a tool that already has a big cognitive load I don't understand how hooks add complexity or cognitive load. Simple cases stay simple (even more so, and it's harder to mess up with useEffect than with lifecycle methods, for example), and complex cases are less so. From the point of view of someone with years of experience writing large applications with React, hooks are a ve…
But more than that, react based code has a lot of indirections, requires a lot of pieces of the puzzle to figure out what's going on, and projects have so many different styles and layout you never feel at home when you switch.
The best exemple is jsx. Not only you need a transpiler, not only do you mix in the same place representation and behavior, but the code looks like either spagetthi inlines, or, if you are lucky, a list of many references you suddenly gotta check up somewhere else.
The thing is, with classes, you have a little guidance on where goes what, and people still manage to screw that up. With hooks it's free for all, with caveats, so reading somebody else's code is going to get extra fun.
Earlier quoted context omitted.
No my answer boils down to: - hooks are technically interesting, but make it easy for humans to screw up. It's a precise critic. - the JS community has bad habits that can catalyse this, and above all, may lead them to avoid seing what's wrong - they get angry when we say it, and dismiss it as nonsense. Case in point.
The behavior that you see from a system is the behavior that that system encourages. I guess the proof will be in the pudding as to what hooks actually encourage. I find a healthy dose of 'gloating dismissive' skepticism is usually a good thing. Because it stands in stark contrast 'gloating dismissive' dismissals of criticisms as 'nonsense' that usually come in the form "nah you just don't get it". UI paradigms in pa…
Earlier quoted context omitted.
I think the more relevant analogy between hooks and setState is that setState uses essentially the exact same technique as hooks to keep track of which component is calling it, namely, React keeps track of which component it’s rendering, and setState mutates some “global” state. A lot of people seem to think that setState stores state in the instance of the React component class, but that’s not the case (and that wou…
> setState mutates some “global” state Is this true? Maybe I'm reading it wrong but this.setState in a React.Component just transparently calls out to `this.updater`[1] where `this.updater` is injected by the particular platform library (eg react-dom). At least in react-dom/server's case, a unique `updater` object exists per-component[2], so it's effectively a private instance field; and those state changes apply to…
https://medium.com/@dan_abramov/making-sense-of-react-hooks-... (Ctrl-f “where React keeps the state for Hooks”)
Which is talking about where the state is stored, not the implementation detail of how setState works.
Earlier quoted context omitted.
Pretty much the same way as this.setState in a class does. React knows which component is rendering at any point in time — so it knows which component useState() call corresponds to. I think this explanation is quite accessible: https://medium.com/@ryardley/react-hooks-not-magic-just-arra...
> React knows which component is rendering at any point in time — so it knows which component useState() call corresponds to. Personally, I think that may be the piece that makes it feel a bit magical. With `this.setState()`, usage of `this` makes me feel like I know how the component and the state are linked. With hooks, however, there's no obvious link to the component in the code. I'm grabbing `useState` off of th…
Conceptually Hooks are modeled as "algebraic effects" feature from languages like Eff and Koka. Those are essentially like resumable exceptions.
With that conceptual model, `useState` is like a `throw` that goes back into React "up the stack", and then goes back into your code.
Of course that's not how it works for perf and other reasons (there's no resumable exceptions in JS). But this may help the conceptual model around how we know which component it is.
Earlier quoted context omitted.
This is basically the NPC meme but for technologies instead of politics. I've been building websites since the 1990s and web applications since the mid-2000s. I've used a wide range of web technologies and despite being "self-taught" went out of my way to broaden my horizon beyond the imminently useful. My initial reaction to JSX was dismissive ridicule: "XML in JS? Yeah, because that worked out so well when we did t…
> Maybe, just maybe, some of the people who are truly enthusiastic about hooks aren't simply naive, maybe some are enthusiastic because they do understand how hooks work and what implications they have. In the exact same way that some of the people who are not enthusiastic aren't people who haven't looked at Hooks and don't understand them. Maybe they aren't enthusiastic even though they do understand them. That is e…
Negativity is the cultural norm on HN so much that many people look at HN ("the orange website") the way HN looks at Reddit.
I'm not talking about constructive criticism, heck even non-constructive criticism would be a welcome addition if at least it attacked something more foundational than e.g. "relying on call order is a footgun" (which btw is true but ignores the many footguns involved in the APIs hooks are replacing).
You haven't given a single argument why "hooks are bad if you understand them". That makes you indistinguishable from the usual drive-by negativity. If you want to appear like you have something to say, maybe you should actually say that instead of just insisting your opinion is based on something substantial.
For the record here are the top level responses to the original comment I responded to:
* omeid2 says hooks are change for the sake of change and they only help saving a few keystrokes
* geezerjay says hooks bring nothing new (then pivots to "no new features" when pushed on it)
And then there's my comment where I say HN is jaded.
The first response by omeid2 is demonstrably false: hooks allow collocating all code related to aspects of your components that previously resided in lifecycle methods. They also get rid of the leaky abstraction of `this.state` and `this.setState`, make it easier (read: less error-prone) to respond to prop changes and eliminate the indirection required to consume contexts.
The second response by geezerjay is true in a trivial way and false when taken at face value but further downthread he doesn't elaborate and instead just insists he's not being understood.
Meanwhile your entire contribution so far can be summarised as "no you" at worst or "some people don't like hooks even though they understand them" without going into any tangible specifics at best.
Earlier quoted context omitted.
Fun approach! But I don’t think that’s it? Just not the same kind of zero-effort awesomeness right? Also uses the context API for something it’s not intended for.
I'm not sure what you mean — the context API is specifically for moving data around the component tree without prop drilling. What are you talking about with regard to recompose?