Clojurians
#om
<
2017-04-05
>

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

denik01:04:17

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

peeja01:04:04

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

peeja01:04:35

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

danielstockton07:04: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).

danielstockton07:04: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.andrewj10:04:31

Hi guys, I've been dipping my toe into om.next 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.andrewj10:04: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.andrewj10:04:50

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

danielstockton11:04: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.

danielstockton11:04:46

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

carter.andrewj13:04:11

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

carter.andrewj13:04:10

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

danielstockton14:04: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.andrewj14:04: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

gardnervickers14:04:29

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

mitchelkuijpers15:04:24

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

gardnervickers15:04: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.

peeja17:04:25

@carter.andrewj You may be better off using a separate remote for your live data and then forceing that remote from a transact!: https://github.com/omcljs/om/wiki/Documentation-(om.next)#force

peeja17:04:56

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

peeja17:04: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.andrewj17:04:24

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

carter.andrewj17:04:46

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

peeja17:04: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.andrewj17:04:05

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

carter.andrewj18:04: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?

bnoguchi18:04: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.

anmonteiro18:04:05

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

anmonteiro18:04:12

if you want it globally

bnoguchi18:04:20

Got it, thanks!

sineer20:04: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:

thosmos21:04:42

@carter.andrewj in order to have your child component's individual parse methods called, your parent's parse method would need to call the parser again on the child's query

carter.andrewj21:04:19

@thosmos can that be done? Is there a standard way of doing that or would I be destructuring/restructuring the ast?

anmonteiro21:04:50

@sineer awesome! thanks

wilkerlucio22:04:36

@carter.andrewj the parser and the query are available at the environment