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

111–120 of 168 posts

Re: Why React Re-Renders

#111

Post by NTARelix »

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.

This is correct, but I think the point nickdandakis was trying to make is that useEffect does not directly correlate with componentDidUnmount because useEffect's returned callback could be called in the middle of the component's lifecycle, not only when the component unmounts.

Re: Why React Re-Renders

#112

Post by knodi123 »

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.

Yes, you're correct, and he got it wrong when talking about it.

This kind of goes towards my point. useEffect works, and it works great. It's flexible and powerful - but it's cryptic as hell, and the interface is just "memorize it because you have to", not something more intuitive.

What if useEffect required a 2nd argument, but you had the option to pass in self, which would still offer the onMount behavior, by mirroring the way the other form of it worked? Bada-bing, now there's no exception to the rule. What if the 2nd argument was a named argument, like "trigger"? Now it's self-documenting. What if the teardown function as an optional 3rd argument with a name, too? Now it's easy to glance at a useEffect and tell whether it's declaring a teardown without carefully reading the body. etc etc.

He says "useRef offering a connection to DOM elements is just sugar", but that's not sweet, to me. There's no reason one thing should do two totally different things. That's exactly what I'm complaining about.

Re: Why React Re-Renders

#113

Post by pcthrowaway »

NTARelix wrote: post #111
pcthrowaway wrote: post #96

Earlier quoted context omitted.

> 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.

This is correct, but I think the point nickdandakis was trying to make is that useEffect does not directly correlate with componentDidUnmount because useEffect's returned callback could be called in the middle of the component's lifecycle, not only when the component unmounts.

Err.. no, you pass a callback (let's call it the effect callback) that returns a callback (the cleanup callback) to useEffect. The effect callback gets called when the component mounts, and when dependencies (if any) change. The cleanup callback gets called when the dependency unmounts (and will not be called at other times in the lifecycle)

edit: I'm wrong, the cleanup is also called when dependencies change, just not on mount.. eg. it gets called before the effect callback being called again.

In other words, the cleanup function is called on unmount when useEffect is called with an empty array, and if useEffect has dependencies, it will also be called when those dependencies change

Re: Why React Re-Renders

#114

Post by dceddia »

knodi123 wrote: post #112
pcthrowaway wrote: post #96

Earlier quoted context omitted.

> 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.

Yes, you're correct, and he got it wrong when talking about it . This kind of goes towards my point. useEffect works, and it works great. It's flexible and powerful - but it's cryptic as hell, and the interface is just "memorize it because you have to", not something more intuitive. What if useEffect required a 2nd argument, but you had the option to pass in self, which would still offer the onMount behavior, by mirr…

Oh hey, that's me! :wave:

I definitely agree useEffect is awfully cryptic and easy to get wrong, and I'm happy to be corrected... but I'm not sure how I'm wrong about it running on every render when there's no 2nd argument?

I kinda wish they'd made it easier to do the common operations like onMount and onUnmount by providing some simplified wrappers around useEffect (with less power comes less responsibility... or something). Of course we can make custom hooks for those, but having the well-trodden paths be paved is always nice.

Re: Why React Re-Renders

#115

Post by pcthrowaway »

dceddia wrote: post #114
knodi123 wrote: post #112

Earlier quoted context omitted.

Yes, you're correct, and he got it wrong when talking about it . This kind of goes towards my point. useEffect works, and it works great. It's flexible and powerful - but it's cryptic as hell, and the interface is just "memorize it because you have to", not something more intuitive. What if useEffect required a 2nd argument, but you had the option to pass in self, which would still offer the onMount behavior, by mirr…

Oh hey, that's me! :wave: I definitely agree useEffect is awfully cryptic and easy to get wrong, and I'm happy to be corrected... but I'm not sure how I'm wrong about it running on every render when there's no 2nd argument? I kinda wish they'd made it easier to do the common operations like onMount and onUnmount by providing some simplified wrappers around useEffect (with less power comes less responsibility... or so…

I misunderstood what you were saying about it running on unmount when the dependency array is empty.

Of course, it does run on unmount when the dependency array is empty, and it runs on unmount when there are dependencies in the dependency array.

But upon re-reading what you said, I think your intent was that it's comparable to componentWillUnmount() in class-based React only when the dependency array is empty (because otherwise the cleanup function also gets called when dependencies change).

My apologies, as I never really used class-based React, so the distinction was lost on me (and also forgot about the cleanup function being called between useEffect callback calls)

Re: Why React Re-Renders

#116

Post by SirHound »

knodi123 wrote: post #112
pcthrowaway wrote: post #96

Earlier quoted context omitted.

> 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.

Yes, you're correct, and he got it wrong when talking about it . This kind of goes towards my point. useEffect works, and it works great. It's flexible and powerful - but it's cryptic as hell, and the interface is just "memorize it because you have to", not something more intuitive. What if useEffect required a 2nd argument, but you had the option to pass in self, which would still offer the onMount behavior, by mirr…

useRef does only one thing. It returns an object where the latest value is current. That’s all. Element components will use a ref to put a reference to themselves if you pass one via the ref prop. They can be used to store anything else too. Nothing magic or confusing.

If anything it’d be weirder to make this two separate concepts. What would they even be? What does a ref not already do, as a box that contains an arbitrary value, that we’d want from a box with an element in it?

Re: Why React Re-Renders

#117

Post by dceddia »

pcthrowaway wrote: post #115
dceddia wrote: post #114

Earlier quoted context omitted.

Oh hey, that's me! :wave: I definitely agree useEffect is awfully cryptic and easy to get wrong, and I'm happy to be corrected... but I'm not sure how I'm wrong about it running on every render when there's no 2nd argument? I kinda wish they'd made it easier to do the common operations like onMount and onUnmount by providing some simplified wrappers around useEffect (with less power comes less responsibility... or so…

I misunderstood what you were saying about it running on unmount when the dependency array is empty. Of course, it does run on unmount when the dependency array is empty, and it runs on unmount when there are dependencies in the dependency array. But upon re-reading what you said, I think your intent was that it's comparable to componentWillUnmount() in class-based React only when the dependency array is empty (becau…

Oh gotcha, no worries. I'm not sure if you meant to reply to me anyway, my comment was in regards to knodi123's original comment that linked to an article of mine and said it was wrong about when useEffect re-renders – but the comment was edited and that part is gone, so now mine looks entirely crazy haha.

Re: Why React Re-Renders

#118

Post by acemarke »

TurningCanadian wrote: post #84
acemarke wrote: post #81

Earlier quoted context omitted.

Yeah, we specifically built Redux Toolkit around Immer from the very first prototype that I wrote. I had catalogued _dozens_ of immutable update libs between 2015-2018, and Immer is simply superior to all of them. Which is why Immer is a non-negotiable part of RTK, and something we specifically tell everyone they should be using with Redux: - https://redux.js.org/style-guide/#use-immer-for-writing-immu... - https://r…

Where will the Record & Tuple proposal (Stage: 2) fit in? https://tc39.es/proposal-record-tuple/tutorial/

I'm not sure, tbh.

I agree that having the ability to construct objects/arrays that are compared by nested values, rather than references, will be useful.

But, given that Immer already exists, and only meaningfully requires ES6 Proxy support, I'm not sure how much of an impact the availability of Records will have.

In the case of RTK specifically... Immer is built into `createSlice/createReducer`, and it's _always_ getting called even if you manually create an immutably-updated result yourself. So I don't see any real change or benefit there.

Re: Why React Re-Renders

#119

Post by 8n4vidtmkvmk »

AgentME wrote: post #80
acemarke wrote: post #65

Earlier quoted context omitted.

FWIW, React has always been designed around some Functional Programming type principles, such as immutable updates. Immutable updates do in fact require that if you want to update `state.some.nested.field`, you have to make copies of _all_ objects in that path: `nested`, `some`, and `state`. This isn't unique to React. Yes, class component `this.setState()` lets you get away with mutations. That's not really a _good_…

When updating deeply-nested immutable objects, the Immer library is great. You call the `produce(immutableValue, draft => { ... })` function with some immutable value and a callback function that manipulates a mutable proxy object mimicking the immutable value, and then the function returns a new immutable value with the same changes made by the callback function. The mutable proxy object never escapes the callback,…

i dont like proxy magic, its bitten me before. immutability helper ftw

Re: Why React Re-Renders

#120

Post by 8n4vidtmkvmk »

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…

why? i personally like the "tear down" aspect effects. often times you have to clean up/unregister things when props change or component is unmounted. this leads to 5 random initializers in component class ctor and 5 random cleanups in onUnmount or whatever it was called. they're separated so its hard to correlate them. but even worse is that you cant encapsulate that by creating your own useX function. you could create HOCs but those were kind of clunky
Post reply on HN