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

Why React Re-Renders

joshwcomeau.com

Post reply on HN
Print view View original

151–160 of 168 posts

Re: Why React Re-Renders

#151

Post by v0idzer0 »

pcthrowaway wrote: post #96
nickdandakis wrote: post #61

Earlier quoted context omitted.

You're translating the class-based way of working in React against hooks, without stopping to consider understanding hooks as a first-class principle instead of a translation. It's called useEffect because it runs on the (side)effects observed by the dependency array. An empty array happens to happen on mount. useEffect returns a teardown function which happens to correlate with unmount when an empty array is passed.…

> useEffect returns a teardown function which happens to correlate with unmount when an empty array is passed. I believe this teardown function runs on unmount whether or not the dependency array is empty.

It does, but it runs on more than just unmount when the dependency array is not empty. It runs anytime any dependency in the array changes. This is an important distinction. For example, event listeners added in useEffect will be removed anytime a dependency changes. Then a re-render will occur and they will be added back in the next useEffect body execution. This differs from componentDidUnmount which obviously only runs on unmount and never in the render cycle

Re: Why React Re-Renders

#152

Post by brundolf »

petilon wrote: post #56

A pain point with React is large data structures. To re-render (assuming class components), you can setState with the changed property. For example if your state has two properties named foo and bar, and bar has changed then you call setState({ bar: newValue }). This works if you have simple properties. What if you have large complex data structures, and you need to modify a property deep down inside? Then you can ma…

MobX formalizes this way of working with state and makes it non-fragile (and more performant to boot)

I don't think I could recommend doing it the way you describe because there are a huge number of ways it can go wrong

Re: Why React Re-Renders

#153

Post by acemarke »

endless90 wrote: post #142

> I know some developers believe that every state change in React forces an application-wide render, but this isn't true. Re-renders only affect the component that owns the state + its descendants (if any). The App component, in this example, doesn't have to re-render when the count state variable changes. Does that mean if i have a redux store attached to my app it rerenders everything when i change something small…

No. React-Redux only uses Context to pass down _the Redux store instance_, not _the current state value_. The store instance doesn't change, so that use of context will never cause later re-renders.

Instead, components directly call `store.subscribe()`, and check to see if they need to update after each dispatched action.

See my post "A (Mostly) Complete Guide to React Rendering Behavior" for more details:

- https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...

Re: Why React Re-Renders

#154

Post by acemarke »

Zealotux wrote: post #149
endless90 wrote: post #142

> I know some developers believe that every state change in React forces an application-wide render, but this isn't true. Re-renders only affect the component that owns the state + its descendants (if any). The App component, in this example, doesn't have to re-render when the count state variable changes. Does that mean if i have a redux store attached to my app it rerenders everything when i change something small…

No, there is optimization happening at Redux level to ensure components only gets updated when they need to, but it's up to you to ensure your store is properly designed and consumed to avoid unnecessary updates. Look up Mark Erikson's blog[1], who's a Redux maintainer, for a lot of details on Redux's internals (acemarke on HN), he also answers tons of questions everywhere[2] about Redux, he helped me so much underst…

Thanks, glad to hear that info's been helpful! :)

Re: Why React Re-Renders

#155

Post by DanielHB »

One funny thing about React is that the most dangerous kind of developer is the one with middle-level knowledge of it

beginners don't know enough to do optimisation seniors know enough that they only optimise what is needed mid-level are capable of build code that needs to be optimised, but they tend to over-optimise and often do the optimisation wrong

for example what a mid-level might do:

const C1 = React.memo(({values}) => {...}) const C2 = () => { return }

That React.memo is useless because arrays and objects are mutable in JS It also reveals a flaw in JS/React in that memoization often needs to happen at the parent instead of the child, creating awkward code and implicit behaviour and implicit performance traps when forgetting to memoize object/array props that the child expect to be memoized. The child decides which props should be memoized, but doesn't enforce it and no amount of typescript will catch that problem

Fortunately there is a proposal that will fix this problem by introducing records and tuples like python (immutable objects/arrays) https://github.com/tc39/proposal-record-tuple but it still seems far off to being usable as I don't think it will be viable to polyfill it for browsers that don't support it

Re: Why React Re-Renders

#156

Post by DanielHB »

Griffinsauce wrote: post #105
HeyImAlex wrote: post #64

Earlier quoted context omitted.

Hooks compose, whereas side effects and memoized values sprinkled through component constructors and lifecycle methods do not. For example, the equivalent of useEffect required calls inside of componentWillMount, componentDidUpdate, and componentWillUnmount. You try and make something like this re-usable and you’ll be leaking details of your implementation across the whole component via inclusion in these lifecycle m…

I wish the current detractors would look back at this. The options with life cycles are either huge life cycles with interspersed features OR super painful composition. I've been in big codebases with both and it was absolute hell. Hooks aren't perfect or pretty but the fact that they can encapsulate AND compose makes them a million times better. Those codebases are much easier to deal with now. Again, not perfect, b…

hooks were created to replace the functionality of mixins, not necessarily to replace lifecycles The react team could have easily added a useDidUpdate() and useWillMount(), but they didn't because the new abstractions cover the mixins use-cases also work better than lifecycles as well (but somewhat less intuitive at first glance)

Re: Why React Re-Renders

#157

Post by DanielHB »

fabian2k wrote: post #46
gregsadetsky wrote: post #45

Josh's content is always very very high quality. I look forward to him releasing his online React course [0] so that I can recommend it to others who are starting out. My personal biggest not-total-comprehension is around Hooks / effects. I've followed tutorials, used them in production, etc. I'm comfortable using them but I also consider them a bit of a black box, which I don't like (e.g. I'm not sure how they're im…

You can reuse hooks between multiple components. You can't really do that with the lifecycle methods of class-based components.

you can with mixins

doesn't mean you should...

Re: Why React Re-Renders

#158

Post by DanielHB »

egeozcan wrote: post #143
mlajtos wrote: post #136

Earlier quoted context omitted.

> immediate data structures Immutable? But React in JS is a blessing – it brought good thinking to messy world. And as a direct influence, JS will adopt immutable data structures – tuples and records. https://github.com/tc39/proposal-record-tuple

I just cannot wait for this to come to the browsers. This will massively (and positively) impact how I can write JS.

I keep raving about it to people, no one cares or understands why this is MASSIVE for react development...

Re: Why React Re-Renders

#159

Post by DanielHB »

fabian2k wrote: post #33

The big part that seems to thoroughly confuses developers new to React is the difference between rendering and reconciliation. This is not particularly difficult to understand, but the original emphasis on the virtual DOM seems to lead to a misunderstanding on how React works. The vDOM plays a role only after rendering happened, so all that diffing stuff doesn't have anything to do with rendering. To me that seems li…

yeah, this is key. What you should be REALLY avoiding is unnecessary DOM updates, rerenders have a cost too, but marginal compared to DOM updates

and even then you mostly don't need to care either except in extreme situations (like useCallback is not really necessary most of the time0

Re: Why React Re-Renders

#160

Post by petilon »

kccqzy wrote: post #121
petilon wrote: post #90

Earlier quoted context omitted.

> React has always been designed around some Functional Programming type principles, such as immutable updates If you think React has anything to do with Functional Programming, please read this ASAP: https://mckoder.medium.com/why-react-is-not-functional-b1ed1...

React was prototyped in Standard ML. Say what you want about whether you think it's functional enough but you can't revise history.

Whether React's implementation is functional or not has no relevance to the question of whether applications written using React are functional.
Post reply on HN