Approaching React performance with Halogen

[garyb]

@milesfrain

It seems like React.PureComponent does state diffing. I notice with Halogen that if I update the new state to match the previous state, then a re-render will still be triggered. The halogen guide shows an example of using when (oldN /= n) $ H.put n , but I wonder if this is a capability that could/should be built-into components.

Ah right, I wouldn’t have described that as state diffing, since it’s not comparing state values any more deeply than “is it different?”.

The when situation for state modification is there as a means of preventing unnecessary rendering based on the component receiving an input, yeah. Without explicitly guarding here the child will re-render any time a parent re-renders, negating one of the benefits of using components. This guarding doesn’t happen automatically as we didn’t want to impose an Eq constraint on component state, as that is far too restrictive in general.

This is because every modify in halogen will cause a render (unless the state is referentially equal to the previous value… this is a hack to prevent re-rendering on get also, due to the way MonadState is defined, rather than something we specifically wanted)

@milesfrain

I probably misinterpreted these two pieces of advice as performance-based, rather than developer-convenience-based

I guess I should emphasise that distinction in the Halogen docs, since yeah it’s pretty much the opposite of what you thought - before lazy and memo using components was the only way of taking control over situations like this.

@milesfrain

To confirm, would you use a Halogen component for each todoRow in this React todo-app ?

It’s right on the threshold of where I’d make a component, I could go either way. I think maybe no in this specific case, because there’s a need to see the overall state of completeness of the items and it’s convenient to do that having all the item state accessible, but if they had one more interaction/piece of modifiable state each, then I’d probably switch them to components.

For your example, one thing that might be worth trying is not making each item into a component, but making the whole list part a child component. You could still even populate it dynamically with entries passed down as an input to that component (with the aforementioned guarded update in the list component’s receiver). This should improve things because the only diffing that will take place then is for the vdom specifically rendered by the outer component, where the text changes. The list entries would be isolated from that diff because of the component boundary, which should speed things up greatly both in avoiding rendering vdom nodes for the items, and then not having to diff them again, which is still an overhead even in my suggestion of making the rows static.