This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-12-06
Channels
- # adventofcode (24)
- # aleph (1)
- # bangalore-clj (2)
- # beginners (196)
- # boot (148)
- # cider (18)
- # clara (83)
- # cljsrn (24)
- # clojure (210)
- # clojure-brasil (3)
- # clojure-china (1)
- # clojure-italy (11)
- # clojure-korea (8)
- # clojure-russia (82)
- # clojure-spec (115)
- # clojure-uk (130)
- # clojurescript (109)
- # core-async (7)
- # cryogen (1)
- # cursive (22)
- # datascript (11)
- # datomic (6)
- # devcards (2)
- # emacs (1)
- # garden (1)
- # hoplon (2)
- # incanter (1)
- # klipse (4)
- # luminus (4)
- # off-topic (89)
- # om (53)
- # onyx (78)
- # parinfer (9)
- # proton (3)
- # protorepl (20)
- # re-frame (107)
- # reagent (52)
- # rum (30)
- # spacemacs (1)
- # testing (3)
- # untangled (31)
- # vim (43)
- # yada (9)
@haywood yes. your input data is not normalized
ah, it works when replaced with get-in style vecs. for some reason I thought I remembered using that function to query arbitrary maps with om's query syntax
I'm trying to debug a duplicate remote send, is there an explanation somewhere of what's going on behind the scenes for reads and sends? Trying to get my head around why reads are called multiple times, when this triggers a remote read (depends on (:target ast)?), and how exactly I can debug it.
Is it related to transform-reads
? Are the implications of this that if I trigger a read, it will find the component queries of all components interested in that read and re-read the whole query?
For example, if i have the query [:current-user :totals]
, if I merge a new :current-user
into state, will it trigger a re-read of :totals
too?
I’m using om.next for an internal tool and I’m in the process of adding a “File a Bug Report” feature that dumps the reconciler for debugging. I can see I can get at the reconciler history itself (albeit in an undocumented way) via (-> reconciler :config :history)
but the history of the transactions themselves (i.e. the UUID->transaction info that gets logged) doesn’t seem to be stored anywhere in the reconciler. is there any way to get at those transactions in a not-hacky way? would also be open to suggestions of better ways to debug om.next apps
@calvis have you considered Untangled? Which has exactly this feature built in and is a small layer on top of om.next. You could even only use the untangled-client (which is how we started using it). This is a demo of the vcr support of untangled https://youtu.be/CoMyszwN50g?t=168
I’m not sure Untangled has the transaction history though - I’ve been wondering if we could add it to our vcr support requests.
I found https://github.com/omcljs/om/issues/384 after I dropped that message here
@calvis Aha well did not know if you were aware of untangled. Untangled seems to be recording their own history
Oh nice find @calvis - this could be pretty useful for our own support tool.
https://github.com/untangled-web/untangled-client/blob/master/src/untangled/client/core.cljs#L194 this seems to be the code where they get the history
But that Intercept solution also seems very elegant 🙂
@calvis :history
should be the mutable cache, it’s configurable, all you need is add
and get
Object methods
hrm, I guess you’re right - it’s an old feature so I don’t think I considered just exposing that
unrelated, I just landed a remote reconciliation queue - if you’re aware of that problem feel free to ask questions about that and test that
I tried to avoid breakage here which makes it a little clunky - but it should allow you to get precise renders from remote responses
https://github.com/omcljs/om/blob/master/src/devcards/om/devcards/autocomplete.cljs (for the curious)
the only difference here is that the send
cb can now take 3 args, where the last one is the remote you handled
we also drop the component that triggered the remote query into the proper remote queue
so even if that component just invokes a single remote mutation (no reads) we’ll put the component in the remote render queue
in the old world, the component would go into the queue, 16 ms delay to re-render, server responds slower than that, render queue is empty, throw our hands up and re-render from root
Cool stuff. I guess it took seeing the implementation to actually understand the problem :-)
I can now relate, I've had this problem before
@dnolen: when are these remote queues consumed though? In reconcile!
?
yes I made a breaking change to reconcile! that should only potentially affect Clojure consumers
Oh nevermind, I see it's when the callback is invoked
Clojure won’t be so happy though, you need implement both arities if you’re doing a custom reconciler
Not sure that's an actual problem, at least I don't know anyone who's implementing own reconciler