# om

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

sova 01:01:35

@levitanong (om/transact! ..) takes 2 args, one is a component and the rest can be mutates_and_keys_to_be_re-read ... I just figured that out yesterday, it may be germane to what you're doing.

levitanong 05:52:27

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

levitanong 07:48:00

@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.)

anmonteiro 07:55:19

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

anmonteiro 07:55:29

not that you wanna do it :slightly_smiling_face:

anmonteiro 07:56:13

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

levitanong 07:56:33

force-root-render! also works btw

anmonteiro 07:56:53

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

anmonteiro 07:57:45

but requestAnimationFrame won't probably exist in React Native

levitanong 07:57:59

so it’s on the timeout loop

anmonteiro 07:58:06

so Om Next falls back to setTimeout

anmonteiro 07:58:21

that might be flaky for a bunch of reasons

anmonteiro 07:59:28

@levitanong you can override the function that queues the render loop by binding*raf*

levitanong 07:59:35

(looks like requestAnimationFrame exists on react native though.

levitanong 07:59:55

but would overriding the function work anyway?

anmonteiro 08:00:06


anmonteiro 08:00:10

you could even make it synchronous

levitanong 08:00:58

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

anmonteiro 08:01:32


anmonteiro 08:02:00

just set! it to nil and requestAnimationFrame will be called

levitanong 08:02:20

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

levitanong 08:12:19

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

levitanong 08:12:41

and putting the unsetting code in a setTimeout feels unsafe.

anmonteiro 08:13:09

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

levitanong 08:13:59

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

levitanong 08:14:38

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

levitanong 08:16:18

i realize, probably not.

sineer 21:50:33

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...

sineer 22:02:17

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... :slightly_smiling_face:

levitanong 22:23:49

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

levitanong 22:24:38

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

levitanong 22:24:59

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

sineer 22:30:38

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..) ?

sineer 22:33:34

It seems to be what my experiment have tought me :slightly_smiling_face:

sineer 22:35:14

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...

sineer 22:38:16

Here is my timeloop hack if you are curious:

sineer 22:53:07

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.