Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Frustrations with React Hooks

blog.logrocket.com

Post reply on HN
Print view View original

111–120 of 139 posts

Re: Frustrations with React Hooks

#111

Post by bcyn »

tylerFowler wrote: post #95
bcyn wrote: post #54

I don't agree with the author's statement that there are only two (very involved) solutions to the pagination problem (re: section titled "React relies on the order in which Hooks are called"). It can easily be solved by just setting the state in the event handler, since the state is included in the dependencies array for the fetch effect: https://codesandbox.io/s/dependency-array-0u3sc The answer to this question po…

I wondered about this too, in general I think the article misses that updating state is the key to "causing" effects. Rather than latching onto the callback model to explicitly "run" effects. Though I'll admit getting the relationship of state and effects caused by changes to that state can be more difficult to work out mentally, I think it results in a more complete understanding of what a component actually does.

I agree it's not intuitive at first. As someone pointed out on Twitter (can't find link at the moment):

A good mental model is that the second argument to useEffect defines which pieces of state that effect syncs with.

useEffect(() => {}, undefined) // Sync with all state

useEffect(() => {}, []) // Sync with no state

useEffect(() => {}, [a, b]) // Sync with `a` & `b`

Re: Frustrations with React Hooks

#112

Post by acemarke »

bcyn wrote: post #111
tylerFowler wrote: post #95

Earlier quoted context omitted.

I wondered about this too, in general I think the article misses that updating state is the key to "causing" effects. Rather than latching onto the callback model to explicitly "run" effects. Though I'll admit getting the relationship of state and effects caused by changes to that state can be more difficult to work out mentally, I think it results in a more complete understanding of what a component actually does.

I agree it's not intuitive at first. As someone pointed out on Twitter (can't find link at the moment): A good mental model is that the second argument to useEffect defines which pieces of state that effect syncs with. useEffect(() => {}, undefined) // Sync with all state useEffect(() => {}, []) // Sync with no state useEffect(() => {}, [a, b]) // Sync with `a` & `b`

Original source was Ryan Florence:

https://twitter.com/ryanflorence/status/1125041041063665666

Re: Frustrations with React Hooks

#113

Post by dumbmatter »

PKop wrote: post #94
dumbmatter wrote: post #74

Earlier quoted context omitted.

I've seen a ton of people make that mistake, though. I think it's because what you write is accurate - "refs are meant for values that don't need to trigger a rerender" - but most people think of refs (or at least refs of DOM elements, which for many people are the only refs they ever use) as just a way to access a DOM element. They expect it to just be a DOM element in a normal variable. I'm not sure if there is a l…

But it's a pretty straightforward rule once you know it right? This is simply a matter of reading the docs (or making the mistake until you learn). Not an inherently more complex characteristic than, say, Class component lifecycle methods, which also required understanding their rules and reading the docs. Once you know refs updates won't re-render, you won't make this mistake. I don't understand why "a thing you nee…

Tons of shitty "here's how to use hooks for X" articles on Medium make the mistake, so people learning hooks right at the beginning will not be completely immune.

Also that the fix is "instead of using this one kind ref, use another kind of ref and put it in state"... I don't know, like I said I'm not sure if there is a better solution, but it still feels kind of unintuitive and complicated.

Now that I'm thinking about it... what is the reason that DOM refs and other refs need to be handled by the same concept? Every time I make a DOM ref, I'm doing something with it in a hook like useEffect. Why make me jump through hoops to re-run the hook if the DOM ref changes?

(I recognize there are probably good answers to those questions, the React folks are great, I just don't know the answers! Is it just to avoid introducing one more "type of thing", and instead making refs and DOM refs the same "thing"?)

Re: Frustrations with React Hooks

#114

Post by spion »

The most fascinating thing about React Hooks is the perceived false dichotomy of hooks vs old class API. The old class API was pretty bad and could have been improved without changing the paradigm. Take componentDidMount and cdUpdate: they could have been replaced by this.onMountOrUpdate(fn) : that would have both solved the ergonomic issues and allowed multiple event listeners to be set up by multiple custom 'component enhancers' (the equivalent of custom hooks).

The market is ripe for a React like framework that keeps JSX and first class components but goes away with hooks in favour of a couple of event listeners and stuff like this.getContext(ContextName). Maybe also add MobX to easily solve state management. Vue is pretty close except JSX / first class components are an afterthought.

Re: Frustrations with React Hooks

#115

Post by mikewhy »

acemarke wrote: post #99
Pabblo001 wrote: post #98

Since hooks introduction, I fell in love with React. I always use useState, useEffect, useContext, useReducer... I remember the pain building an app with redux and constant mapToState.... that was nightmare! With hooks it's so easy now.

Please check out our new Redux Starter Kit package [0]. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once The React-Redux hooks API [1] also requires less code that `connect`. I just wrote a tutorial for RSK that shows how to use it with TypeScript, thunks for async, and React-Redux hoo…

(note this is not directed at redux, react-redux, or the wonderful redux-starter-kit library. I'm also a huge, huge fan of how createSlice combines action constants, action creators, and reducer handlers, all in one.)

Those react-redux hooks just exemplify the issues I have with hooks.

Yeah, potentially less code, but with more (and in some instances, completely unheard of) gotchas, more that the developer has to do to keep parity with not using hooks, and certain things dropped entirely.

I'm super interested in this discussion. I've been using React for years, and it's been smooth sailing. But somethings up with hooks, and I haven't been able to put it into words.

Re: Frustrations with React Hooks

#116

Post by PKop »

dumbmatter wrote: post #113
PKop wrote: post #94

Earlier quoted context omitted.

But it's a pretty straightforward rule once you know it right? This is simply a matter of reading the docs (or making the mistake until you learn). Not an inherently more complex characteristic than, say, Class component lifecycle methods, which also required understanding their rules and reading the docs. Once you know refs updates won't re-render, you won't make this mistake. I don't understand why "a thing you nee…

Tons of shitty "here's how to use hooks for X" articles on Medium make the mistake, so people learning hooks right at the beginning will not be completely immune. Also that the fix is "instead of using this one kind ref, use another kind of ref and put it in state"... I don't know, like I said I'm not sure if there is a better solution, but it still feels kind of unintuitive and complicated. Now that I'm thinking abo…

What is the use case for re-rendering based on change of DOM ref? (that can't be accomplished by putting some data in state?)

Ref's are basically a 1 to 1 replacement for instance fields for mutable data (that doesn't cause rerenders).

https://reactjs.org/docs/hooks-reference.html#useref

There's always need for escape hatches and maybe I'm missing your use case, but in the context of a discussion about how hooks are more complicated than classes, what were you doing before with refs to solve your "re-render" on change scenario?

Your example was likely contrived, but modifying innerHTML should be replaced by putting whatever in state and simply rendering it. And use state for dependencies where you want to re-run on change. Refs are just another way to keep state but not have it affect render cycle.

Re: Frustrations with React Hooks

#117

Post by zbuttram »

mjpuser wrote: post #84

I think the part that is hard to grasp is that React essentially has it's own runtime tangled with JS. With the introduction of hooks, there are non JS things going on, which is why React relies on the quirk of having the same order and number of hooks in your component. It also has Suspense which allows you to exit from the render function and return to that spot, which is definitely not a feature of JS. So yea, it'…

There are no "non-js things" going on. I'll grant that they're doing some out of the ordinary things in order to support hooks and suspense, but it's still just JavaScript.

Edit: If you want to see how hooks are implemented without needing to understand the React codebase, Kyle Simpson has a project that provides hooks for non-React functions, the implementation is all in one file: https://github.com/getify/TNG-Hooks/blob/master/src/tng-hook...

Re: Frustrations with React Hooks

#118

Post by dumbmatter »

PKop wrote: post #116
dumbmatter wrote: post #113

Earlier quoted context omitted.

Tons of shitty "here's how to use hooks for X" articles on Medium make the mistake, so people learning hooks right at the beginning will not be completely immune. Also that the fix is "instead of using this one kind ref, use another kind of ref and put it in state"... I don't know, like I said I'm not sure if there is a better solution, but it still feels kind of unintuitive and complicated. Now that I'm thinking abo…

What is the use case for re-rendering based on change of DOM ref? (that can't be accomplished by putting some data in state?) Ref's are basically a 1 to 1 replacement for instance fields for mutable data (that doesn't cause rerenders). https://reactjs.org/docs/hooks-reference.html#useref There's always need for escape hatches and maybe I'm missing your use case, but in the context of a discussion about how hooks are…

Stuff like https://reactjs.org/docs/hooks-faq.html#how-can-i-measure-a-...

If you're not aware of that, it is very tempting to use `useRef`, which is what I have often seen. Before hooks, we did not have the temptingly-named footgun `useRef` for this scenario (although we did have other footguns for other scenarios, and overall I love hooks).

Re: Frustrations with React Hooks

#119

Post by enobrev »

eternalny1 wrote: post #58

> This is yet another JavaScript paradigm to learn. For the record, I am a 49-year-old React fanboy. I am a freelancer and use other frameworks apart from React, and this gives me fatigue. Amen to that. The fact that still are in "here's a 'better' idea, let's try this" landscape in JavaScript is depressing. I no longer jump on these new frameworks when the bandwagon flies by. I ignore postings for jobs saying they a…

React Hooks and Containerizing Everything are the things this old "Webmaster" is kicking down the road until all the bugs are shaken out. I also skipped gulp and grunt and jumped straight into webpack, which I've read far too much about to understand so little.

Re: Frustrations with React Hooks

#120

Post by acemarke »

mikewhy wrote: post #115
acemarke wrote: post #99

Earlier quoted context omitted.

Please check out our new Redux Starter Kit package [0]. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once The React-Redux hooks API [1] also requires less code that `connect`. I just wrote a tutorial for RSK that shows how to use it with TypeScript, thunks for async, and React-Redux hoo…

(note this is not directed at redux, react-redux, or the wonderful redux-starter-kit library. I'm also a huge, huge fan of how createSlice combines action constants, action creators, and reducer handlers, all in one.) Those react-redux hooks just exemplify the issues I have with hooks. Yeah, potentially less code, but with more (and in some instances, completely unheard of) gotchas, more that the developer has to do…

FWIW, the "stale props/zombie child" issues described in the React-Redux hooks docs [0] really have nothing to do with the hooks themselves. It's a combination of:

- The long-standing problem of trying to synchronize an external synchronous state container with React's async rendering cycle

- That our existing solution for this problem requires overriding values in context for connected components

- The fact that context usage _require_ rendering a to update a value

- The fact that hooks themselves do not do any rendering

So, the solution we have for avoiding stale props only works with `connect`. It's not that the hooks themselves are problematic or have inherent gotchas, it's just that hooks don't offer the specific additional capability we would need to implement that same solution in both places.

A user just put together a _fantastic_ article that dives deeper into this specific problem, and recaps how each version of React-Redux tried to solve it [1]. Highly recommended reading if you have some time.

[0] https://react-redux.js.org/api/hooks#stale-props-and-zombie-...

[1] https://kaihao.dev/posts/Stale-props-and-zombie-children-in-...

Post reply on HN