Clojurians Log v2

Nice, thanks, just didn’t find a way to do the shadow-cljs compiler options for the tracing in figwheel so I will stick with shadow. @p-himik @superstructor Reframe depends on reagent right? Or could I replace reagent with something like dumdom while still using all reframe features? I would like to remove react as a dependency.

Re-frame directly depends on Reagent and is impossible to use without it. Some details here: https://github.com/day8/re-frame/issues/590

Interresting discussion. After years of working with hooks I fully agree with you. Thats also why I wanted to go for dumdom. I hope the react team won’t at one point only support hooks.

What version if react do you then recommend to set in a reframe project?

When using Reagent, you don't have to worry about hooks at all, unless some NPM library uses them - you can just not use them yourself. A particular re-frame version depends on a specific Reagent version which, in turn, depends on a specific React version. Just choose those versions accordingly.

Ah I read that reagent is switching to hooks as well

A recent version has made it possible to use them for the user of Reagent. But no, Reagent doesn't switch to hooks.

so the new :f> and :r> shouldn’t be used when using reframe?

I was wondering why the :dispatch-later map doesn’t support :dispatch-n . My use case is that I need two events happening after certain ms. I have many ways to achieve the same behaviour but thought that a dispatch-n within dispatch-later was the cleanest way.

:dispatch-later and :dispatch-n are effects that accept events. That's why. With that being said, :dispatch-later accepts not only a map, but also a vector of maps - that's how you dispatch multiple events later.

They can be used. Whether they should be or not - depends on what your use-case it. Re-frame doesn't care about them at all. Whatever works in Reagent, will work in re-frame.

Ah right it makes sense 🙂. Will use a vec of maps thanks!

In the https://day8.github.io/re-frame/Effects/#order-of-effects, there's a portion that references best practices changing and the new approach (i.e., :db and :fx) are "more about making it easier to compose event handlers." I totally agree & think this new best practice is great. I'm curious, however, is the composition of event handlers documented somewhere? I'd like to be able to link to this doc from our internal best practices doc.

There's not much to it. You have two handler functions, that both return {:db ..., :fx ...}, where both keys are optional. And then you just do something like:

(defn combine-fx-handlers [fns]
  (fn [{db :db :as ctx} event-v]
    (reduce (fn [acc f]
              (let [fxs (f (assoc ctx :db (:db acc)) event-v)]
                (cond-> acc
                  (contains? fxs :db) (assoc :db (:db fxs))
                  (contains? fxs :fx) (update :fx into (:fx fxs)))))
            {:db db, :fx []} fns)))

Right. I was hoping for a link to documentation to reference though.

As you said - it's not there. :) At least, I also don't know of it. If you want to see it there, a GitHub issue should be created first.