This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-07-11
Channels
- # aleph (3)
- # beginners (42)
- # cider (219)
- # cljs-dev (39)
- # cljsjs (19)
- # cljsrn (3)
- # clojure (97)
- # clojure-canada (12)
- # clojure-dev (14)
- # clojure-italy (5)
- # clojure-nl (4)
- # clojure-russia (1)
- # clojure-spec (3)
- # clojure-uk (140)
- # clojurescript (52)
- # clojutre (2)
- # cursive (2)
- # datomic (29)
- # docs (1)
- # duct (13)
- # emacs (19)
- # fulcro (8)
- # funcool (2)
- # graphql (26)
- # hyperfiddle (1)
- # luminus (9)
- # nyc (7)
- # off-topic (26)
- # om (21)
- # onyx (19)
- # overtone (1)
- # pedestal (4)
- # re-frame (10)
- # reagent (109)
- # ring (5)
- # rum (15)
- # shadow-cljs (120)
- # spacemacs (22)
- # specter (7)
- # vim (10)
if you're wrapping a REST api, what factors dictate weather or not you convert all named parameters to kebab-case
or just leave it camelCase
If you're writing an api wrapper, I would go with kebab-case. Or you could accept both. But the point of a wrapper is to bring everything into the Clojure world and kebab-case is the naming convention in the Clojure world.
Tangentially, I haven't used an API wrapper for a while. Instead, I like to use https://github.com/oliyh/martian
there's a big thread on clojureverse talking about keywords and boundaries between different systems and languages
@jjttjj I've been thinking about this a lot lately. With a Clojure server (REST HTTP API/SQL DB) I am converting from PostgreSQL column names (snake_case) to Clojure kebab-case and then to JSON snake_case (make it easier for JS clients). I have a function that recursively updates key names at every boundary. Kind of a pain in the butt (and if your JSON/JDBC lib doesn't have a direct hook then you may end up walking the same data structure twice). Edit: my logic was to try to keep each data format in the most idiomatic style for each language/context at the cost of conversion
yeah it makes sense regarding the idioms of the language. What has given me pause lately is that datomic uses camelCase keyword terms
it has always bothered me, but it extends a bit beyond just clj since there are so many naming conventions in play
except clj is somewhat “unique” in that it uses kebab-case, which some langs can’t deal with
in the past i would always convert things. But there are always edge cases that must be accounted for ("PnL", etc) and effort going into something that at the end of the day doesn't matter a ton
also not converting allows you to leverage the host docs mabe with a little less mental overhead required for the user
but on the flip-side, if you have a bunch of non-idiomatic keywords in your code, may cause subtle mistakes
I think camel case is the most universally supported... maybe I should just get in the habit of using it more for naming SQL columns and JS objects... would sync with Java naming as well