Live data from Hacker News

Why React Re-Renders

joshwcomeau.com

131–140 of 168 posts

Re: Why React Re-Renders

#131

Earlier quoted context omitted.

> if you don't mess with useMemo (which you generally shouldn't) why? is this not the primary way to re-init expensive internal component state when specific props change?

GP's claim is a little too strong, but in my experience most uses of `useMemo` / `useCallback` are only necessary because people define things in the wrong scope, or write giant spaghetti components with 15 different props and no internal structure. The best memoization technique is not calling things repeatedly in the first place.

I find it necessary for a lot of different types of patterns that optimize performance. See the very recently written beta react docs, they go over this quite well.

In general, I think it's always a mistake to tell people "don't use this tool because you may shoot yourself in the foot", best to explain the when and why. But I do have a problem when the tool has just stupid defaults that make it harder to use correctly in the first place.

Re: Why React Re-Renders

#132

The blog is sooo good! I enjoyed every single paragraph when reading it. If you're confused about the last part where it mentioned where useMemo and useCallback can help when passing props, I completely understand after reading Kent C Dodds block and Dan Abramov. Further, I learned a lot by taking interactive course from Dan Abramov in https://justjavascript.com Highly recommended! good read!! https://kentcdodds.com/…

To follow up on that, the new beta react docs are largely written by Dan, and they explain the concepts very well, more formally. IMO they're a must-read, even if they're not quite final (some sections missing because they're doing each part carefully one at a time). They're a great refresher and/or confirmation that you're "doing it right", and there's many lessons to be brought into how you approach writing and reviewing components.

Re: Why React Re-Renders

#133
post #16

Earlier quoted context omitted.

The new version of the official docs is currently in Beta and this is really, really good: https://beta.reactjs.org/learn (In fact, I'll go further than this and add that the section on "Escape Hatches" should be re-read by senior/lead engineers, as many have misconceptions due to learning concepts ad-hoc from code of mixed quality: https://beta.reactjs.org/learn/escape-hatches )

Hmm. The escape hatches page is just “coming soon” for me?

That page is just the "category header" for a bunch of other pages. Look at the sidebar (or on mobile, hamburger menu) to see the actual content.

Re: Why React Re-Renders

#134

I sometimes wonder what people are using React for, that they wouldn’t know this or have figured it out along the way. Let me kind of explain, as best I can, without code. We have a complex software product, an integrated compliance and risk management system with embedded workflow, automatic highlighting of potential risks due to non-compliance, plans of actions (aka risk management plans), RBAC, ABAC (used to contr…

You could have achieved the same thing with Mobx stores without having to pass a handler around everywhere. Although it sounds you're using context-dependent state that don't need to exist globally. Well, it would still work and you'd only need to know a couple of Mobx pitfalls in order to make it render efficiently. So no, you don't need to understand React state management model completely in order to build working apps.

Re: Why React Re-Renders

#135

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…

In the beginning React was a great example of high payoff of just a little bit of "memorize it because you have to."

For many projects it felt like it gave you super powers, for some it was just OK, and a small percentage of interfaces just didn't fit the React model and were better some other way.

It appears to me that since then that small percentage has gotten the development attention (understandably), creating a React which is more well rounded and broadly useful but there is more to learn and the super power feeling has been dulled a bit.

Overall it has improved but I still wonder what a React that was more specialized for those interfaces where it really works great would be like.

Re: Why React Re-Renders

#136

React would have been great in a functional language with immediate data structures. Instead it’s used with JavaScript, where you have to constantly force yourself to create your prop objects in a very specific way to avoid or force (re)rendering. It’s a constant struggle to control re-rendering. I still can’t believe React became as big as it is. Vue and Angular just fit JavaScript better.

> 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

Re: Why React Re-Renders

#137
post #16
post #5

If you don’t mind a slight tangent, where would you start today to learn front end development with React such that you learn this sort of thing as you go?

The new version of the official docs is currently in Beta and this is really, really good: https://beta.reactjs.org/learn (In fact, I'll go further than this and add that the section on "Escape Hatches" should be re-read by senior/lead engineers, as many have misconceptions due to learning concepts ad-hoc from code of mixed quality: https://beta.reactjs.org/learn/escape-hatches )

[deleted]

Re: Why React Re-Renders

#138
My brain reads the title as "why not calling `render()` manually?".

Probably unpopular opinion: manually call `render` is always better.

Creating your own `ui = f(state)` is very trivial with DOM event, custom element, and a whatever 5kb pure view lib. With event delegation technique and a global store, I can build almost whatever ui with this pattern.

Re: Why React Re-Renders

#139
post #93

Earlier quoted context omitted.

> But it is tremendously wasteful to make a complete copy of a large data structure! You don't make a complete copy: you make a shallow copy of the spine, and then only descend along the fields you actually modify. The number of operations scales as O(branching factor * depth), not O(size).

> You don't make a complete copy: you make a shallow copy of the spine, and then only descend along the fields you actually modify. Sounds painful.

You can have the computer automate tedious tasks for you.

Re: Why React Re-Renders

#140

My brain reads the title as "why not calling `render()` manually?". Probably unpopular opinion: manually call `render` is always better. Creating your own `ui = f(state)` is very trivial with DOM event, custom element, and a whatever 5kb pure view lib. With event delegation technique and a global store, I can build almost whatever ui with this pattern.

It's both. You should be able to control it, but can have a same default that does it for you automatically under certain conditions. Unfortunately React forces the latter only
Post reply on HN