Fork me on GitHub

@nha my next steps are using sockets, not really puritan-om-nextiness, but if you keep a list/array/set of websockets that are subscribed to particular queries and let them socket-emit you a signal that says "hey subscribe me to updates on this" or "hey unsub this ws from this update" and just remove it from your websockets-to-send-updates-to-for-this-particular-info-item list... then in theory you have sub/unsub. How does your talk to your datomic?


@atdixon yo! superselect is sweet!


Hey all, I'm learning, and I'm trying to write a parser for a query that uses ui-only keys at the root in order to join in two subcomponents. I want to be able to treat the keys in the subcomponent queries as though they were top-level in the parser, because they will be at the top level of my app state. I'm experimenting with invoking the parser recursively to accomplish this, and I can get values back from the reads, but remotes are not invoked. Can anyone point me in the right direction?


Here is a reduced version of what I'm working on now: - please ignore any errors that seem to be unrelated to the conceptual problems I'm having - I made some changes pulling this gist out from the app I'm working on, I just need help understanding how to correctly write a parser for the thing I'm trying to do.


@sova I don't have subscriptions yet, and I don't talk to datomic but rethinkdb (love the idea, api etc from what I see but I can't resolve myself to give all my data to a proprietary database that has no equivalent/replacement/specification)


@gws so the Tabs component needs pieces of global data :data/from-remote-*. looks similar to problem described here!


@mavbozo Thanks, I may be contorting my app model to fit something I was reading. I was looking at this:!/om_tutorial.G_Remote_Fetch, and specifically the machinery in that first snippet of code: :widget (p/recurse-remote env key true) in which :widget is only a UI-concern. Below that snippet, the explanation seemed to fit the use case I had: > The recurse-remote function basically means "I have to include this node, because it is on the path to real remote data, but itself needs nothing from the server".


I made some changes to use links instead: - I still have an issue where the reads that I'm expecting to be issued to the root of the application state (as a result of (om/db->tree ...)) aren't being issued.


It seems to be the same problem @arohner is having in - what am I missing?