Fork me on GitHub
#chlorine-clover
<
2021-01-02
>
mauricio.szabo00:01:56

Thanks, happy new year for you too! Well, Figwheel is not officially supported. There are some "hacks" but nothing concrete yet. But I believe is not hard to support - I can look at that starting on monday. Any reason why you're not using shadow-cljs? To be honest, Chlorine / Clover will probably always be better with shadow (for example, if you enable experimental features it'll resolve promises for you, show compilation warnings on the console, etc)

seancorfield00:01:08

Shadow is pretty node-focused and I don't want to install node 🙂

seancorfield00:01:59

(I know I can run Shadow as a JVM library but that's not very well documented and I get the impression it's not as well supported because it's not the "recommended approach")

seancorfield00:01:16

Having used Shadow in the past, back when I was hacking on Chlorine(!), Figwheel feels a bit leaner and a bit more "standard" (and you know how much I love "simple" tooling!).

mauricio.szabo00:01:42

Well, the point about node is really a good point 😅. It's not hard to use shadow as a JVM library, but even if you do run shadow with clj you still need to install node dependencies (for example, react if you're going to use reagent, etc)...

mauricio.szabo00:01:34

As for leaner, I also prefer shadow to be honest. I think the configuration is easier and more reliable (I used mostly figwheel, not figwheel-main but I remember the compilation process to be quite unreliable). As for what I was studying for making figwheel compatible with Chlorine, I think that you will need to add some dependencies like piggieback and others. I was not able to start a cljs repl without it, for example, and even then needs some wiring.

seancorfield00:01:04

Yeah, I see the "Editor Integration" section of Figwheel (main) talks about nREPL and Piggieback which does not thrill me at all 😞

seancorfield00:01:15

Chlorine had an embedded ClojureScript REPL at some point? I see Clover does not. Did it go away from Chlorine as well?

mauricio.szabo00:01:17

Yes, I remember trying to start a cljs socket repl in figwheel and it gave me some errors like the absence of piggieback

mauricio.szabo00:01:28

Ah, both Chlorine and Clover have embedded cljs. The problem is that it only works with shadow for now, that's why I renamed it on Clover 😅

mauricio.szabo00:01:39

But in theory, connect embedded would detect if the current Clojure REPL have access to the shadow or figwheel API, and then run connect to the right REPL

mauricio.szabo00:01:57

The problem with both Shadow and Figwheel is that none have a "pure ClojureScript socket REPL" - you connect into Clojure then change it to CLJS

mauricio.szabo00:01:03

That's where piggieback comes - to make this bridge

mauricio.szabo00:01:09

(things are complicated in CLJS world!)

mauricio.szabo00:01:46

(well, except shadow-cljs that do have a "websocket REPL" that communicates directly with CLJS, but it's not standard by any means)

seancorfield00:01:27

Figwheel talks about a websocket setup, but that's just for pushing changes to the browser?

mauricio.szabo00:01:09

Yes, exactly. Shadow also does that, but @thheller was kind enough to document the format of this websocket. For figwheel, as far as I know, it's just an implementation detail.

mauricio.szabo00:01:14

I don't even know if it's possible to connect to this websocket and issue evaluation commands to be honest...

seancorfield00:01:58

I wonder if @bhauman would be amenable to either documenting what Figwheel does there, or offering some additional integration for a socket REPL, without the whole nREPL/Piggieback stuff?

seancorfield00:01:17

nREPL and all its middleware just makes me sad. Just like node/npm makes me sad.

seancorfield00:01:40

So I really want to avoid all of that if I can...

mauricio.szabo01:01:41

Well, if you don't use node dependencies like react/reagent or react/fulcro, you don't need npm at all, even with shadow-cljs

mauricio.szabo01:01:58

But if you do, you somehow need to solve the js dependency

mauricio.szabo01:01:03

Figwheel will use cljsjs (it's the node packages inside a jar). It remembers me when I was using Rails and Ruby was packing jquery inside a ruby package 😅

mauricio.szabo01:01:54

(sorry if this all is too basic)

mauricio.szabo01:01:43

I see shadow-cljs' alternative being better - I can, for example, use fulcro or reagent or whatever on native platforms like proton-native or react-native, or in command line interfaces just by installing the right npm. I also don't like npm too much, but I think it's what won the race :(

mauricio.szabo01:01:46

Or.. if you're not going to use any of these you can just import jquery or whatever in a Javascript tag and use it in cljs - no need to use node at all here

mauricio.szabo01:01:20

As for figwheel and socket repl, it's a hard problem. Compilation in cljs happens on clj side, so there's no way to "send a form to be evaluated in a pure ClojureScript repl" because there's no compiler on CLJS, and maybe it won't even have a JS environment to run...

mauricio.szabo01:01:37

So, what shadows do is to offer a websocket that happens as a way to push ClojureScript code to the browser. It runs on Clojure side, doubles as a clojure and ClojureScript repl, and also as a "poor man's REBL"

mauricio.szabo01:01:16

Figwheel does it differently I believe - the websocket server (which is also running on Clojure side) just sends code to the js env, and back. For they to support a pure socket repl I believe they'll have to change lots of things in their implementation

mauricio.szabo01:01:18

For example, when I used figwheel when I asked for a cljs repl, it waited for a js environment and then started the REPL as soon as it was present. If you open another tab, Figwheel will send the eval to the first one. And I have no idea what happens when you close the tab and tries to send eval again...

mauricio.szabo01:01:38

but I remember in the past that bizarre things happened like the REPL closing and I had to re-open it. I believe most of these issues are better now with figwheel-main. But yeah, cljs is quite complicated :(

seancorfield01:01:52

I'm pretty set on re-frame (with Reagent/React under the hood), using cljsjs. No interest in native platforms, just regular web app stuff. But Figwheel has support for npm now I think?

seancorfield02:01:46

Well, I'm going to continue on with this setup for now. I suspect what I'll do is write code as .cljc files and run a Clojure Socket REPL inside Figwheel and connect Clover to that so I can eval and get all the usual fun stuff 🙂

mauricio.szabo02:01:49

If you don't need to support clojure you can just set "eval mode" to CLJ on Clover config, then cljs files will be evaluated as clojure.

mauricio.szabo02:01:04

At least while I study on how to add figwheel support :)

seancorfield02:01:11

I'm going to be building a full-stack app so I'll need real Clojure support as well as ClojureScript. I changed all my .cljs files to .cljc, moved the cljs-only startup bit to a new .cljs and now I can run Clover against a (Clojure) socket REPL and evaluate all my main app code (just not the startup bit) and run tests (also .cljc files) via Clover -- as well as them showing up in Figwheel's auto-test page 🙂

seancorfield02:01:08

Yeah... I think this is going to work... It all looks and feels like Clojure (except the main.cljs startup) and auto-compile/-load works, and auto-tests run... OK. So, don't sweat the Figwheel support. I think I like this setup @U3Y18N0UC 🙂

seancorfield05:01:39

I just updated my dot-clojure/dev.clj file so it works with a Figwheel environment, that already has a Socket REPL open, so that I can still get my customized Reveal experience...

seancorfield05:01:39

I just updated my dot-clojure/dev.clj file so it works with a Figwheel environment, that already has a Socket REPL open, so that I can still get my customized Reveal experience...