Live data from Hacker News

Optimizing React Rendering

flexport.engineering

1–10 of 79 posts

Re: Optimizing React Rendering

#3
post #2

This is actually a pretty decent article, in part because it signals its audience properly: (semi-?)experienced React developers who haven't dealt with optimization yet.

so basically the Facebook app team?

Edit: sorry guys, didn't knew you were all on HN :(

Re: Optimizing React Rendering

#5
From the article:

> Fixing the issue is pretty simple*. We simply need to short circuit the re-rendering for a subtree if we know that the subtree hasn’t changed.

Not a frontend guy but I've seen this theme more than once on HN recently. It seems to me that addressing this anti-pattern would be built right in to modern React components. Isn't efficient DOM manipulation by pruning non-necessary changes kind of their thing?

Re: Optimizing React Rendering

#6

From the article: > Fixing the issue is pretty simple*. We simply need to short circuit the re-rendering for a subtree if we know that the subtree hasn’t changed. Not a frontend guy but I've seen this theme more than once on HN recently. It seems to me that addressing this anti-pattern would be built right in to modern React components. Isn't efficient DOM manipulation by pruning non-necessary changes kind of their t…

React won't update the DOM when render returns the same result but if you can avoid those unnecessary render calls you save some scripting time. Front-end developers have to be very conservative when it comes to running JS code. Welcome to single threaded everything programming!

Re: Optimizing React Rendering

#7

From the article: > Fixing the issue is pretty simple*. We simply need to short circuit the re-rendering for a subtree if we know that the subtree hasn’t changed. Not a frontend guy but I've seen this theme more than once on HN recently. It seems to me that addressing this anti-pattern would be built right in to modern React components. Isn't efficient DOM manipulation by pruning non-necessary changes kind of their t…

It is, so a DOM change wouldn't occur, but in these cases you still go through a React rendering to virtual DOM phase (templating) and the DOM tree reconciliation.

Since these can be slow (although much faster than a DOM change), it makes sense to check and skip those steps when you can.

The focus of most of this article is how you can skip those steps when you're components input data is unchanged and common gotchas related to that.

Some other great posts in this vein are: https://facebook.github.io/react/docs/optimizing-performance... and http://benchling.engineering/performance-engineering-with-re...

Re: Optimizing React Rendering

#8

From the article: > Fixing the issue is pretty simple*. We simply need to short circuit the re-rendering for a subtree if we know that the subtree hasn’t changed. Not a frontend guy but I've seen this theme more than once on HN recently. It seems to me that addressing this anti-pattern would be built right in to modern React components. Isn't efficient DOM manipulation by pruning non-necessary changes kind of their t…

I think it is an anti-pattern that is a result of the language it's built on.

This is one place where using Clojurescript wrappers of React has a real payoff - immutable datastructures make equality checking very very cheap.

Re: Optimizing React Rendering

#10
Is there special logic in react that binds arguments of a function to the props with the same name? I'm talking about the handleDelete "fix" in the article:

    render() {
        const views = this .props.dataList.map((d, i) => {
            return 
        });
    }
    handleDelete(index) {
        //...
    }
I guess they just call that function from within the Data component with the correct parameter. But then, Data component needs to know how to call that function. Is there a better way?
Post reply on HN