# om

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

denik 04:19:17

@peeja sorry. I mean if I change the code in initLocalState I want the component to re-mount.

peeja 04:28:04

@denik Oh, does it not? It does for me.

peeja 04:28:35

In my app, my components lose local state when Figwheel uses that code to reload, and they get whatever's in init-state

danielstockton 10:21:27

I tried it, they get fired immediately (which means if it's a remote call, it is sent in the same request as the mutation itself).

danielstockton 10:22:38

Not sure about the indexer indexing transacts but the indexer will update components that have queries reading keys that are merged in, or keys returned by :keys from merge.

carter.andrewj 13:33:31

Hi guys, I've been dipping my toe into for the last few months and - while I've been able to get things working - I'm pretty sure I'm effectively hacking my way around some blind-spots I have with how I'm supposed to be using it and, now I'm stepping up my usage, I'd like to know how to do it properly

carter.andrewj 13:44:29

My current problem centres around data distribution across the app. I'm building a set of dashboards that pull data from a remote. The data is live and so needs to be refreshed at regular intervals. I have a component at the root to manage this, and the UI tree instantiates view components that require some subset of data from the root store. What I'm unsure of is - when a new view component is instantiated, what's the correct way to communicate to the manager that it needs to fetch more data from the root (and what that data needs to be)?

carter.andrewj 13:46:50

Specifically - mutate? set-query? via a channel?

danielstockton 14:17:54

I think we all feel the way you do, at least I do. I think it's whatever works for you. FYI, transact! can be used to trigger reads as well as mutations.

danielstockton 14:19:46

You could (transact! this [:root/query-fragment]) some query fragment.

carter.andrewj 16:50:11

Good to know I'm not alone, at least :slightly_smiling_face:

carter.andrewj 16:51:10

Yes - currently using transact, but within the manager component (via a channel), rather than the views (there were ordering issues otherwise)

danielstockton 17:03:29

I don't think there is anything inherently wrong with channels either, it depends what you discover to be easier and more maintainable.
If you settle on any good patterns, I'm sure we'll all be interested to hear about them.
How are you passing the channels around? With :shared?

carter.andrewj 17:17:52

Currently it's just stored in a global variable (didn't seem worth the investment in something more detailed yet - still not sure if it's the solution I'll stick with) but would probably move to :shared if it sticks around

gardnervickers 17:45:29

Is it possible to call om/ident server-side?

mitchelkuijpers 18:00:24

I would think that would be possible if your components is written in cljc

gardnervickers 18:30:52

I can call the instantiated component, but it looks like the class is backed by AFunction$1 which I can’t call ident on.

peeja 20:14:25

@carter.andrewj You may be better off using a separate remote for your live data and then forceing that remote from a transact!:

peeja 20:14:56

By using a separate remote, you can leave it up to the parser to decide which data is live

peeja 20:15:55

Then you can transact! to re-read the entire root query, but because you've forced a specific remote, only the parts that the parser says should be sent to the live remote will actually be fetched

carter.andrewj 20:19:24

Interesting - is there any more documentation on that with examples, etc...?

carter.andrewj 20:19:46

(Somewhat reluctant to unpick so much code without knowing where I hope to end up)

peeja 20:22:52

Not that I know of. But AFAIK there's no particular pattern for this that would be documented; I just made that up in response to your question.

carter.andrewj 20:28:05

Is it possible to have separate merge! fns for each remote...?

carter.andrewj 21:26:06

Okay - and another one :slightly_smiling_face: - if I have a query [(:data {:sources ?sources}) :things :stuff] which gets rolled into the query of a parent component, can I still have a separate read method for :data, :things and :stuff? I can't figure out what the reason would be for not allowing this - but (unless they're keys in the root component), it seems not to be possible. Am I just cocking up somewhere? Or do nested queries like this not work by design?

bnoguchi 21:42:18

Where is the best place to override the dynamic var om/*raf*? om/*raf* is called inside callbacks, so binding the new value around om/add-root and other calls to om don't appear to preserve the overriding binding.

anmonteiro 21:43:05

@bnoguchi you may have to just (set! om/*raf* ...)

anmonteiro 21:43:12

if you want it globally

bnoguchi 21:43:20

Got it, thanks!

sineer 23:41:27

@anmonteiro Thank you very much for your (and Mike) presentation on "teleport testing" is great! I was looking for a way to take devcards to the next level for webgl game dev with om/datomic and you gave me lots of great ideas :slightly_smiling_face: