Don't lock render before calling view function.

Recently I have been playing around with modules that map external state of things like mouse, scroll and location to hyperapp state. I have observed that it certain cases when update is called in rapid succession; that the data used in the last render is not the data in the state.

If I remove the skip render check (but leave rAF), the behaviour goes away:

function repaint() {
  if (props.view) { requestAnimationFrame(render) }
}

I started looking at requestAnimationFrame as I haven’t used it since I experimented with WebGL years ago. From what I can gather:

• Requests that the browser call a specified function before the next repaint
• You should call this method whenever you’re ready to update your view onscreen

It doesn’t say anything about skipping renders 🤔 and it makes me wonder why we are doing this? I have always thought of requestAnimationFrame as like a smart debounce/throttle which you throw whatever you want at, and it makes sure not to over compute.

Looking at the current setup it seems that a state update assign(state, data) could be made, which calls repaint() when skipRender is true meaning that render is never called. This would explain the behaviours I have witnessed.

Interestingly removing all trace of skipRender seems to have no adverse effects at all on hyperapp even when challenged with rapid state updates. Do we need it for some reason I am not remembering?

[SkaterDad]

If you could join us on slack, you’d see, it was a 2 hour long discussion with Luke.

Unfortunately my work blocks Slack, so I miss out on that sort of thing. I look forward to seeing what comes out of it, though. 👍

[SkaterDad]

@lukejacksonn I agree that last snippet looks appealing. The dynamic nature of component routes is also pretty neat.

I’m hesitant because of the way hyperapp re-runs the whole view() function on every state update. In your sample, it wouldn’t be an issue unless some other action (potentially unrelated) triggered a state update before your actions.fetchData() finished. In that case, you’ll end up calling fetchData() again.

Easy enough fix in this case, but does this approach scale up to even more complicated apps? Some ideas could be borrowed from RemoteData for elm?

div([
  !state.fetching && actions.fetchData(),
  state.fetching ? div('Fetching..') : ul(state.data.map(li))
])

I look forward to being able to play around with this approach. For now, I built a HOA routing solution that works for me (routes pre-defined and passed in up front), so I might be able to upgrade my main project from 0.12.1 at long last 😄