4 ms·

Re-frame is a layer on top of reagent, which is an API for using React in cljs. If you want to use react, you can also just directly use reagent which is the pr

Re-frame is a layer on top of reagent, which is an API for using React in cljs. If you want to use react, you can also just directly use reagent which is the preference of many in the community. The boilerplate and verbosity required for reframe could be overkill for many small projects, especially for solo developers, where pure reagent often thrives. However reframe’s restrictions can be helpful in team environments. The library github page is an entertaining display of equal parts vanity and hyperbole: https://github.com/day8/re-frame/ https://github.com/day8/re-frame/

synthc 6y ago
Re-frame really doesn't add much in addition to Reagent, I really don't understand its popularity.
- MikeOfAu 6y ago
  This comes up often enough that there is an FAQ entry: https://day8.github.io/re-frame/FAQs/DoINeedReFrame/ https://day8.github.io/re-frame/FAQs/DoINeedReFrame/
- hellofunk 6y ago
  I personally prefer reagent directly over re-frame. I've heard some Clojure developers express frustrations with the typical idioms that Re-frame promotes. I can see some value in how it organizes some things, but you can do the same thing directly with Reagent far more quickly. The difference is that in Re-frame you only really have one way of doing things, and that consistency can be good for a team. But it does require extra development time.
- yomly 6y ago
  I think the parent is correct to point out two things. That re-frame is useful in bigger teams and it is useful for larger apps. Re-frame is somewhat more complex than inline and vanilla reagent. I suppose with hooks a lot of the simpler use cases for state management also go away. That said, as a discipline the indirection re-frame encourages you to use helps you architect a purely functional* application. My observation is a lot of larger user facing applications will tend towards something that is event-driven and possibly loosely a state machine. Which incidentally also is one of the implementations of "functional core imperative shell" Ultimately YMMV. If you just want a static site with a tiny bit of sparkle then you probably don't need reframe. (possibly you don't need cljs/reagent) If you're tending towards a large full blown SPA with lots of interactivity and IO plus failure states, then reframe probably isn't a bad solution IMO. * subscribe and dispatch are strictly not pure and actually use global state so purely functional isn't actually accurate. But it is a reasonable stab at being purely functional, while strongly quarantining the side-effecting bits.
- pinchhit 6y ago
  I've run a team with re-frame and a team with reagent (and a convention of a single state atom.) Reagent by itself scaled far better. I use re-frame if it's a company convention, but I'd far rather just ditch it. Plain reagent has no unnecessary function registry; mutations are done with `(swap! my-cursor foo/update-foo bar)` rather than the extra overhead of `(dispatch [::foo/update-foo bar])`. This also helps new people who rely on cursive to jump to definitions, and don't have a preferred emacs setup. Reagent testing can be scoped to a single DB. In re-frame, you can clear the subscription queue (which will not handle callbacks from network calls putting events on to the queue when the callback fires, leading to flaky tests that receive unexpected events.) In reagent, you have more power, since you can call `(reagent/atom {})` with your test state and any callbacks specfic to the test will see their DB, regardless of when they resolve. Re-frame's single events/subscriptions files scaled horribly; once we got beyond a few hundred business-logic-filled events, velocity on changes involving that file slowed down a lot. We broke convention and moved events into namespaces closer to the code.
  - pinchhit 6y ago
    Three things that would make re-frame better, if you want them: - A supported/blessed way to switch out the entire app-db entirely for the purposes of testing - Use of symbols rather than namespaced keywords for function dispatch - Docs that give alternate strategies for code organization (fine to have the events.cljs convention, but would be nice to see some viewpoints like having one per child ns similar to angular's code organization model.)
    - MikeOfAu 6y ago
      Answers to your three points: - I'm wondering if re-frame-test might help? - That ship has sailed a long time ago. And, even if it hadn't, I diagree that symbols would be better. - I'm unfamiliar with angular's code. The Resources section lists larger apps which you can inspect.
      - pinchhit 6y ago
        I'll try re-frame-test, thanks! If it doesn't do something like `(with-redefs [re-frame.db/app-db (reagent/atom {})] ...)` it is still open to this bug, though. Because the call to `dispatch` happens inside of a callback the test library has no way to signal that future dispatches coming from a different function context should not be put on the same queue. It'd be hard to change that aspect of the API now, and I wouldn't recommend you do it; but right now, editor completion and new-user understanding is just better on the reagent side. They do this: (defn assoc-foo [db bar] (assoc db :foo bar)) (defn fetch-new-foo [db bar] (go (let [bar (<! (get-bar)] (swap! db assoc-foo bar)))) (swap! db assoc-foo bar) (fetch-new-foo db bar) whereas re-frame would make you do this: (re-frame/reg-event-db ::assoc-foo (fn [db [_ bar]] (assoc db :foo bar))) (re-frame/reg-fx ::pull-from-channel (fn [{:keys [f event]}] (go (let [resp (<! (f))] (re-frame/dispatch (conj event resp)))))) (re-frame/reg-event-fx ::fetch-new-foo (fn [_ _] {:pull-from-channel {:f get-bar :event [::assoc-foo]}})) (dispatch [::assoc-foo bar]) (dispatch [::fetch-new-foo]) The first one has a lot going for it; swap! is part of the standard library, has a bunch of docs for free, etc.; any clojure editor will pick up on the use of assoc-foo as a function and give you arity warnings if you pass too many parameters, etc. I've looked at the larger apps - the way I've seen people be most successful if if they have a child namespace with events, subs, & views laid out on a per namespace basis (`my-ns.events, my-ns.subs, my-other-ns.events, my-other-ns.subs`.) Partially due to the tone the docs take, there's always some pushback as to whether that's the re-frame way to do things, and I'd love to just be able to avoid that whole conversation in the future.

synthc 6y ago

Re-frame really doesn't add much in addition to Reagent, I really don't understand its popularity.

MikeOfAu 6y ago
This comes up often enough that there is an FAQ entry: https://day8.github.io/re-frame/FAQs/DoINeedReFrame/ https://day8.github.io/re-frame/FAQs/DoINeedReFrame/
hellofunk 6y ago
I personally prefer reagent directly over re-frame. I've heard some Clojure developers express frustrations with the typical idioms that Re-frame promotes. I can see some value in how it organizes some things, but you can do the same thing directly with Reagent far more quickly. The difference is that in Re-frame you only really have one way of doing things, and that consistency can be good for a team. But it does require extra development time.
yomly 6y ago
I think the parent is correct to point out two things. That re-frame is useful in bigger teams and it is useful for larger apps. Re-frame is somewhat more complex than inline and vanilla reagent. I suppose with hooks a lot of the simpler use cases for state management also go away. That said, as a discipline the indirection re-frame encourages you to use helps you architect a purely functional* application. My observation is a lot of larger user facing applications will tend towards something that is event-driven and possibly loosely a state machine. Which incidentally also is one of the implementations of "functional core imperative shell" Ultimately YMMV. If you just want a static site with a tiny bit of sparkle then you probably don't need reframe. (possibly you don't need cljs/reagent) If you're tending towards a large full blown SPA with lots of interactivity and IO plus failure states, then reframe probably isn't a bad solution IMO. * subscribe and dispatch are strictly not pure and actually use global state so purely functional isn't actually accurate. But it is a reasonable stab at being purely functional, while strongly quarantining the side-effecting bits.
pinchhit 6y ago
I've run a team with re-frame and a team with reagent (and a convention of a single state atom.) Reagent by itself scaled far better. I use re-frame if it's a company convention, but I'd far rather just ditch it. Plain reagent has no unnecessary function registry; mutations are done with `(swap! my-cursor foo/update-foo bar)` rather than the extra overhead of `(dispatch [::foo/update-foo bar])`. This also helps new people who rely on cursive to jump to definitions, and don't have a preferred emacs setup. Reagent testing can be scoped to a single DB. In re-frame, you can clear the subscription queue (which will not handle callbacks from network calls putting events on to the queue when the callback fires, leading to flaky tests that receive unexpected events.) In reagent, you have more power, since you can call `(reagent/atom {})` with your test state and any callbacks specfic to the test will see their DB, regardless of when they resolve. Re-frame's single events/subscriptions files scaled horribly; once we got beyond a few hundred business-logic-filled events, velocity on changes involving that file slowed down a lot. We broke convention and moved events into namespaces closer to the code.
- pinchhit 6y ago
  Three things that would make re-frame better, if you want them: - A supported/blessed way to switch out the entire app-db entirely for the purposes of testing - Use of symbols rather than namespaced keywords for function dispatch - Docs that give alternate strategies for code organization (fine to have the events.cljs convention, but would be nice to see some viewpoints like having one per child ns similar to angular's code organization model.)
  - MikeOfAu 6y ago
    Answers to your three points: - I'm wondering if re-frame-test might help? - That ship has sailed a long time ago. And, even if it hadn't, I diagree that symbols would be better. - I'm unfamiliar with angular's code. The Resources section lists larger apps which you can inspect.
    - pinchhit 6y ago
      I'll try re-frame-test, thanks! If it doesn't do something like `(with-redefs [re-frame.db/app-db (reagent/atom {})] ...)` it is still open to this bug, though. Because the call to `dispatch` happens inside of a callback the test library has no way to signal that future dispatches coming from a different function context should not be put on the same queue. It'd be hard to change that aspect of the API now, and I wouldn't recommend you do it; but right now, editor completion and new-user understanding is just better on the reagent side. They do this: (defn assoc-foo [db bar] (assoc db :foo bar)) (defn fetch-new-foo [db bar] (go (let [bar (<! (get-bar)] (swap! db assoc-foo bar)))) (swap! db assoc-foo bar) (fetch-new-foo db bar) whereas re-frame would make you do this: (re-frame/reg-event-db ::assoc-foo (fn [db [_ bar]] (assoc db :foo bar))) (re-frame/reg-fx ::pull-from-channel (fn [{:keys [f event]}] (go (let [resp (<! (f))] (re-frame/dispatch (conj event resp)))))) (re-frame/reg-event-fx ::fetch-new-foo (fn [_ _] {:pull-from-channel {:f get-bar :event [::assoc-foo]}})) (dispatch [::assoc-foo bar]) (dispatch [::fetch-new-foo]) The first one has a lot going for it; swap! is part of the standard library, has a bunch of docs for free, etc.; any clojure editor will pick up on the use of assoc-foo as a function and give you arity warnings if you pass too many parameters, etc. I've looked at the larger apps - the way I've seen people be most successful if if they have a child namespace with events, subs, & views laid out on a per namespace basis (`my-ns.events, my-ns.subs, my-other-ns.events, my-other-ns.subs`.) Partially due to the tone the docs take, there's always some pushback as to whether that's the re-frame way to do things, and I'd love to just be able to avoid that whole conversation in the future.