Clojurians Log v2

@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?

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...

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

@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.

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

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?

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

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

#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

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

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

cljsjs is still the first resort if there is one available

the only thing that has changed is npm module consumption

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"
:cljs.user/event/type

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 https://github.com/bhauman/figwheel-main-template instead. thanks for the pointer! 🙏

@johanatan :cljs.user/event/type is not a valid keyword, otherwise just ::event.type will be :current.ns/event.type?

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:

it's valid. try it if you doubt me. that's an actual live repl session.

i have two requirements here: (name kw) must produce exactly type and it must be qualified by namespace and the word "event"

so: :cljs.user_event/type would also satisfy that

but aesthetically slash looks better

regardless whether you use underscore or slash though, the problem is the same

i.e., this is the actual problem: https://clojurians.slack.com/archives/C03S1L9DN/p1601144150065700

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

I don't understand the problem statement. I looks to me like the slash is the only problem.

::event.type will be fine while ::event/type will look for the event alias which probably doens't exist

cljs.user=> ::event.type
:cljs.user/event.type

(name ::event.type) not= "type"

that does not satisfy my requirement

these are intended for use with :req-un and :opt-un of spec

and spec uses name to get the "name" portion of the kwd

the problem statement is that this needs to happen at reader expansion time or macro expansion time (prior to spec's own macro expansion time)

cljs.user=> (name ::event.type)
"event.type"

e.g.,

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

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

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

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

why does it "need to say that"?

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

it's a requirement

https://clojurians.slack.com/archives/C03S1L9DN/p1601146726072900?thread_ts=1601144663.068700&cid=C03S1L9DN

my codebase has a bunch of existing data structures that i'm not keen on changing

the word "type" is used across many namespaces

i'm trying to retrofit clojure spec to an existing non-optimal (for spec) data model

so the (namespace ::event.type) isn't actually a namespace?

correct, it's a "qualification"

which is a concatenation of an actual namespace and a "group"

yeah don't think there is a built-in way to make that happen

https://blog.jeaye.com/2017/10/31/clojure-keywords/

of course there isn't. hence the question. i wouldn't be exploring macros and tagged literals if there were a built in way

well maybe you should explore a custom spec impl 😛

the multi-spec section of this page uses a "non-namespace, qualified keyword": https://clojure.org/guides/spec

e.g.

i.e., :event/type is a non-namespaced, qualified keywor

I wrote an impl a long time ago that works on "unqualified maps" directly and not via spec :req-un

https://github.com/thheller/shadow/blob/master/src/main/shadow/spec.cljc#L133

definitely do not use that implementation but maybe something in that direction works better for your usecase?

i'm afraid i'd have to reimplement a lot. it'd be basically the whole "multi-spec" section of that clojure guide

mutli-spec works just fine with this?

works just fine with what?

https://github.com/edn-format/edn#symbols

/ has special meaning in symbols. It can be used once only in the middle of a symbol to separate the prefix (often a namespace) from the name

i'm not using edn and this isn't really a symbol

it's a qualified keyword

but once again if you really quibble over the "/", it can be a "_"

no harm no foul

spec doesn't care about the difference between: :event/type and :my-ns_event/type

the latter is to prevent collisions between namespaces

I'm not trying to quibble over anything. I'm pointing out that you are actively trying to fight the system and namespace and names. nothing in clojure will let you do that easily. of course you can do so but I would still warn you strongly against doing so since it will most likely need to more trouble in the future somewhere

ok, so then "_" it is

no fight, yes?

now you can join me where I'm at without objection

there is "no fighting the system". there is only "dynamically creating qualified keywords at reader/compile time"

which is precisely what my original question pertained to

I thought you solved that with the reader fn?

no, the problem is that it works in the repl

but in source code, it just gets expanded

not eval'd

and then spec complains that it received a "form"

rather than a keyword

and the fact that cljs has no "eval"

prevents me from actively "evaluating" it myself

reader fns are eval'd at read-time not at runtime?

ah ...

that's not what i'm seeing in practice. looks like they are merely expanded

you are returning a form in your reader fn

skip the leading backtick 😛

just return the keyword instance

hmm, i thought that would work but i got a weird crash when i tried that

let me try again

(that was how all examples I've seen do it so I figured it must be part of the contract)

i.e., all examples return forms not instances

well yeah but the keyword is the form you want?

hmm, looks like you may be right

i think it's working!

🙂

doh!

yep, it's definitely working

thanks for your help!

my repl must have been in some weird state or some other problem was interfering when I tried this yesterday

2nd time's a charm apparently

one other weird thing though. the compiler actually complains about my data_readers.cljc. about both "no such namespace" and "undeclared var". seems spurious as the actual code works fine at runtime

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