Re-frame is still current. The CLJS ecosystem, like CLJ, doesn't churn rapidly 🙂 .

use helix

re-frame (reagent) doesn't play nicely with modern react stuff like hooks, and a bunch of libraries use stuff hooks + all the reasons i'll trauma dump if provoked

Helix by itself can’t be compared to re-frame

it precludes the usage of the homerolled cljs event/sub/dispatch thing that re-frame does

so it 100% can be compared - re-frame dictates how your app is structured. modern react does too

agreed on adopting helix. I've been enjoying combining it with fulcro for data management and subscriptions for reactivity e.g. https://github.com/matterandvoid-space/todomvc-fulcro-subscriptions

I honestly like re-frame. To be honest, I HATE modern React with all the hooks and providers and such

Re-frame allows me to be careful on how I handle my events, and I can register different fx for testing

Which, by the way, I recommend looking at Freerange. It's a re-frame fork with local state, which plays really nice on tests

Also, with Freerange I'm somewhat more free to "break the rules" where things get too inconvenient (like events that dispatches fx that dispatches events that dispatches other fx)

We use the same setup. And there are a few really nice libraries that accompany re-frame. https://github.com/day8/re-frame-http-fx https://github.com/day8/re-frame-async-flow-fx https://github.com/day8/re-frame-10x come to mind

I like to stay current and assess what's new anytime I start a project. The browser can render 20 year old code no problem but reagent isn't going stale - Juho has announced he's working on updating it. I personally haven't found anything I like more than re-frame and the architecture assuming your events are pure makes it extremely easy to include with an RN app if you need one.

@U01M742UT8F don't use async flow. please

don't anyone use async flow

@U013YN3T4DA For your own edification, Reagent is currently being updated to support latest React (React 18). The most current update about this can be read in the blog post https://www.metosin.fi/blog/reagent-towards-react-18/.

I wish I could run a scared straight program for re-frame with my company's codebase

@U3JH98J4R what's wrong with async flow?

We used it for page transitions and data fetching to various degrees. • Events only fire once...unless you hack it. Once enough of your logic exists in the "async graph" believe you me you'll absolutely need to. • Good luck debugging. Re-frame already can suck if you have events dispatch other events (and re-usable helper events oh boy!), and this encourages that and makes that even worse It is >only< good for global bootup, but the temptation will be there for engineers to use it "for something small" later on or the "bootup" of a page. Much better for the "this initialization really needs to be done before anything happens fr" to just use promesa or something and for "I need to initialize a page" just write the events. Have a state machine in something recognizable as page state. Right. page-state. A pattern that everyone using re-frame needs to invent independently without any guidance.

Just like namespaced events. or namespaced keys in your db

I wish I drank

Interesting. We've only used it for booting up an app so far. Seems to do its job, but you make some interesting points.

page state can be quite messy, I agree

I'll link my response here (https://clojurians.slack.com/archives/C03RZGPG3/p1671130080367739?thread_ts=1671055359.229919&amp;cid=C03RZGPG3):

By the way, I'm just debugging an issue with React Hooks conflicting with each other, which causes the page to repaint when an element is nil, even considering that I do have a condition to avoid rendering the page if that state is nil.... now I need to do a double-check.... :man-facepalming:. So yeah, I actually don't like "modern react" at all...

#C073DKH9P is still big, but....What's new? #CRRJBCX7S and #C03A6GE8D32. The latter is for those of us who are disappointed by React.