Are there plans for re-frame 8 to be compatible with pre-spec versions of clojure?

Don’t think there’s anything spec specific in re-frame 8

There is spec specific code in re-frame 8, though.

line 3 of re-frame.subs has it

https://github.com/Day8/re-frame/blob/master/src/re_frame/subs.cljs#L3

ah

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?

I've been working on it but havn't rolled middleware into the equation yet.

(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

true, it's not a perfect representation

of what happens in re-frame

but it's enough to test sequential app-db interactions (without javascript)

@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 dont think that will work, michael.heuberger.

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

doseq would be better, as map is lazy

Oh, yeah. Ture

doseq?

(doseq [event [[:eventA 123] [:eventB 234]]] 
  (dispatch-sync event))

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.

guys stop bikeshedding. 😛

@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 ☺️