This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-02-15
Channels
- # aws (1)
- # beginners (6)
- # boot (25)
- # cider (30)
- # cljs-dev (50)
- # cljsrn (45)
- # clojure (98)
- # clojure-austin (5)
- # clojure-czech (1)
- # clojure-dev (21)
- # clojure-dusseldorf (29)
- # clojure-germany (2)
- # clojure-greece (117)
- # clojure-italy (2)
- # clojure-nl (4)
- # clojure-russia (26)
- # clojure-serbia (10)
- # clojure-spec (123)
- # clojure-turkiye (1)
- # clojure-uk (27)
- # clojured (13)
- # clojurescript (57)
- # core-async (18)
- # cursive (13)
- # datomic (20)
- # defnpodcast (16)
- # emacs (8)
- # events (2)
- # figwheel (3)
- # instaparse (1)
- # jobs (3)
- # jobs-discuss (39)
- # klipse (9)
- # lumo (100)
- # mount (1)
- # numerical-computing (1)
- # off-topic (22)
- # om (34)
- # onyx (17)
- # pedestal (1)
- # perun (29)
- # re-frame (60)
- # reagent (16)
- # remote-jobs (8)
- # rethinkdb (6)
- # ring-swagger (19)
- # rum (1)
- # slack-help (1)
- # specter (3)
- # untangled (1)
- # yada (17)
@devth that's the behavior i expect, although I cannot claim it is intentional or not. I think figwheel is made to only reload the "relevant js" and therefore may not do anything with your remotes. I use figwheel in combination with my backend up-and-running so that I get the reality of my backend and the benefits of js-reloading while (= true :dev-mode)
just saying it doesn't trigger a remote read so it's not getting state it needs *unless i do a hard refresh in my browser
Ah yes, same behavior here. wonder if there is a workaround 🔮
what is the common trick to force send! when a nested component needs remote data. Im returning {:remote true}, which usually calls the send function but its not when its nested.
You probably need to transact! if it's not the initial read.
@danielstockton ok I will try transact!, sounds weird to mutate when one wants to fetch data.
You don't mutate anything, just a 'read transact' to trigger the read.
ok, the read is being triggered. And it returns {:remote true}, but the reconciler is compltetly silent, no :send.
You might try using force
: https://github.com/omcljs/om/wiki/Documentation-(om.next)#force
I remember trying myself and didn't have much luck.
Your question sounds slightly confused though. It shouldn't really matter whether a component is nested or not. The problem you're having seems to be 'how to force a remote read' after the app has initially mounted?
ok, I see where that leads me. My other option is to update-query! of the root from a child. I think it wont talk to the reconciler because im requestin for a read from a nested compoennt.
@hlolli Try adding the keys you want to re-read after the transact: (om/transact this '[(some/mutate) :important-key])
ok, maybe Im misunderstanding the parser. If the parser is called, then the reconciler is reading. Or can the parser be triggered without re-read?
The reconciler might not call your parser with remote set. If remote is nil, then it doesn't matter what you return. The reconciler calls with remote nil for local reads and remote :remote for remote (actually, once for each remote you have configured)
After the app loads up, parser calls will not have remote set unless something happens to trigger that. One way is to add keys to a transact! call
I should say, it doesn't matter if you return {:remote true} when remote is nil. It of course matters if you return a {:value ...}
ok, the default reconciler config has :remote [:remote], except I excplicitly specify :remote nil, then returning :remote true from parse-read should work?
Indeed @hlolli, you will notice that the parser is called multiple times for each remote. This is why you should not have side-effects in the parser function and for mutates, the action has to be inside a thunk.
(defmethod read :some/key
[{:keys [target]} _ _]
(println target))
You can test it with this, you will probably see nil
and :remote
being logged.one can see my attempt here
(defmethod read :search/search
[{:keys [state ast target] :as env} k params]
(when-not (empty? params)
(js/console.log (str "search params: " (:target env)))
;; ((transit-post "/api"))
(prn target)
(if target
{:remote true}
;; {:remote true}
(ess-parser (assoc env :target [:remote])
`[(:search/search ~params)]))
{;;:remote true
;; :value {:a 1}
:value (get @state k)
}))
@hlolli It seems like your (if target ...)
form is not the last one in the when-not.
As a suggestion, perhaps try to keep your search parameters as a separate entity in your state. Then you can change those params with a transact
(om/transact! this `[(search/update-params ~new-params) :search/search])
Your :search/search read method would first read the params from the state and then check for remote. Your return for that would look like {:remote (assoc ast :params (get @state :search-params))}
right, when target is :remote its time to return the {:remote ...} bit. Adding :search/search to the transact! call should trigger the parser to be called with target set to :remote.