I've decided to finally come back to ClojureScript (last time I looked at it was 2014) and after some suggestions from folks in other channels here, I got started on Tuesday with figwheel-main and re-frame (I'd previously used an early version of Reagent and I think re-frame came out after I'd given up on ClojureScript?). It's all going pretty smoothly, in terms of learning (the docs are great; I started with figwheel's template with Reagent, then added re-frame and converted the code to use that... took me about an hour to figure out how to run auto-testing in one browser tab with the app in another tab, and to work between VS Code and the REPL to experiment and learn).
I noticed there's a re-frame-test project that talks about running tests on both JVM and cljs ... which was when I first noticed that re-frame is almost all .cljc
files (aside from the interop
ns). So that made me curious... is it actually feasible to write JVM-based Clojure apps using re-frame on the server? interop.clj
has lots of caveats, including a note about tests doing extra work because of the naive way make-reaction
is written). So, is it practical to write server-side code with re-frame? If anyone has done that, I'd be curious to know how you get at the "results" since the view rendering stuff is an infinite loop and it just side-effects stuff into the DOM.
I assume "JVM-based Clojure apps" refers to web apps, but re-frame can technically be used to build desktop and terminal apps, https://github.com/phronmophobic/membrane-re-frame-example
Nice! Thanks @smith.adriane
@seancorfield
You might also be interested in the official re-frame template https://github.com/day8/re-frame-template which uses shadow-clj and supports Calva (unless you are 100% committed to figwheel)
Regarding re-frame-test
, a local Australian company was very keen on the idea, and did much of that work, and we thought it seemed like a good idea, so we made changes to accommodate it (like moving to .`cljc`), but we never used it ourselves. Because of politics, the local company was soon after forced to use Angular or something, so they never really went on with it. So, I'm left slightly unsure of its status. At one point, it was certainly sufficient that they were no longer asking us for changes. Anyway, I'll be interested to hear how you go with it.
Based on my experiences with Figwheel this week and Shadow-cljs a while back (when I was hacking on Chlorine for Atom), I think I'd rather stick with Figwheel, and I don't use Calva -- I use Clover for VS Code.
I'll probably create a basic app from the re-frame-template and merge the relevant bits into/over a basic reagent/figwheel app when I'm ready to actually build something "real"...
@https://app.slack.com/team/U8P40TFSR re-frame-10x doesn't yet work with Reagent 1.0.0 We'll make that happen in the next few weeks.
@mikethompson That re-frame-template looks like it requires Leiningen? (at least it only seems to contain project.clj
)
Yes
Uses Lein
I haven't used lein
for years (except when helping beginners with problems here on Slack) π
You calling me a Dinosaur?
I think you are
:-)
Only if it takes one to know one π¦
When I was looking at Shadow earlier in the week, it also looks very node-focused and I don't want to install node and all that nonsense on my laptop for cljs stuff π Someone said it can be used as a library but the docs seems a bit thin on that, which is another reason for me to stick with Figwheel at this point π
(I do have node etc on my desktop from back when I was using Shadow-cljs to hack on Chlorine... but I really don't like JS/node...)
If you want to use React components (javascript ones), then Shadow-clj used to be the best choice by far. Having said that, I know that Bruce Hauman did a lot with figwheel about 6 months ago, so perhaps it got back to parity
I'm trying to completely avoid JS but we'll see how that goes. Others on my team are heavily into JS/React so they may well start recommending React components to solve problems that I may have building something with re-frame.
(I did see some sort of "npm bundles" option for figwheel's template so...)
I find figwheel pretty great, and it stays close to cljs cli, basically one writes "figwheel.main" instead "cljs.main", some extra opts aside
some issues on logging and reporting errors, but I think that's more on cljs than fig
π
Yeah, I'm a little out of the loop
Re: server-side re-frame -- interesting history and good to know that it may be "unknown" in status at this point. I may have a play and see what I think.
I would be interested to know if the re-frame modelβs viability on the backend: it would be nice to transpose the same philosophy for backends with a central global variable and event dispatchers. The killer feature of re-frame would always be 10x for me. It just makes the state tangible.
I made some slides on my little project: https://github.com/tape-framework/doc/blob/master/docs/Internals.pdf
@neo2551 It would be viable but only for a kind of backend that is fairly rare - complex state maintained per connection
essentially if the state of the frontend was persisted on the backend
pheonix live-view type stuff
but at that point it is kinda just an actor system
I spent several hours last night playing with re-frame on the JVM and I can see it being very useful in some situations but maybe making most server-side stuff unnecessarily weird/complicated π
what kind of things were you doing with re-frame on the JVM?
(partly because re-frame seems to suit a continuous process that updates an external "system" but it doesn't feel as good a fit for discrete request/response stuff like a web app)
@smith.adriane Nothing specific really -- just kind of exploring what sort of app model is possible with that architecture. It seems hard to wrangle an "end" state onto something spawned via rf/dispatch
and most stuff I actually build on the server is discrete. That said, we do have some continuous processes running at work that might be very suitable for a re-frame style workflow...
that being said, i've been thrust back into re-frame for work after focusing mostly on elm since 2016-17
so i am trying to figure out "what is going on" at the same time as figuring out how to feel about the whole thing
I like the separation of events definition and dispatch
It forces to have some kind of queue.
I could be heading there with Tape Framework. "Isomorphic" (don't like the word but that's what frontend folks call it). All the pieces seem to support both browser and server (reagent, re-frame, reitit). The trick is some conventions: - all event dispatches originating in the UI are via router - keep app-db very lightweight (as in each event sets it anew). - maybe special treatment for (:session @app-db) Something along those lines. But I don't know if it's a real value add If you squint at a https://github.com/tape-framework/7guis/blob/master/src/tape/guis7/app/guis/counter/view.cljs and https://github.com/tape-framework/7guis/blob/master/src/tape/guis7/app/guis/counter/controller.cljs it looks like Rails.