This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-12-12
Channels
- # admin-announcements (1)
- # bangalore-clj (13)
- # beginners (149)
- # boot (123)
- # cider (7)
- # clojure (167)
- # clojure-brasil (3)
- # clojure-greece (1)
- # clojure-korea (2)
- # clojure-new-zealand (2)
- # clojure-russia (70)
- # clojure-sanfrancisco (3)
- # clojure-spec (84)
- # clojure-uk (36)
- # clojurescript (300)
- # code-reviews (242)
- # community-development (34)
- # core-async (4)
- # css (1)
- # cursive (37)
- # datascript (1)
- # datomic (20)
- # defnpodcast (1)
- # dirac (15)
- # events (7)
- # garden (12)
- # hoplon (100)
- # lein-figwheel (11)
- # off-topic (2)
- # om (69)
- # om-next (3)
- # onyx (86)
- # planck (14)
- # proton (4)
- # protorepl (1)
- # quil (2)
- # re-frame (53)
- # rum (3)
- # untangled (1)
- # vim (50)
is there anything in the om next query syntax that doesn't translate to graphql?
im wondering whether to write my own parser, or translate the query into graphql where a number of backend implementations already exist
Anyone else changing the :compassus/route in their merge
function? Or is that a terrible idea?
Attempting to change routes after a successful remote mutation (but not if there was a problem)
@jonsmock I think @danielstockton was doing it at some point
I don't think that it would cause any complications
let me know if it does
I did try it but unsuccessfully
it seemed to have no effect
correction, it's set-route that didn't work
I must be doing something else incorrectly. It triggers a query to my new route's query, which triggers a remote read
merging c.core/route worked I think
Not sure where to hook in to test or where to break that apart (i.e. Stu's scientific method talk)
This is sometimes something I struggle with that I haven't completely figured out, probably something basic I'm forgetting
To recap: parsing happens with target nil and parser returns :remote true, and then I never see the parser called again with the remote target
@jonsmock Om Next won't make any remote calls in merge
1. merge changes compassus route, 2. om notices and triggers query for new root component, 3. parser gets called with query and returns {:remote true}
what you're missing is: the parser either gets called with target
set to nil
or to a remote name
whenever you transact!
, the parser is called twice. Only when target
is non-nil it goes and sees what's in the :remote
key that you return
but in merge
, the parser is only called once, with target
set to nil
this is by design, or you could end up in an endless remote loop
yes and no
#3 happens as part of the reconciliation phase
this occurs because merge
queues something to be reconciliated
so it's effectively after merge
but because merge
wanted it to happen
So #3 will happen with target set to nil, and it won't notice the :remote true if I return it
exactly
the :remote
key is just ignored (because the parser was called with a nil
target)
if you need to perform a new remote read, you can probably use set-route!
that'll call transact!
and go remote
I assume it only happens in the successful case
I assume I don't do that from within the merge, though, or is that what you're suggesting?
I suppose you can do that from within
The other thing I can think of is to have a channel that merge puts something in on success
you probably need to be careful about the heuristic you use to check when that needs to happen
sounds hacky
using the componentDidUpdate
React lifecycle hook to do a transaction would probably be less hacky
keep in mind that you can also transact!
a read
(om/transact! this [:some-key-to-read])
I see - I was just about to ask if my merge assumption was correct (i.e. that merge is the only thing that can notice that a successful response came back)
But I think you're suggesting that the original component's componentDidUpdate watches for the successful response to be merged
you understood correctly 🙂
consider componentWillUpdate
too
and work with the one that feels best
no problem, and likewise!