This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-07-08
Channels
- # admin-announcements (1)
- # arachne (3)
- # beginners (17)
- # boot (36)
- # bristol-clojurians (1)
- # cider (4)
- # clara (10)
- # cljsjs (11)
- # cljsrn (20)
- # clojure (134)
- # clojure-austin (2)
- # clojure-boston (1)
- # clojure-czech (1)
- # clojure-greece (128)
- # clojure-norway (1)
- # clojure-romania (1)
- # clojure-russia (17)
- # clojure-spec (106)
- # clojure-sweden (1)
- # clojure-taiwan (1)
- # clojure-uk (41)
- # clojurescript (122)
- # component (4)
- # cursive (1)
- # datomic (34)
- # editors (57)
- # emacs (12)
- # events (5)
- # hoplon (18)
- # instaparse (1)
- # jobs (9)
- # keechma (9)
- # lein-figwheel (3)
- # luminus (1)
- # om (47)
- # onyx (31)
- # proton (2)
- # re-frame (7)
- # reagent (3)
- # rethinkdb (1)
- # specter (25)
- # sql (2)
- # untangled (21)
- # yada (1)
@jasonjckn: I've recently be working on client side routing and history. What I settled on was using bidi/pushy for routing/history management and using compassus for om routing. What I ended up doing was using om/transact! to do normal state management, but when time to navigate internal to the app I just used pushy to update the location and then loaded the app state from the url in the bidi callback. This works with the back button nicely and since my app is initialized from the url then deep linking is also supported (kinda) for free.
@jasonjckn: this works for one site I made.
(defn make-history []
(doto (Html5History.)
(.setPathPrefix (str js/window.location.protocol
"//"
js/window.location.host))
(.setUseFragment false)))
and
(defonce history
(doto (make-history)
(events/listen goog.History.EventType.NAVIGATE
#(page-loader (get-subpage (.-token %))))
(.setEnabled true)))
where page-loader is a function that mutates the app-state trough the reconciler. And get-subpage is a map that matches the uri parameter. (ps long time I implemented this, so not sure if this works like I think it does).
Also this hack works because I change the uri according to page changes with:
(doto history
(.setUseFragment false)
(.setPathPrefix "")
(.setToken (name active-window)))
Here I don't used #uri so I need to tell Compojure about the website. Well, this is a ugly hack when I think about it.re: your issue yesterday
@anmonteiro: awesome! I wonder if this will cause some existing code to select different paths for existing unions if the unions are already just more specific sets.
@cmcfarlen: it will always select the most specific query
notice that I only call reduced
in the strict case
so even if there’s a case that fits the relaxed one, it’ll run until it finds one that’s exactly equal
@cmcfarlen: I even wrote a test for that
@anmonteiro: ah, yes. I see now. Very nice!
@anmonteiro: I actually ran into another issue last night. I hope it will be the last as I have almost converted my entire app now. ha
I had to add this in compassus-merge for merges after a remote mutate.
- (om/default-merge reconciler state
- (cond-> res
- (not mutation?) (get route)) query')))
+ (assoc (om/default-merge reconciler state
+ (cond-> res
+ (not mutation?) (get route)) query')
+ ::route route)))
Its the :next
key that needs to have ::route assoc'd back in. I'm not saying that is a fix, just what I did initially.
But ::route is being dropped after a merge! from a remote mutate coming back with :tempids and ref-based novelty. I also have to lookup the query for the current route and pass that along in the callback or the state is replaced with the response
- (om/default-merge reconciler state
- (cond-> res
- (not mutation?) (get route)) query')))
+ (update (om/default-merge reconciler state
+ (cond-> res
+ (not mutation?) (get route)) query')
+ :next assoc ::route route)))
@cmcfarlen: hrm, I’ll look into that, thx for reporting
@anmonteiro: Great! Thanks again. I can get more details together if you want
I'm still struggling with remote mutation. I'm using mutation to send email trough a server and I want the mutation to receive response if the email delivery went successful. I always end up with {send-email! {:result {:success? true}}}
the name of the mutation is 'send-email!
, how can I merge it into the app-state correctly. I can't access the response data in :action nor :remote?
@hlolli: override :merge
in the reconciler
e.g.:
(defn my-merge
[reconciler state res query]
(om/default-merge reconciler state
(if (symbol? (ffirst res))
(-> res first second :result)
res)
query))
BINGO, I think I've read almost all documentation on om.next. But I see that there are some holes, so without slack I would be lost 🙂
@hlolli: When you get to resolving tempids to stable ids from the server, the shape om expects is like: {'item/create {:tempids {[:item/by-id <#C06DT2YSY>/id[]] [:item/by-id 12312234]}}}
So in that case you might have to move your novelty out to be beside the symbol in the map instead of replace it
I ended up writing a fn to look for a :novelty
key inside the returns from remote mutates and merge those in at the top.
ok, must admit I've never dived to tempids, but I'm still studying the talks code from anmonteiro. I know I will need to use them soon.
It did take a while to figure out how that worked reading the om.next code so thought I'd mention it 🙂
A win win would be if you wrote a blog post about how you use it. Just throwing ideas out, no pressure 🙂
@anmonteiro: after further digging it looks like default migrate is what is dropping the route, only if tempids are present. It does a db->tree->db cycle with the given query to add the tempids.
So either the result has to have the shape of the root query, or something has to preserve those keys
@cmcfarlen: yeah, I was aware of that normalization cycle
just seems like I forgot to add the :compassus.core/route
key after that
¯\(ツ)/¯
(defn my-migrate
([app-state-pure query tempids]
(my-migrate app-state-pure query tempids nil))
([app-state-pure query tempids id-key]
(let [route (::compassus/route app-state-pure)
res (om/default-migrate app-state-pure query tempids id-key)]
(assoc res ::compassus/route route))))
It might be nice if compassus looked up the query for the current route and passed that along for merges with mutations. I might not be handling that properly though, so it might only seem nice 🙂
@cmcfarlen: this is definitely something that needs to be fixed in Compassus
I’ll try and look at it tonight