Thanks, Richard.
I'm pretty sure I had tried that earlier, and the element wasn't there yet.
I had to nest two `requestAnimationFrame` calls within each other, or a mix
of `rAF` and `setTimeout` with 1 or 0 as delay. And I would see a short
flicker on the screen before my scroll code executed. I was suspecting that
the port call was made before Elm itself called `rAF`, which would make my
call to `rAF ` run before Elm's.
But now it works beautifully with just one (like you say):
app.ports.scrollIntoView.subscribe(selector => {
window.requestAnimationFrame(() => {
let el = document.body.querySelector(selector)
if (!el) {
throw new Error(`scrollintoView error: Element not found by selector
'${selector}'.`)
}
el.scrollIntoView()
})
})
Is Elm's execution order of port calls and DOM updates always
deterministic? I.e.:
- Elm app's `update` function is called and returns with new model and
command
- Elm calls `requestAnimationFrame` (to batch DOM writes)
- Commands on ports are called into JS
Thanks,
Sebastian
On Tuesday, January 3, 2017 at 10:54:20 PM UTC-8, Richard Feldman wrote:
>
> Hi Sebastian,
>
> Elm batches DOM updat`es using requestAnimationFrame
> <https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame>,
>
> so you should be able to delay until after the next DOM update by wrapping
> your entire callback (starting from let el = document.body.querySelector(
> selector)) in a call to requestAnimationFrame.
>
> See if that works!
>
--
You received this message because you are subscribed to the Google Groups "Elm
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
