41–50 of 79 posts
Would using mobx to manage state solve most of these problems?
We've just started using mobx ourselves. There's still a weird contention between events and state that I'm yet develop patterns for but overall I'm really happy with it.
Earlier quoted context omitted.
The reason arrow functions and bind don't play well with PureComponents is that they return a new function instance each time. This means that the Data pure component will wastefully re-render even if none of the other props change.
Only if you did that in the render function. If you did this.foo = this.foo.bind(this, props.bar) in the constructor then it would be the same function each time.
Earlier quoted context omitted.
Only if you did that in the render function. If you did this.foo = this.foo.bind(this, props.bar) in the constructor then it would be the same function each time.
If you do that in the parent constructor it only really works for a single child and then you're better off not partially evaluating and instead having it pull props.bar at execution time
eg: it's going to be used as a event callback but you want the function signature to be foo(bar, event). Then you get the benefits of partial application without the problems of currying a new function each time its called.
source: have used this a lot for event handlers, especially when dealing with on 3rd party code.
Earlier quoted context omitted.
The reason arrow functions and bind don't play well with PureComponents is that they return a new function instance each time. This means that the Data pure component will wastefully re-render even if none of the other props change.
Only if you did that in the render function. If you did this.foo = this.foo.bind(this, props.bar) in the constructor then it would be the same function each time.
In general binding like that in the constructor works only if you depend on props, but at that point, there isn't a need to bind at all since you can just reference the prop in the callback.
Earlier quoted context omitted.
If you do that in the parent constructor it only really works for a single child and then you're better off not partially evaluating and instead having it pull props.bar at execution time
Sure, it would be an odd pattern but perhaps a required one for a certain interface. eg: it's going to be used as a event callback but you want the function signature to be foo(bar, event). Then you get the benefits of partial application without the problems of currying a new function each time its called. source: have used this a lot for event handlers, especially when dealing with on 3rd party code.
I guess my point was that it doesn't scale to multiple children (which is effectively what the question was about). And whether you want to partially apply a bound function in the constructor or just bind and then have the function pick up the extra arg itself - it's the same thing. You end up with a single function that works with a single constant.
Though, in your case if props change, the partially applied function is now incorrect. Which is why I think I'm misunderstanding you.
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 :(
I am more concerned that the code that runs during a re-render is not rebuilding huge static lists that never change and so. I see that over and over again in React apps. I tend to build a lot of the static stuff in the ComponentWillMount stage to prevent that. Only when already optimised code is getting to slow I start thinking about preventing re-rendering if possible.
My reason for not starting with ShouldComponentUpdate is that you have to be very careful not creating nasty bugs with that like I did some times. If a year later you write some code and it doesn't work for some reason it is painful if you find out after a long search that a stupid child component did not update for some prevention rule you forgot about. I really try hard to avoid premature optimisations.
> So all you have to do is use PureComponent everywhere and you’re good to go. There’s nothing more to it. Enjoy your new blazing fast React app! (I work on React.) This isn't quite right. If we recommended that PureComponent be used everywhere, it would probably be the default already. Rather -- the comparison to decide whether or not a component should be rerendered costs something, and in the case that you do want…
How do function(al?) components compare in performance to PureComponents? e.g., const MyComponent = props => (...); vs class MyComponent extends PureComponent {...}
Even if I agree that premature optimization is the root of all evils, I like when the language and the framework I use make it writing fast code as easy as writing slow code.
I wonder if anybody has evaluated, the improvement they get in development speed using React when they add the time they have to spend to optimizing their React code.
In my experience, I am not even frustrated with React itself most of the time but with the other things in the ecosystem.