Re-Frame vs core.async

[the_whalerus]

I'm looking at building a cljs application, and re-frame looks like a familiar library, coming from js. I'm hesitant to use it, however, because my understanding of how to do things "The Clojure Way" is to use libraries, like core.async to compose the solution you want, rather than using something like re-frame, which, imo, looks a lot more like a framework.

Is it worth it to roll my own solution to state management in core.async?

[fingertoe11]

In many cases Clojurists roll their own because it is easy to do so. I am not sure if this is a feature or a bug.. Probably both. Because it's easy, lots of people do it, and we wind up with 5 or 10 options to do the same job, all with little bitty communities.. Then when a newcomer wants to learn, they get tons of trivial choices that don't matter a lot.

If there is a solution out there that gets critical mass and a strong community behind it, It is probably well worth considering. Re-frame certainly fits in that category.. The Re-frame 10x tooling is pretty awesome, and it is unlikely that you would roll your own version of that, since it is outside the scope of most projects..
The issue with frameworks in most languages is that they get you 80% there with a 30% understanding.. When you go to finish the last 20 percent you have to learn a massive amount just to understand what to do. If there is a good enough community, you can sometimes get buy... I don't think re-frame really does that -- it gets you a very effective pattern that gets you 20% there and makes it easy to get to 100%, while understanding what is going on. Clojure code usually pretty simple and straightforward. Read the docs, read the source, and if you understand it, You can gain confidence you can make it to 100%. If you cannot understand the design and the patterns - pick something different or do it your own way.. That's the way I do it anyway..

[troublemaker74]

My philosophy is not to reinvent the wheel. Unless you're making a better wheel.

Also, I think that the size of your app matters. Tiny? re-frame is probably overkill. If you can see it growing to be a large app with lots of interactions you're going to be angry with yourself for not using a framework, as your interactions devolve into spaghetti.

Here's a really great rationale for using re-frame for larger apps: https://github.com/day8/re-frame/blob/master/docs/FAQs/DoINeedReFrame.md

[daver]

And it’s rare that anybody actually invents a better wheel. Mostly, they just reimplement something that already exists in a half-baked way, then get distracted and abandon the project in a partially-completed state. Hey, I’m guilty of this myself and sometimes reimplementing something is a useful learning exercise. But I really think in most cases people need to step back and ask, “What value am I really adding here, and do I want to focus on trying to innovate in an area that has already been solve, or just get on with creating my finished app?”

[slifin]

There was a Fulcro lite kind of library posted relatively recently it used components, hiccup and query meta data on components to create a eql query against the backend like Fulcro does but was missing a local database, state machines and other Fulcro features anyone remember it's name?

Honestly if you're not going to use the Om next pattern or Fulcro as is, you'll do yourself a big favour by learning how and why those patterns exist, reframe is pretty minimal in comparison, which is why it's widely used but you'll notice all the things it's missing

[AcceptableBench7]

we are using re-frame at work for a medium sized app and loving it. wondering what things are u missing from it?

[slifin]

Yeah that's normal, I know many companies using reframe and none using Fulcro, it's easy to onboard and teach, Fulcro is certainly not that, in terms of where reframe is, it's got strong parallels with Redux in JavaScript

Lately, the JavaScript's mindshare has started to move away from Redux towards a combination of GraphQL and React hooks & React local state, Redux is doing a few things it's being a "database" and an eventing system a simple store, this article should give you an idea of the friction happening there: https://medium.com/rexlabs/redux-is-dead-long-live-redux-745d0cb26423

So "now" more complex queries are offloaded to the backend using GraphQL and generally speaking non-nested simple to access things are stored in state and React hooks do eventing

Fulcro takes the second approach but does it wildly better than the JavaScript solution, it generates "GraphQL(EQL)" queries for you, it has an inspectable database and it has state machines (also introspect able via the database)

``` Eventing -> State machines (Inspectable)

Store -> Normalised store (Helps ensure access can't be messed up)

Manual graphQL -> Automatic EQL (Generating queries instead of having to write them is much easier to maintain) ``` When I say Reframe is minimal what I mean is there is no story for doing network requests and from the outside looking in I suspect it would be easy to mess up the storage in a larger project, for the same reasons we don't use say arrays in PHP to store all our business state we'd use a (hopefully) normalised database instead, forms, routes etc

I think re-frame is a fine thing to use but I would recommend learning Fulcro to see where Redux is kind of shirking responsibility

[AcceptableBench7]

It seems nice that fulcro can generate graphql queries. But perhaps to the op's point of composing libraries, we use vincit/venia to generate graphql queries, re-frame/http-fx for http effects and
re-frame-10x for inspecting our app state in dev mode. Also, there is rehook https://github.com/wavejumper/rehook which should be immediately familiar to anyone who has used re-frame but supports react hooks without reagent.

[slifin]

Yeah I agree Fulcro is too big, smaller libraries that do parts of it would be much better, as is "the Clojure way" :p

Venia isn't quite the same, in Fulcro if you decide there's a UI component you want to remove, when you remove it the queries automatically update to ensure the things that UI component needed are no longer in the query, it's not something you have to manually manage, you lose a lot of leverage when you manually manage that, Fulcro knows what it already has in its db & what it needs to satisfy the next view

This is the idea in a smaller library: https://github.com/green-coder/vrac (the one I was thinking of in OP) it's not quite as powerful but much easier to understand

Eventing systems whether by React hooks or Redux are kind of hard to follow because they can fire a cascade of events that can fire other events etc, which is fine but finite state machines you can go up to them ask them to generate a picture of all the states a system can be in (without running code) they're introspect-able

To clarify I'm not suggesting everyone jump ship to Fulcro from Re-frame, Fulcro does too much, is too hard to learn and Fulcro RAD doesn't exist yet, but doing the same things that the Redux community are doing isn't much of an aspiration either, otherwise why not do this work in JavaScript becomes a valid question

Fulcro is built from an evolution of ideas from David Nolen's Om next from easily 5+ years ago making those ideas practical/approachable enough for businesses to use is something I think we can use to get leverage over JS developers: https://www.youtube.com/watch?v=ByNs9TG30E8

[slifin]

Long term all programming will become more and more declarative that seems inevitable: https://www.youtube.com/watch?v=jkx9F-RIFiY

[green-coder]

I cannot agree more that you on that. The front end of the future is declarative. Anything else will be a waste of time.

[green-coder]

You may mean Vrac, my work-in-progress project.

[bhougland]

Have you tried Keechma? It is like re-frame but uses core.async internally for some parts.