Fork me on GitHub
#om
<
2017-02-15
>
sova-soars-the-sora00:02:03

@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)

devth00:02:52

right - i don't expect figwheel to reload clj. i do that on my own.

devth00:02:04

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

sova-soars-the-sora00:02:55

Ah yes, same behavior here. wonder if there is a workaround 🔮

devth00:02:18

could probably figure out a way to manually trigger a remote read via the repl

hlolli13:02:42

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.

danielstockton13:02:58

You probably need to transact! if it's not the initial read.

hlolli13:02:12

@danielstockton ok I will try transact!, sounds weird to mutate when one wants to fetch data.

hlolli13:02:26

but probably the only thing that could work

danielstockton13:02:59

You don't mutate anything, just a 'read transact' to trigger the read.

hlolli13:02:59

ok, the read is being triggered. And it returns {:remote true}, but the reconciler is compltetly silent, no :send.

danielstockton13:02:28

I remember trying myself and didn't have much luck.

danielstockton13:02:20

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?

hlolli13:02:34

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.

hlolli13:02:07

yes, I would have thought it shouldn't matter

cmcfarlen13:02:57

@hlolli Try adding the keys you want to re-read after the transact: (om/transact this '[(some/mutate) :important-key])

hlolli13:02:25

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?

cmcfarlen13:02:49

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)

cmcfarlen13:02:13

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

cmcfarlen13:02:08

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 ...}

hlolli13:02:56

ok, the default reconciler config has :remote [:remote], except I excplicitly specify :remote nil, then returning :remote true from parse-read should work?

danielstockton13:02:14

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.

hlolli13:02:32

ok, I have few ideas to try out, thanks.

danielstockton13:02:12

(defmethod read :some/key
  [{:keys [target]} _ _]
  (println target))
You can test it with this, you will probably see nil and :remote being logged.

hlolli13:02:13

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)
     }))

hlolli13:02:48

but this causes infinite loop. :target doesnt change from being nil.

cmcfarlen13:02:12

@hlolli It seems like your (if target ...) form is not the last one in the when-not.

cmcfarlen13:02:10

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))}

hlolli14:02:28

yes nice, that sounds clean.

hlolli14:02:01

Im assumeing the value for :remote will be passed as parameter?

cmcfarlen14:02:13

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.

hlolli14:02:04

Im already mutating the search queries so this should be quick to try. But still few hours as Im stuck in a complex mess I made for myself.

cmcfarlen14:02:39

Oh I've been there! Good luck! 🙂