Lazy rendering

[pkamenarsky]

Inspired by elm-html. I've flipped the arguments though, because it's more useful this way imo:

renderSomething props state -> lazy2` props state \props state -> [ div [] [...] ]

[paf31]

Looks good in general, but I'm not sure about whether using reference equality like this is a good idea. It will fail for all but the simplest inputs, for example, most algebraic data types.

[ethul]

I think this is good idea. I am wondering however if this could possibly stand on its own as purescript-react-lazy (or something of the sort). My gut feeling is this might be the way to go. Similar to #64, I think features that are not part of the React JS core might be nice as independent libraries. What do you think?

PS - Referring to #64, contexts are technically part of React, but they are still experimental.

[pkamenarsky]

@paf31: What do you mean?. So let's say you have some state {name :: String, msgs :: Array String} and there are 1000 items in msgs, one would use lazy like this:

renderMessages state = lazy state.msgs \msgs -> div [] [...]

The idea is to perform a fast check and see if msgs might have changed. Comparing two arrays with 1000 items in them for equality would defeat the whole purpose. Yes, it would fail sometimes when the data is equal but the reference changed (although I can't come up with a use case where that would happen regularly), but then it won't be worse than rendering without lazy anyway.

@ethul: I thought about that too. On the other hand, I think the advantages of immutable data and fast equality checks for making a component render really fast (especially when using a single global state and every keystroke leads to recomputing, diffing and patching a potentially very large DOM tree) are way undersold in the Purescript frontend ecosystem. Elm is doing a really good job here. This is why including React.Lazy in purescript-react and specifically telling people about it in the docs might be a better move here (at least for now). But I'm not opposed to creating a separate package either.

[pkamenarsky]

By the way, lazy2 won't work, I need to patch it.

[ethul]

@pkamenarsky I am still torn on whether this functionality would be better in a separate package. I might have to give it some more thought. In terms of performance benefits, is there a practical way to obtain benchmarks? I would be interested to see Lazy compared to stateless classes, etc. Not sure how easy this would be to do. But I think it could be very informative.