Re-Frame: Build web apps in ClojureScript and React

http://day8.github.io/re-frame/

by tosh • 6 years ago

123 56 6 years ago

day8.github.io

jb19915• 6 years ago

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/

synthc3• 6 years ago

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

MikeOfAu16• 6 years ago

This comes up often enough that there is an FAQ entry:

https://day8.github.io/re-frame/FAQs/DoINeedReFrame/

hellofunk2• 6 years 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• 6 years 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.

pinchhit5• 6 years 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.

synthc3• 6 years ago

I really dislike the documentation of re-frame. The concepts are quite simple, but the docs explain them in a really confusing and buzzword heavy way.

MikeOfAu16• 6 years ago

Hmm. In my experience, this an unusual opinion (to me, the author). Over the years the re-frame documentation has been the most praised part of the project.

Could you point out the area which you found unnecessarily difficult, and I'll happily review it. Could you also include your background, so I know where you are coming from? The docs are a little oriented towards JS developers coming across, but perhaps you are already very experienced with Clojure and data-oriented design, which makes it seem like the concepts more obvious. Maybe.

thom• 6 years ago

Said with love, happy re-frame user: many developers want to be able to match use cases to docs and code examples as quickly and directly as possible. The re-frame docs contain a lot of very verbose motivation and philosophy (over multiple pages) which while useful context, obfuscates the practical content. All of re-frame’s philosophy would be immediately evident from some code examples on the top level readme on GitHub.

harperlee2• 6 years ago

I’m another person, but: when I initially read an old version of it (about 4 years ago) I liked the comprehensiveness but disliked the tone. Perhaps due to not being a native english speaker, it distracted me and made it harder to get the point.

Quickly peering it it seems that it has been improved, although some things there remind me of what I felt, such as:

    McCoy might report "It's MVC, Jim, but not as we know it". And you would respond "McCoy, you trouble maker, why even mention an OO pattern? re-frame is a functional framework."

This does not help me a lot; although I know about “the real mccoy” expression, I dont understand/enjoy that.

synthc3• 6 years ago

This part: https://day8.github.io/re-frame/a-loop/#the-data-loop The analogy with the water cycle is not helpful at all to me.

My background: I have several years of Clojure(script) experience, and used various other cljs frameworks before trying re-frame, so my view is probably biased.

idointernet2• 6 years ago

I'm a react developer and I immediately wanted to see code examples. I looked through the docs and couldn't easily find any. I went to the API docs on mobile and was met with layout issues (iphone 11 on Chrome).

jb19915• 6 years ago

In my experience, this an unusual opinion

It can't be too unusual; I've seen this critique shared in forums, to which you've replied, for years.

I've seen developers remark how turned off they got by reading stuff like this on its front page, which is frankly just noise and undermines the goals of a serious project:

re-frame is lucky enough to enjoy an unfair advantage...When we use Lisp, we get to leverage 50 years of foliated excellence from the very best minds available.

I mean, come on. The very best minds work in many different fields with many different languages. Lisp doesn't own the best minds, and neither does re-frame. The fact that lisp or Fortran or other languages have been around for many decades is kinda irrelevant, and this writing style permeates all the docs.

Travel the geodesic.
an immaculate hammock conception

The heart of the how-tos is often hidden in lengthy prose that celebrates itself.

dennisy• 6 years ago

I would love to try out all these cool alternatives to pure JS plus Vue or React, but at what point is this a good idea for a commercial production application?

invalidOrTaken2• 6 years ago

At this point I think it's safe to say---clojurescript has proven itself and is not a risk.

An excellent language, good libraries (Metosin's ambidextrous router, Reitit, stands out here), the best development story with Figwheel, and oh, dead code elimination for free, as the cljs compiler leverages Google's Closure (not to be mistaken for Clojure) compiler.

Not to mention that cljs is actually a better fit for React even than JavaScript---implicit return, bias towards functional programming, and it requires no magic JSX step---in cljs you just write your html in nested data literals. It's a dream.

I haven't even mentioned black magic like core.async, or that now your front-end devs have a foothold on the JVM rather than the more-impoverished Node ecosystem(oh, you want to keep Node? Well, cljs runs there too!).

Pitch is a well-funded German startup making a presentation tool in the browser---as in, they can't afford to get their front end wrong---and they're comfortably using cljs.

Frankly at this point I think anyone serious about the frontend, who wants it to be good, not just passable, should be using clojurescript. There are reasons not to---if you need something today, and don't have time to learn a lisp---but for anything not due next week, I'd recommend cljs.

yakshaving_jgt• 6 years ago

Conversely, I found the experience pretty terrible when I worked on a big cljs/reagent/reframe/figwheel app over the course of a couple of years. It was slow, prone to runtime errors (though not as much as JavaScript), and often presented weird edge-cases at the intersection between the Lisp world and the React world. The company ended up abandoning all this stuff after having been big Clojure/ClojureScript evangelists for a long time.

On the other hand, after having built several large Elm applications, Elm is still the tool I'd recommend. On my current ~10KLOC Elm project, compilation is near enough instant, the structure of the code is more rigid so it's far easier to understand — even for beginners — and there's far less potential for runtime errors to occur.

Of course, this is the classic religious war in programming, so I expect someone to appear soon and point out that there is no empirical evidence to support the idea that a type system like the one in Elm or Haskell results in fewer errors in practice. Or perhaps they'll say jet fuel can't melt steel beams.

auganov2• 6 years ago

Two main considerations:

Does the bundle size matter? CLJS bundles are not terribly huge but if you need a very lightweight bundle you're out of luck. Vs plain JS there is just no comparison. Vs plain JS + just a few libraries CLJS will probably do worse too. But for anything bigger it starts to catch up. Say I'd never use CLJS for a landing page, but for most kinds of apps there shouldn't be a problem.

How do you plan to interact with the wider JS ecosystem? One problem with CLJS is while you can pull in most JS stuff, it doesn't work the other way around. Your CLJS library will not be a first class citizen in the JS world. It can be done but it's not a good idea. You can contribute to the CLJS world, but forget about contributing anything significant back to the JS world.

If these two don't bother you, you should be fine.

adamkl• 6 years ago

Your CLJS library will not be a first class citizen in the JS world. It can be done but it's not a good idea.

Why is this? What makes it a bad idea? Does ClojureScript’s new ‘bundle’ compilation target [0] help resolve whatever issues you are referring to?

Genuinely curious.

[0] https://clojurescript.org/news/2020-04-24-bundle-target

b4ke2• 6 years ago

the documentation seems thirsty for validity, if i am being honest about it's attempts to impart understanding with it's quip context.

yogthos• 6 years ago

Re-frame is absolutely fantastic in my experience. Here's a beginner workshop on Reagent/re-frame that I ran for Js devs a little while back. If you're interested to try ClojureScript, this will run your through the basics from ground up

https://github.com/ClojureTO/JS-Workshop/tree/shadow-cljs

frompdx2• 6 years ago

I enjoy working with re-frame and can't imagine building single page apps in ClojureScript without it. For some reason the docs are controversial, which is a surprise to me. I appreciate the conceptual framing in the docs and how each section builds upon the previous. I don't mind the references to star trek or statements on the greatness of Lisp.

A common complaint seems to be the docs are too verbose and people just want to jump in and use the library. If this is you, I recommend using the Luminus framework https://luminusweb.com/ to generate a new project template so you can hack on a ClojureScript project with re-frame to see if you like it.

  # Make a new project with re-frame
  lein new luminus my-project +re-frame
  # Start the clj and cljs repls
  lein repl
  lein figwheel

filoeleven• 6 years ago

I’ve looked at re-frame for a couple of years now, since right when I started learning Clojure on my own time, and I’m quite interested but still on the fence about whether it would be helpful for my use case.

Our API calls are messy (historical limitations) and clojurescript’s robust data merging capabilities would work wonders here. In a new front-end iteration I’m trying to use the model of a single global data store, but given how many conditional API calls we have to make and how much easier and more idiomatic it is to “cheat” with mutability in JS, it’s hard to convince my team to be rigorous about keeping to this pattern for everything. There are real difficulties and tradeoffs there: ES6 spreads more than one level deep are hard to read, we may want to display a view before its drop down entries are resolved, etc.

The essentials are that we have to handle retrieving the following:

1. A model that represents some global concerns (auth, network/system errors, websocket messages) plus the data required by the current view.

2. A template that determines how to display the current view. This can be a full-page display with nav tree links to other views plus the display form that a given field should use (input, drop down, button, etc.), or it can be a modal view, n layers deep, and also may or may not contain a nested nav tree of its own. (Yep, we have to keep the lower-layer models ourselves and still merge errors/websocket stuff.)

I’m already confident that cljs can turn the messy model reconciliation into something easier to read and maintain. I’m less certain about re-frame’s idea of how to subscribe to its db data, especially since I’d like to reuse some custom components in deeply-nested data. For example, “sticking a drop down inside of a grid column“ is an expected feature in the view template.

Transforming it from js react to cljs reagent seems like a pretty straightforward exercise—famous last words. The impression I get from re-frame is that it’s “a more robust redux with less boilerplate,” and the dev tools look great. But any proof-of-concept app I develop will be a spare-time if not my-own-time exploration. It’s something I want to do, because I think it’ll save us loads of time later and just be more fun to work with. It’s also an uphill battle to sell using Clojure at my org anyway, and I want to make a good pitch of it without spending too much time in the weeds.

Does anyone have experience with a system like this in re-frame, or in cljs more generally, who is willing to give me some feedback?

Re-Frame: Build web apps in ClojureScript and React

Related Stories