What kind of CSS framework/design system/principles would you recommend to help build a simple CSS based presentation?

How about variable/dynamic?

Hi, I was wondering what mechanism(s) are available for documenting individual namespaced keywords. If there is no such approach in the language, how do you go about this? thx.

I would do this

(def thing 
  "Indicates that you should do the thing"
  ::thing)

then use the var

bad idea to have vars proxying to keywords.

@thomasmoerman that question is totally on-topic 🙂 , which is off-topic in the off-topic room

you could always make a little table (a map) of keyword -> information about the keyword

which might include a docstring, might include other stuff too

what's wrong with vars proxying keywords?

it's slower and it makes two things that need to be synced

it's the moral equivalent of creating a set of "getFoo()" methods for the foo field on a Java class

hmm ok

I find it useful sometimes when I want to have like a global singleton I can use as data, e.g. in re-frame:

(def user-sub ::user-sub)

(rf/reg-sub user-sub ,,,)

(rf/subscribe [user-sub])

this is due to the fact that re-frame doesn't return a reified thing, of course; a little quirky

I don't see what value that provides over just using ::user-sub

@thomasmoerman if you use spec, you can make your own spec/def wrapper that accepts an extra docstring argument when you "jump to keyword" (cider does that) you would reach that definition additionally, your wrapper can push the docstring to a registry that you would query with rebl or such I've done exactly this, worked well

mainly helps prevent typos via compiler warnings 😄

and go-to definition

sounds like tooling is catching up to those tho

jump-to-def for keywords was implemented circa 2017 the compiler-check part is true but can also be tackled otherwise (e.g. intentful spec usage)

clojure-lsp now also has jump to keyword definition which works out of the box with clojure.spec and re-frame

clj-kondo delivers this analysis so it can be leveraged by other tools as well

If you def the keyword, you get jump to definition

and also you can list out "possibilities"

(def process-state:a ::a)
(def process-state:b ::b)
(def process-state:c ::c)

@emccue that's not idiomatic so it won't work with typical code, and has been discussed already here: https://clojurians.slack.com/archives/C03RZGPG3/p1620220712458300

I don't mean to be pedantic, just saying that most people don't do this

we aren't using spec, so having all the options listed out in the source code is beneficial

and autocompletion with ns/pr -> ns/process-state:a, ns/process-state:b, ... is also helpful

I don't always do it for sure

and alex is right - it is slower and it is mostly ceremony

but its ceremony that I appreciate when coming back to code after a month or two

I can heartily recommend use clojure-lsp. It works with the most widely used editors for clojure and provides this kind of navigation without introducing such a major workaround.

does it work with cursive?

yes. afaik cursive already has keyword navigation out of the box as well

cursive lets me search for usages of a keyword and jump to definition if its being used in a specific set of forms like re-frame/reg-*

strawman example

same for clojure-lsp, so if that's not sufficient, then ignore what I said

it's pluggable though using clj-kondo hooks

(ns a)

(defn record-transaction [source transaction-info]
  (jdbc/execute ....)
  (tracking/track {:event :recorded-transaction
                   :came-through source}))

(ns b)

(record-transaction ::a/email-blast { ... })
(record-transaction ::a/phone-call { ... })

just easier for me to read the code if I have this

so you mean, custom macros or functions that "register" something using a fully qualified keyword. and you want to navigate to those. yes, you can customize this using clj-kondo hooks in clojure-lsp.

(ns a)

(def source:email-blast ::email-blast)
(def source:phone-call  ::phone-call)

(defn record-transaction [source transaction-info]
  (jdbc/execute ....)
  (tracking/track {:event :recorded-transaction
                   :came-through source}))

(ns b)

(record-transaction a/source:email-blast { ... })
(record-transaction a/source:phone-call { ... })

at least in this case I just mean constants

a keyword is already a constant :)

so is a list [1 2 3]

I mean constants not in the "unchanging value" sense

ok, not going to argue, if this works for you, then by all means, enjoy ;)

but in the "finite set of flags" sense

if that tracks

deffing the keyword in service of tooling or typo-catching is a hack

deffinitaly :)

lol

you might as well not use keywords in this case. (def source:email-blast 0)

so is avoiding macros that def multiple symbols because cursive can't recognize them

and yet...

I can sympathize with that

^ in debugging :some.ns/email-blast is still straightforward to track down. say if these are put into re-frame state or something

previous codebase would use (declare foo) above macros that def'd things to get around static limitations like that. one benefit of nrepl for sure

I think the spec or malli way of doing that might be to define an "enum" of keywords, like (s/def const #{::email-blast})

anyway, each their own

Given the tools available currently (cider, paredit-functionality, LSP, clj-kondo, RDD) what language feedback features is Clojure lacking? e.g I feel like project wide refactors (e.g rename) are now reliable with LSP, a big missing piece. I'm left curious what else is out there?

more off topic

insert-or-update has upsert

is there an equivalent shorthand for get-or-create?

put-if-absent is used from time to time

that saves 0 letters though

yeah it's simply that is has a standardized meaning I think the JCIP book uses it

ensure

is a good word for get-or-create

hmm, so at least to me usage with that would be

(ensure-thing-created ...)
(let [thing (get-thing ...)]
  ...)

like it doesn't imply that the thing will be returned

(doc ensure-thing-created) <- yes it does

@alexmiller is "docstrings for keywords" a thing? I mean, it will be implemented in the future? Or it's not implemented because it's not a good idea? If this is implemented, it will be a "clojure" feature or a "spec" feature?

it's not a thing, and will not be implemented in the future

keywords are shared (interned) and may be used for more than one thing

docstrings for specs may be implemented in the future

that's a narrower context (I would not expect those to be stored on the keyword, but rather available via some api)

you can vote on docstring (https://ask.clojure.org/index.php/731/clojure-spec-def-should-support-an-optional-doc-string) and more general metadata for specs https://ask.clojure.org/index.php/9414/how-could-i-add-metadata-to-specs