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.

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 https://github.com/bhauman/figwheel-main-template 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

#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: https://github.com/jjtolton/rocinante 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.

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

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"

why does it "need to say that"?

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