om

Please ask the channel first, not @dnolen directly!
denik 2017-04-05T01:19:17.828331Z

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

peeja 2017-04-05T01:28:04.897101Z

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

peeja 2017-04-05T01:28:35.901345Z

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

carter.andrewj 2017-04-05T10:33:31.081472Z

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.andrewj 2017-04-05T10:44:29.212628Z

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 2017-04-05T10:46:50.240796Z

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

2017-04-05T11:17:54.614005Z

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.

2017-04-05T11:19:46.635238Z

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

carter.andrewj 2017-04-05T13:50:11.016836Z

Good to know I'm not alone, at least πŸ™‚

carter.andrewj 2017-04-05T13:51:10.039373Z

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

2017-04-05T14:03:29.328679Z

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 2017-04-05T14:17:52.664450Z

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 2017-04-05T14:45:29.335853Z

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

mitchelkuijpers 2017-04-05T15:00:24.713629Z

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

gardnervickers 2017-04-05T15:30:52.478414Z

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 2017-04-05T17:14:25.855052Z

@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

peeja 2017-04-05T17:14:56.866184Z

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

peeja 2017-04-05T17:15:55.888315Z

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 2017-04-05T17:19:24.963682Z

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

carter.andrewj 2017-04-05T17:19:46.971568Z

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

peeja 2017-04-05T17:22:52.039288Z

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 2017-04-05T17:28:05.154469Z

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

carter.andrewj 2017-04-05T18:26:06.452533Z

Okay - and another one πŸ™‚ - 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?

2017-04-05T18:42:18.813171Z

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 2017-04-05T18:43:05.830062Z

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

anmonteiro 2017-04-05T18:43:12.832479Z

if you want it globally

2017-04-05T18:43:20.835518Z

Got it, thanks!

sineer 2017-04-05T20:41:27.261693Z

@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 πŸ™‚

thosmos 2017-04-05T21:15:42.925628Z

@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.andrewj 2017-04-05T21:20:19.006657Z

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

anmonteiro 2017-04-05T21:23:50.067257Z

@sineer awesome! thanks

wilkerlucio 2017-04-05T22:59:36.383421Z

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