This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-01-18
Channels
- # bangalore-clj (1)
- # beginners (60)
- # boot (98)
- # cider (8)
- # clojure (158)
- # clojure-dusseldorf (16)
- # clojure-france (3)
- # clojure-hamburg (2)
- # clojure-mke (2)
- # clojure-russia (11)
- # clojure-serbia (1)
- # clojure-spec (123)
- # clojure-uk (59)
- # clojurescript (44)
- # code-reviews (16)
- # community-development (51)
- # core-async (46)
- # cryogen (1)
- # cursive (9)
- # datascript (5)
- # datomic (36)
- # emacs (3)
- # events (12)
- # hoplon (57)
- # jobs (1)
- # juxt (3)
- # klipse (55)
- # lein-figwheel (3)
- # leiningen (5)
- # luminus (3)
- # off-topic (8)
- # om (75)
- # om-next (9)
- # onyx (17)
- # pedestal (7)
- # portland-or (3)
- # proton (36)
- # protorepl (6)
- # re-frame (3)
- # reagent (33)
- # remote-jobs (1)
- # ring (23)
- # ring-swagger (2)
- # rum (1)
- # specter (1)
- # untangled (36)
- # yada (11)
@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 om.next talk to your datomic?
@atdixon yo! superselect is sweet!
Hey all, I'm learning om.next, 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: https://gist.github.com/gws/e4b216446f3f1c49bc7a48ff2b61b8cf - 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 https://github.com/omcljs/om/wiki/Thinking-With-Links!
@mavbozo Thanks, I may be contorting my app model to fit something I was reading. I was looking at this: https://awkay.github.io/om-tutorial/#!/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: https://gist.github.com/gws/e4b216446f3f1c49bc7a48ff2b61b8cf - 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 https://github.com/omcljs/om/issues/813 - what am I missing?