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

91–100 of 139 posts

Re: Frustrations with React Hooks

#91

Post by acdha »

csande17 wrote: post #73
acemarke wrote: post #70

Earlier quoted context omitted.

A lot of people don't understand that React's default behavior is to re-render _everything_. When a component is rendered, React will recursively re-render all descendants of that component. Out of the box, React doesn't do any optimizations like "skip rendering this component if the props haven't changed". Because of that, "re-creating callbacks" isn't an issue in base behavior [0], because there's nothing that care…

Yeah, React seems to have been designed under the assumption that DOM operations are the only thing front-end code can do that takes non-zero time. Like, here's the first line of their document describing how to use to improve performance using things like PureComponent: ( https://reactjs.org/docs/optimizing-performance.html ) > Internally, React uses several clever techniques to minimize the number of costly DOM ope…

This was also a huge part of the marketing push for years: if you listened to proponents, you have thought that the average app was bottlenecked on DOM updates, and that partial updates were too hard to do with anything else.

Re: Frustrations with React Hooks

#92

Post by PKop »

ssalka wrote: post #82
aidos wrote: post #76

Earlier quoted context omitted.

I feel of all the arguments against hooks, the whole “order of hooks” thing is the thinnest. You just learn about it and then it’s not a problem again. I definitely get that there are some more complex cases where you have to jump through a couple of useRef hoops to do what you need. On balance though, I think the way the behaviour becomes declarative is worth the trade off.

Coming from the FP world, hooks are a terror because they break all the nice rules functions are supposed to uphold. Hook components don't necessarily return the same value when given the same arguments, making them impure (stateful). The benefit of function components IMO has always been that you can use the function scope as a container for pure, stateless rendering logic. With the introduction of hooks I can no lo…

How does the existence of hooks preclude you from using function components without state (without any hooks)?

Re: Frustrations with React Hooks

#93

Post by Unbeliever69 »

nooyurrsdey wrote: post #62

What's lost in all this is that classes are simple and understandable. Introducing all these new paradigms removes that simplicity. Everyone is ready to hate on classes but they have been robust structures for a long time

I think that what is lost is that Javascript is more of a functional language than an object-oriented one and a move to hooks embraces its functional roots while eliminating numerous footguns (this), simplifying reuse, and reducing redundancy.

Re: Frustrations with React Hooks

#94

Post by PKop »

dumbmatter wrote: post #74
bcyn wrote: post #38

Earlier quoted context omitted.

> For example, this useRef / useEffect combo mystifies me even now: https://stackblitz.com/edit/react-ts-zhvuha On this particular point, the reasoning is that refs are meant for values that don't need to trigger a rerender[1] -- an escape hatch, rather than something you reach for by default. In that sandbox, you can accomplish what you mean to accomplish by using state rather than a ref. [1] https://github.com/face…

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 need to learn then you're good" is somehow inherently more complicated than ... other apis that you need to also learn.

> but most people think of refs as...

This sounds like Dan Abramov's comment that some of the struggles with hooks is from people who have experience with react without hooks, vs people coming new to the whole thing. So maybe it's about relaxing pre-conceived notions until experience takes over.

Re: Frustrations with React Hooks

#95

Post by tylerFowler »

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.

Re: Frustrations with React Hooks

#96

Post by acemarke »

fishnchips wrote: post #89
dynamite-ready wrote: post #63

Earlier quoted context omitted.

`useContext` is excellent. React.context is a solid alternative to the likes of Redux and Apollo, but takes a fair amount of boilerplate to add to a class based React component. But with `useContext`, applying global state is a breeze. A lot easier to manage than Redux, at the very least. The only real dislike I have, is in how `useEffect` confuses the React lifecycle. It took me a little while to grok the lifecycle…

I understand how contexts can replace Redux, but can you please elaborate how they can be used instead of Apollo? Do you mean the whole of Apollo or Apollo local state?

Note that context and useReducer do _not_ completely replace Redux.

See the following resources for more details:

- Mark Erikson - Reactathon 2019: The State of Redux (https://blog.isquaredsoftware.com/2019/03/presentation-state...)

- Mark Erikson: Redux - Not Dead Yet! (https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet...)

- Dave Ceddia: React Context API vs Redux (https://daveceddia.com/context-api-vs-redux/)

- Mike Green: You Might Not Need Redux (But You Can’t Replace It With Hooks) (https://www.simplethread.com/cant-replace-redux-with-hooks/)

- Sergey Ryzhov: From Redux to Hooks: A Case Study (https://staleclosures.dev/from-redux-to-hooks-case-study/)

- Eric Elliott: Do React Hooks Replace Redux? (https://medium.com/javascript-scene/do-react-hooks-replace-r...)

- Chris Achard: Can You Replace Redux with React Hooks?](https://dev.to/chrisachard/can-you-replace-redux-with-react-...)

Re: Frustrations with React Hooks

#97

Post by PKop »

latortuga wrote: post #28
littlecranky67 wrote: post #20

One major point of the author is complaining that the dependency array in an effect is only compared by reference for objects and arrays. To me this is a feature rather than a shortcomming: I use immutable data structures all the time (with array and object spread operators it is really easy to do so) and the effect will only update when it really needs to - thus only triggering a re-render (or rather reconciliation)…

The example in the article can be fixed very easily and doesn't require immutable data structures. If you're fetching something from a url and you don't want to fetch twice from the same url, make the dependency the url itself.

More generally, one should be destructuring object properties (since he later did that anyways) at the top of the function. It's no more typing, but isolates property usage to one spot. Then pass them into the dependency array.

Seems very convoluted to do that inside the useEffect, just to show how "it doesn't work".

Especially because often a re-run of the effect will be desirable when some of the props change, not always the whole bag..

Re: Frustrations with React Hooks

#98

Post by Pabblo001 »

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.

Re: Frustrations with React Hooks

#99

Post by acemarke »

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 hooks [2].

[0] https://redux-starter-kit.js.org/

[1] https://react-redux.js.org/api/hooks

[2] https://redux-starter-kit.js.org/tutorials/advanced-tutorial

Re: Frustrations with React Hooks

#100

Post by mmckelvy »

Long time React user here, have started experimenting with hooks. My general sense is the useState hook is a pretty neat idea, but useEffect and friends need some work. Definitely doesn't have that same "completely makes sense, this is a great API" feel that I typically associate with React.
Post reply on HN