5 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.
  - MikeOfAu 6y ago
    Checking: you had a few hundred event handlers in the one namespace? That worries me.
  - pinchhit 6y ago
    Yep, pretty large & business critical app. BTW, while I'm not sold on re-frame personally, it is used in a sizable project that has powered a lot of business for us, so thank you for developing it!
  - 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.)
    - 6y ago

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.
- MikeOfAu 6y ago
  Checking: you had a few hundred event handlers in the one namespace? That worries me.
- pinchhit 6y ago
  Yep, pretty large & business critical app. BTW, while I'm not sold on re-frame personally, it is used in a sizable project that has powered a lot of business for us, so thank you for developing it!
- 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.)
  - 6y ago