This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-07-13
Channels
- # admin-announcements (4)
- # beginners (14)
- # boot (41)
- # capetown (1)
- # carry (10)
- # clojure (168)
- # clojure-czech (11)
- # clojure-mexico (3)
- # clojure-quebec (1)
- # clojure-russia (63)
- # clojure-spec (108)
- # clojure-uk (44)
- # clojurescript (37)
- # component (5)
- # data-science (2)
- # datascript (5)
- # datomic (3)
- # defnpodcast (9)
- # dirac (14)
- # emacs (18)
- # events (1)
- # funcool (2)
- # garden (2)
- # hoplon (48)
- # leiningen (6)
- # numerical-computing (1)
- # off-topic (8)
- # om (61)
- # onyx (22)
- # proton (14)
- # re-frame (50)
- # reagent (2)
- # uncomplicate (1)
- # untangled (41)
- # vim (5)
- # yada (5)
Don’t think there’s anything spec specific in re-frame 8
shows how much I know 🙂
In the draft doc it says "not yet", also, I asked in the issue related to v8 about CLJS-1701 and Mike said it is not in yet
By the way it bothers me slightly that the name will change from register-handler
to def-event
. In my head I am not defining an event but indeed an event handler. Am I macaroni ? 😃😃😃
We will run sanity checks on the dispatch and subscription functions in clojure using cljc
@escherize: that’s a good idea - can you share an example of sanity checking dispatch/sub here?
(ns rokt-frame.re-frame-cljc)
(def warn
#?(:clj (fn warn [& xs] (println "[clj] Warning: " xs)))
#?(:cljs re-frame.core/warn))
#?(:clj (def reaction atom))
#?(:clj (defonce app-db (atom {})))
#?(:clj (defonce id->fn (atom {})))
#?(:clj (defonce key->fn (atom {})))
#?(:clj (defn register-handler [kw & mw+fn]
(let [mw (drop-last mw+fn) ;; ignore this.
db-fxn (last mw+fn)]
(when (get @id->fn kw)
(warn "Handler " kw " is being overwritten."))
(swap! id->fn assoc kw db-fxn)
(str "assoc'd " kw " to id->fn"))))
#?(:clj (defn dispatch [[dispatch-kw & args :as dispatch-vector]]
(let [db-fxn (get @id->fn dispatch-kw)
_ (assert db-fxn (str "db-fxn for kw: "
dispatch-kw
" does not exist!!"))]
(swap! app-db #((partial db-fxn %) dispatch-vector)))))
#?(:clj (defn register-sub [kw sub-fn]
(when (get @key->fn kw)
(println "Subscription " kw " is being overwritten."))
(swap! key->fn assoc kw sub-fn)
(str "assoc'd " kw " to key->fn")))
#?(:clj (defn subscribe [[sub-kw]]
(let [sub-fn (get @key->fn sub-kw)]
(sub-fn app-db))))
that's half baked but it can be used like:
(do (dispatch [:initialize-db])
(dispatch [:update-name "George"])
(= @app-db
{:name "George", :order :shuffle}))
mmmh, but dispatch doesn’t modify db immediately
unless it is dispatch-sync
@escherize: @danielcompton I'll take that reference to spec out of the requires
That is necessary but it might not be sufficient to enable our use of re-frame with pre-spec clojure.
@escherize: What else might be a problem?
@richiardiandrea: i know what you mean about def-event
vs register-event
I do feel conflicted. I liked def
because it was short. And because I wanted to make a clear break with previous naming, to avoid any confusion.
The reference to spec is there because register-pure
uses clojure.spec/conform
to parse its arguments. It might not be so easy just to take out of the requires 🙂
Ahh. Now I remember.
We'll redo that so we remove the dependency
Until such time as spec can be DCE it will liekly be a problem for people
To answer @mikethompson's "what else" question to @escherize, the other discussions we'd had internally about ability to use re-frame 8 were more about the update to reagent and react dependencies, which I don't think are actual problems, just things we need to do our due diligence on.
do you guys know if it’s okay to dispatch multiple events in dispatch-sync
? something like
(dispatch-sync [:eventA (:data 123)
:eventB (:data 123)])
@sam.roberton: Right. Reagent shouldn't be a problem. But we found that React 15 was stricter. We got warnings from it when we upgraded.
I haven't had problems with it in my side project, so I don't anticipate any for the day job either. We just need to check 🙂
in [:eventA (:data 123) :eventB (:data 123)]
, :eventB
and (:data 123)
will be assumed to be an arg for :eventA
.
@michael.heuberger: won't work
Do this: (map dispatch (list [:event1] [:event2]))
Also dispatch-sync
should be avoided unless you know what you are doing.
good idea with map … well, using dispatch-sync here only during app start up procedure
Fair enough, the one use case for dispatch-sync
is indeed initiaisation
Oh, yeah. Ture
thanks guys
or just write it twice (probably what i would do unelss there are a variable amount of events)
@mikethompson: what about def-handler
? 😉
The trouble with "handler" is that there are three kinds: - event handlers - subscription handlers - effects handlers (new)
@richiardiandrea: ^^ which is why I went for event
over handler
.
I'm happy with that part.
But it is just what happens in front of that. Should it be:
- def-event
(current proposal)
- register-event
- reg-event
- other?
Remember that this decision then flows into equivalent naming for subs and effects too.
@mikethompson: just to continue to do philosophy, I was picturing the register-subs not as a handler but as creator of a subscription (object, but don't tell anyone), which is then returned.
About effects: def-effect
, because I picture it as executing a side effect.
I picture a def-event
more like a (def user-logged [:user-logged ...])
.
Not trying to convince you, just trying to speak my brains out ☺️