3 ms·

The forceUpdate API is murderous for performance, since it causes the entire tree to do a vdom rerender, bypassing shouldComponentUpdate() checks. Should really

by b34r 11y ago

The forceUpdate API is murderous for performance, since it causes the entire tree to do a vdom rerender, bypassing shouldComponentUpdate() checks. Should really try and find another way to trigger a re-render.

dominic_cocch 11y ago
Definitely agree. In our real code we're much more sensitive of performance. This was just a quick way to show a simple way Backbone can be used with React. I think it'd be interesting for us to do another post in the future about how we measure and improve performance within our React apps. There aren't a ton of articles about this with relation to Bakcbone, it seems. Thanks for giving it a read!
- rgbrgb 11y ago
  Would definitely like to read that one. We have a backbone/react app and generally use your example pattern, but I can see how it would take a toll on performance at some point. What's the general pattern you use if not forceUpdate? I suppose you could use something like @setState(model: model) but you still have mutable models to deal with in shouldComponentUpdate. Have you guys come up with a good way to reconcile backbone's tendency towards mutation and the performance benefits of immutable props?
  - dominic_cocch 11y ago
    Yes and no, really. We mostly keep our backbone models as props and keep them immutable by pure convention. You really could just call set() on one of them and cause some problems. This isn't great long term, of course. Code reviews and code style guides help here for now. We've also at times converted backbone models to simple objects at the parent level and passed them down that way. Keeps things simpler, but we lose some of the niceties of the backbone model api. Once the models are objects, you can use componentShouldUpdate pretty defensively if you need. We've also used throttled and debounced functions for anything which gets hit very heavily.
AgentME 11y ago
I'm not exactly disagreeing with you, but forceUpdate only bypasses the component's own shouldComponentUpdate check. It doesn't necessarily do a "deep" re-render including all of the component's children. The children have their shouldComponentUpdate check run as normal.
amelius 11y ago
shouldComponentUpdate is also slow, since it still requires all children of a big component to be tested every time, even if only one child needs updating.

by b34r 11y ago

dominic_cocch 11y ago

Definitely agree. In our real code we're much more sensitive of performance. This was just a quick way to show a simple way Backbone can be used with React. I think it'd be interesting for us to do another post in the future about how we measure and improve performance within our React apps. There aren't a ton of articles about this with relation to Bakcbone, it seems. Thanks for giving it a read!

rgbrgb 11y ago
Would definitely like to read that one. We have a backbone/react app and generally use your example pattern, but I can see how it would take a toll on performance at some point. What's the general pattern you use if not forceUpdate? I suppose you could use something like @setState(model: model) but you still have mutable models to deal with in shouldComponentUpdate. Have you guys come up with a good way to reconcile backbone's tendency towards mutation and the performance benefits of immutable props?
- dominic_cocch 11y ago
  Yes and no, really. We mostly keep our backbone models as props and keep them immutable by pure convention. You really could just call set() on one of them and cause some problems. This isn't great long term, of course. Code reviews and code style guides help here for now. We've also at times converted backbone models to simple objects at the parent level and passed them down that way. Keeps things simpler, but we lose some of the niceties of the backbone model api. Once the models are objects, you can use componentShouldUpdate pretty defensively if you need. We've also used throttled and debounced functions for anything which gets hit very heavily.

AgentME 11y ago

I'm not exactly disagreeing with you, but forceUpdate only bypasses the component's own shouldComponentUpdate check. It doesn't necessarily do a "deep" re-render including all of the component's children. The children have their shouldComponentUpdate check run as normal.

amelius 11y ago

shouldComponentUpdate is also slow, since it still requires all children of a big component to be tested every time, even if only one child needs updating.