Fork me on GitHub
#om
<
2016-12-06
>
anmonteiro02:12:00

@haywood yes. your input data is not normalized

haywood02:12:14

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

haywood02:12:40

I'm messing around trying to build a js wrapper around the parser's functionality

danielstockton11:12:03

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.

danielstockton12:12:22

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?

danielstockton12:12:14

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?

calvis21:12:44

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

mitchelkuijpers21:12:47

@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

therabidbanana21:12:10

I’m not sure Untangled has the transaction history though - I’ve been wondering if we could add it to our vcr support requests.

calvis21:12:17

not really interested in changing to use Untangled to implement a single thing

calvis21:12:54

I found https://github.com/omcljs/om/issues/384 after I dropped that message here

calvis21:12:12

(which has a suggestion)

mitchelkuijpers21:12:28

@calvis Aha well did not know if you were aware of untangled. Untangled seems to be recording their own history

therabidbanana21:12:18

Oh nice find @calvis - this could be pretty useful for our own support tool.

mitchelkuijpers21:12:21

But that Intercept solution also seems very elegant 🙂

calvis21:12:38

yeah, I don’t think it would get the UUID though

calvis21:12:42

haven’t tried it yet

dnolen21:12:40

@calvis :history should be the mutable cache, it’s configurable, all you need is add and get Object methods

dnolen21:12:12

you could easily wire up a debug cache that isn’t something that drops

dnolen21:12:33

then you can just deref that thing

calvis21:12:43

is there a config option for that or would I manually have to swap that out

dnolen21:12:07

yes :history

dnolen21:12:47

(deftype MyHistory [a-map] Object (add […]) …)

dnolen21:12:07

then :history (MyHistory. …)

calvis21:12:37

it looks like the :history keyword is a number when the reconciler is built

dnolen21:12:43

hrm, I guess you’re right - it’s an old feature so I don’t think I considered just exposing that

dnolen21:12:54

but simple enhance and open to it

dnolen21:12:03

now would be a good time to ask for the interface too

dnolen21:12:08

Object stuff is kind ugly

dnolen21:12:27

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

dnolen21:12:05

I tried to avoid breakage here which makes it a little clunky - but it should allow you to get precise renders from remote responses

dnolen21:12:22

the autocompleter devcards is updated to demonstrate it

dnolen21:12:33

(note writing things the old way will still completely work)

dnolen21:12:08

the only difference here is that the send cb can now take 3 args, where the last one is the remote you handled

dnolen21:12:43

we also drop the component that triggered the remote query into the proper remote queue

dnolen21:12:17

so even if that component just invokes a single remote mutation (no reads) we’ll put the component in the remote render queue

dnolen21:12:35

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

anmonteiro21:12:19

Cool stuff. I guess it took seeing the implementation to actually understand the problem :-)

anmonteiro21:12:43

I can now relate, I've had this problem before

anmonteiro21:12:25

@dnolen: when are these remote queues consumed though? In reconcile!?

dnolen21:12:03

yes I made a breaking change to reconcile! that should only potentially affect Clojure consumers

anmonteiro21:12:03

Oh nevermind, I see it's when the callback is invoked

dnolen21:12:19

so reconcile! and queue! protocols now take 2nd argument

dnolen21:12:29

for ClojureScript no big deal because … JavaScript

dnolen21:12:48

Clojure won’t be so happy though, you need implement both arities if you’re doing a custom reconciler

anmonteiro21:12:47

Not sure that's an actual problem, at least I don't know anyone who's implementing own reconciler

dnolen21:12:59

yeah, I figured as much so I wasn’t concerned about it (custom reconciler in Clojure)