This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-08-23
Channels
- # announcements (6)
- # beginners (54)
- # calva (9)
- # cider (2)
- # clj-kondo (26)
- # cljsrn (2)
- # clojure (49)
- # clojure-brasil (1)
- # clojure-dev (3)
- # clojure-europe (11)
- # clojure-italy (28)
- # clojure-nl (5)
- # clojure-serbia (1)
- # clojure-spec (4)
- # clojure-uk (182)
- # clojuredesign-podcast (2)
- # clojurescript (59)
- # clojurex (9)
- # cursive (26)
- # data-science (11)
- # datomic (40)
- # duct (1)
- # emacs (3)
- # events (4)
- # figwheel-main (2)
- # fulcro (7)
- # instaparse (1)
- # kaocha (2)
- # leiningen (25)
- # off-topic (3)
- # re-frame (36)
- # reagent (15)
- # shadow-cljs (87)
- # spacemacs (12)
- # sql (20)
- # tools-deps (8)
- # vim (1)
- # yada (40)
@mynomoto yeah, basically
(reg-fx
:navigate
(fn [[navigator-obj route params]]
(when (nil? navigator-obj)
(throw (ex-info "nil navigator passed to :navigate effect" {:route route :params params})))
(ocall navigator-obj :dispatch (navactions/navigate-to route params))
)
)
(defonce navigation-actions-map {:init (gobj/get navigation-actions #js ["init"])
:uri (gobj/get navigation-actions #js ["uri"])
:navigate (gobj/get navigation-actions #js ["navigate"])
:back (gobj/get navigation-actions #js ["back"])
:reset (gobj/get navigation-actions #js ["reset"])
:set-params (gobj/get navigation-actions #js ["setParams"])})
(defn navigate-to [route args]
(println "[navactions] navigation action:" ((:navigate navigation-actions-map) (clj->js {:routeName route :params args})))
((:navigate navigation-actions-map) (clj->js {:routeName route :params args}))
)
I actually had another loosely related question. Is there any idiomatic way to pass app-db to custom effects?
@xfyre Thanks, I will check both out. What do you mean by pass app-db to custom effects? You mean something defined by reg-fx
?
yep, exactly - if I register some effect using reg-fx
and this effect also needs data from app-db - what would be the most correct way to do it?
I’ve used re-frame for defining navigation as an effect (snippet above) and this is extremely convenient
When I need that I create an extra reg-event-fx and separate the db part and let the reg-fx be specific and db independent, but not sure if this is what is recommended.
so there’s really no good way of accessing db in a subscription with a signal? e.g:
(reg-sub :foo ,,,)
(reg-sub
:bar
<- [:foo]
(fn [foo]
;; how do I access db here?
))
i think you can make a sub that returns the db and add that as another signal. problem w/ that is you will end up recalculating on every db change.
you mean like this:
(reg-sub
::bar
(fn [db]
{:foo (subscribe [::foo])
:db db})
(fn [{:keys [foo db]}]
;; now have acces to db
))
i tried something like this a while ago. think i ended up unsafely directly accessing the db since it wasn’t important to have a super up to date db.
You can access it without using the sugar syntax and by subscribing your foo together with the db
Straight from the docs:
(reg-sub
:visible-todos
;; signal function - returns a vector of two input signals
(fn [query-v _]
[(subscribe [:todos])
(subscribe [:showing])])
;; the computation function - 1st arg is a 2-vector of values
(fn [[todos showing] _]
(let [filter-fn (case showing
:active (complement :done)
:done :done
:all identity)]
(filter filter-fn todos))))
(reg-sub
:db
(fn [db _]
db))
And then
(reg-sub
:bar
<- [:db]
<- [:foo]
(fn [[db foo] _]
;; access db here
))
yeah i tried that once and it didn’t really work for my use-case since the sub gets re-calculated on any change.
But this is not a great idea because this subscription will fire every single time anything in app-db
changes