Default implementation for shouldComponentUpdate? about purescript-thermite HOT 3 CLOSED

Interesting. I wonder if this should use referential equality or an Eq state instance. It might cause a slowdown if it's a default implementation, but puts the burden on the developer to implement Eq.

So I understand, in what cases does referential equality lead to a performance improvement? For most PS data types, === would rarely evaluate to true in practice, right?

from purescript-thermite.

Edit: somehow managed to submit this while typing.

Just to be clear, it's not just === on the objects themselves, but also checking for reference equality on their field values as well. So in thermite, when properties are assembled into new property objects from the Props list, it's true that the reference equality of the property objects will not hold, but it is possible that the reference equality of all their fields holds. Field equality is more likely to hold when the properties are passed in directly.

A couple cases I encountered while playing with purescript-signal and virtual-dom.

1. Let's say you have a model that is processing a fast incoming event stream, like mouse position or drag events, and it's being rendered to a complicated GUI. The GUI can't render fast enough to keep up, so you decide to downsample using sampleOn to sample at, say, 50 ms. However, sampleOn will fire an event every 50 ms whether the signal it's sampling changed or not. To get around this, I used distinct' in combination with sampleOn. The result is a reference equality check every 50 ms, and only when reference equality fails does the GUI re-render. This puts an upper bound on GUI refresh rate. Using shouldComponentUpdate with reference equality is similar to using distinct' in this example.
2. Your GUI displays info about the model state. Your model processes incoming messages to update state, but some cases results in no change to the state. In that case, returning the state unchanged to the GUI render function should satisfy reference equality, so the GUI doesn't need to update. This case is similar to 1) above if the messages are coming in at a high rate.

As for implementation, I think reference equality is the way to go. My aim here is not to eliminate all unnecessary GUI updates, but only to eliminate those that are easy to guard against in a convenient way. If the new props and state are the same as the old ones, or their field values are the same as the old values, then there is nothing to update.

Using Eq instance, to me, is a little too far removed from the philosophy of "just rerender the GUI every update" because now the Eq instance is essentially responsible for determining whether the GUI should redraw or not. Also, we don't want the props to need to be wrapped in newtypes in order to define typeclasses for them (at least I don't).

from purescript-thermite.

I think this should be implemented in purescript-react, or another library.

from purescript-thermite.