Fork me on GitHub
#re-frame
<
2023-07-25
>
vemv19:07:38

I hadn't used re-frame for a while. Maybe 2018-19. Checking the changelogs for the last few years, changes seem to have been rather gentle. (which of course is a great thing clj) Still, is there something new I should be aware of? Any practical matters that have changed over time? Perhaps the best practices of how one interacts with 3rd party React components have changed? Should I be picky/cautious when picking such a component?

hifumi12319:07:01

most of the react ecosystem has moved on to hooks

hifumi12319:07:26

so you will be typing :f> a lot more often than otherwise, also re-frame now warns you if you use subscriptions outside of a reactive context

hifumi12319:07:09

similarly, implementations of re-frame divorced from reagent have popped up recently, in case you want re-frame but with the speed/ease-of-interop of libraries like helix cf. https://github.com/ferdinand-beyer/refx

hifumi12319:07:26

to give you an idea of how compatible refx is with re-frame, I aliased re-frame.core to refx.alpha in one of my projects where I use martian-re-frame, and everything works out of the box

vemv20:07:43

Interesting - thanks much! 🍻

p-himik20:07:43

There are also global interceptors - some things are much easier to achieve with them.

👀 2
vemv22:07:18

I found this post, which is reassuring https://github.com/day8/re-frame/issues/590#issuecomment-654653862 Like most folks here, I'm allergic to the churn. However it's been 3 years since that post. Would you say it's now unavoidable to have to deal with hooks? i.e., are they here to stay? Is it reasonable to try to stick to only class-based 3rd party components, plus whatever components the re-frame community already has? (plus one's own components, of course)

hifumi12322:07:33

you can avoid hooks as long as you avoid any 3rd party react libraries and stick with what the CLJS ecosystem already has

hifumi12322:07:58

otherwise, you’ll spend more time trying to avoid hooks than simply typing :f> or resetting the default compiler in reagent

hifumi12322:07:27

re-frame itself is super stable, if there is something id worry about, it’s reagent’s react 18 support — i recommend staying on react 17 until hot reload and concurrent rendering issues get ironed out

Kimo00:07:05

It's now conventional for event handlers to return a vector of effects under a single :fx key. Explicitly ordering effects by default is pretty nice, IMO.

Kimo00:07:54

Overall, I agree with hifumi. It depends on your project's venn diagram between cljs vs. react ecosystem support. At day8 we're also trying to figure out whether to mainline something like Uix2, or to stay downstream with reagent. Reagent's development seems pretty slow, perhaps for good reason. To oversimplify: reagent's purpose was to make react functional, but now react itself is functional. With this value-prop removed, the rest of reagent seems like more of a light-weight design pattern. Perhaps we can add the ergonomics of ratoms, reactions and form-2 components into future libraries with less effort than it takes to maintain reagent's full component abstraction. I think clojurians feel torn over this topic. We prefer frameworks that are stable, even to the point of immortality, but we also value a clean interop story.

❤️ 6
Kimo00:07:14

Another point to keep in mind: not only is it easier for a lib like UIx to interoperate with modern react libraries, but modern react libraries are themselves easier to use. Also, check out out https://github.com/squint-cljs/squint for a whole other take on react interop. Pretty soon, what we think of as "clojurescript" may be literally just javascript without syntax.

hifumi12303:07:46

yup… i moved to helix partly for effortless interop + some niceties like being able to detect invalid hooks usage at compile-time… through refx i get to use most basically all of the re-frame API, minus deprecated things like dynv in a subscription

hifumi12303:07:10

and I somehow had missed that the recommended way to declare effects was now the :fx change

hifumi12303:07:33

its a huge game changer to have guaranteed order of dispatching events… IIRC :dispatch-n did not make any guarantees about the order of events being fired, but something like

{:db (assoc db :spinny/thing true)
 :fx [[:dispatch [:event-1 ...]]
      [:dispatch [:event-2 ...]]
      ...
      [:dispatch [:event-n ...]]]}
does guarantee the events are dispatched in order

p-himik07:07:37

:dispatch-n does guarantee order. However, using e.g. both :dispatch and :http-xhrio in a map won't guarantee anything. (A map literal with up to 8 entries still guarantees order since it would be an array map, but that's an implementation detail which you should not rely on.)