@sova: that's a solution to a component not updating. My issue is the component updates milliseconds too late, causing a flicker. :(

@anmonteiro @sova I seem to have gotten it to work. (p/reconcile! reconciler) seems to do the job. (not even (.reconciler! reconciler) for some reason.)

probably because the name is munged. (.reconcile_BANG_ reconciler) would probably do it

not that you wanna do it 🙂

@levitanong hrm, so now that you discovered that works, I may have a less hacky solution for you 🙂

force-root-render! also works btw

so Om Next has this async rendering loop, which on browsers is implemented through requestAnimationFrame

but requestAnimationFrame won't probably exist in React Native

so it’s on the timeout loop

so Om Next falls back to setTimeout

that might be flaky for a bunch of reasons

@levitanong you can override the function that queues the render loop by binding om.next/*raf*

(looks like requestAnimationFrame exists on react native though. https://facebook.github.io/react-native/docs/timers.html)

ah hrm.

but would overriding the function work anyway?

probably

you could even make it synchronous

https://github.com/omcljs/om/blob/master/src/main/om/next.cljc#L1426

and i suppose I could override *raf*, and somehow unbind it later on to bring it back to asynchronous rendering?

definitely

just set! it to nil and requestAnimationFrame will be called

nice! will try that out. Thanks, @anmonteiro!

@anmonteiro overriding *raf* works! Unsetting it doesn’t seem so easy though, because it has to be unset after the rendering finishes.

and putting the unsetting code in a setTimeout feels unsafe.

don't the lifecycle methods help you in that case?

oh right, I’ve been putting them in the parser, but now it’s not necessary since i’m not touching the reconciler.

was wondering though, if (binding [om/*raf* (fn [f] (f))] (p/schedule-render! reconciler)) work

i realize, probably not.

I've been experimenting with the "raf" npm lib and om inside a dev-om-card to implement a TimeLoop component and it works better than I expeced! I still don't fully understand how requestAnimationFrameworks works too I just copied an example from gl-react to build my om component...

I too used react-set-state! to bypass om rendering loop but I ended up mutating the :timeloop/tick state that my components who need to animate based on tick are already querying that same :timeloop so maybe it's wrong to do it using requestAnimFrame. .? I would enjoy seeing some related code... 🙂

request animation frame calls a function when the machine says it’s ready to render a new frame.

this allows the program to keep going without slowing down due to expensive render jobs

i.e. raf lets you tell the machine to do something only when it’s ready to.

Yeah I understand that much but I'm still confused as to how it works with om next rendering loop. If I have a TimeLoop component that mutate say :tick and other components should do something when tick changes (possibly render) then the reconciler will triger rendering for the corresponding component by walking it's om-root... when I use om/react-set-state! and raf, I bypass that and only do that when the browser feels like it (based on free cpu and refresh rate etc..) ?

It seems to be what my experiment have tought me 🙂

but I confused things a little and have the "raf" callback do an om/transact! on the timeloop :tick so that probably trigers the om-root rendering through om next as well I think...

Here is my timeloop hack if you are curious: https://www.refheap.com/124988

I think I need two kind of timeloop for my games... One like that using raf running at 30-60fps (if cpu can keep up) for my visual effects and one using core.async that run at steady 5-10 fps for my game logic.

@levitanong glad you got it werkn.