Fork me on GitHub

@ozzloy_clojurians_net you need to dereference the atom inside a component


You’re derefing it inside the call to render which doesn’t setup the tracking correctly


Is there any smaller implementation of pprint suitable for cljs usage? Including clojure.pprint to my application adds about 90KB to the final bundle size, which ends up being like 40% of my application size, but I'd love to be able to pprint in production env as well (currently excluding it for production builds)


Hey folks, I have been out of the loop with clojurescript for a while, are there any guides out there that list the recommended libraries (that are actively maintained) for the common frontend tasks? Also, do people use things like postcss or are there cljs alternatives? Do people use webpack to get access to all the plugins?


Re recommendations, everything is pretty opinionated as far as I know. I know some groups "standarized" in just using re-frame + reagent, pulling in npm modules for smaller functionalities as needed. Some of them do inline styling in hiccup, others use a css file, others use styled-component. I haven't myself came across any (cljs) projects using webpack, shadow-cljs/figwheel/figwheel-main handles pretty much every common frontend workflow as far as I know


Looks like it hasn’t changed much then! Thanks.


Looking for a bit of help from somebody with more knowledge of the inner workings of ClojureScript here, any help appreciated! I’m attempting to enumerate over fn defintions in an ns and fetching each fn’s metadata, however I’m running out of ideas on how to accomplish this. This is as far as I’ve gotten. Is it even possible to do what I’m trying to do?

; in my.ns
  (defn a {:x :a} [])
  (defn b {:x :b} [])
  (:x (meta (var a))) => :a
  (:x (meta (var b))) => :b
  (doseq [f (keys (ns-publics 'my.ns))]
    (meta (var f))) => Unable to resolve var: f in this context...


@looveh You can use (ns-publics ’my-namespace) to get back a map of symbols to var expressions


I am trying to find out if there is a way to prevent the modularization step of compilation. Specifically, what are all the ways cljs.closure/src-file->goog-require is invoked? I can see there is an invocation within src/main/clojure/cljs.repl.cljc’s load-file at line 622, but how about the cases where we just want to make a build, no repl? Thanks for any comment.


hello everyone, I could use some advice to get back into the cljs ecosystem after a long hiatus


2-3 years ago I built some stuff using “reagent + figwheel + cljsjs”, is that still a viable setup?


sub figwheel-main and you're good to go.


ahh, I did not know there was a new version out, and the Reagent lein template still uses lein-figwheel. Looks like I can use instead. thanks for the pointer! 🙏


oh yea. you'll want deps.edn rather than lein for sure. much better experience


I'm not sure deps.edn rather than leiningen is a "for sure" yet. I haven't found a feature of deps.edn that isn't already supported by leiningen. Only thing I can think of is that deps.edn is more "blessed" by the core clojure team


It’s far less noisy / more concise. Plug-in system is far simpler / less buggy.


Built-in support for git sha refs


In general it “just works”


And that most definitely isn’t the case for the complicated leiningen


yeah, generally (in my experience, not doing anything too fancy), leiningen "just works" too. Hence the uncertainty around you using "for sure". I don't mind what you use, but plenty of the ecosystem still uses leiningen, for what's it worth


I’m just giving my opinion. I’ve used both heavily and there’s just no comparison. Feel free to disagree

👍 1

I’ve poked around a bit and now there is shadow-cljs, :foreign-libs and tons of other new stuff, so I’m worried I’m doing something completely outdated

Jeff Evans18:09:32

#figwheel and #reagent are definitely still active


good to hear! if I’m using those two, what would be the “go-to” way to import libraries such as Semantic-UI-react?


it used to be cljsjs but from what I gather there’s been a lot of change in that space recently


cljsjs is still the first resort if there is one available


the only thing that has changed is npm module consumption


right! I have very limited knowledge of the broader JS ecosystem (I’m a primarily a Clojure/Java guy), so safe to say I should stick to cljsjs then :thumbsup:


Honestly I would go with shadow cljs. It makes npm interop so much easier


is that true with the recent cljs npm interop changes though? my understanding is that shadow is outmoded by the cljs way


Yes it’s still true in my opinion.


The other way requires setting up bundlers and I’m not sure the best way to do that. With shadow it’s a simple npm install and shadow does everything for you


yes the whole point of the cljs changes is to use webpack like the rest of the JS ecosystem does


there are tonnes of tutorials on how to set it up


but if i were starting a new project at this moment in time, i'd go that route for sure


I will say that I am a simple dev and cljs+figwheel+reagent has gotten me very far, even with all the fancy features you mentioned. Here is a little self-inflated demo project that incorporates all of those things: That being said ... for anything MORE complex than the features I have here... I've been checking out the shadow docs and shadow is killin' it with features.

👍 1

does anyone know if it is possible to dynamically construct "qualified keywords" at reader / compile time ? ideally taking the form :ns/class/field


(i've tried both a macro and a tagged literal but neither will get evaluated prior to clojure spec's macro expansion time)


here is my reader implementation for details on what i'm trying to accomplish:

(defn read-ns-grouped-keyword [s]
  `(let [[group# kwd#] (clojure.string/split ~s #"/")]
    (keyword (clojure.string/join "/" [~(str *ns*) group#]) kwd#)))


used like so: #myns/ns-grouped-keyword "event/type"


cljs.user=> #myns/ns-grouped-keyword "event/type"