Clojurians Log v2

there's an example for using a custom key-fn in clj-http: https://github.com/dakrone/clj-http/blob/master/examples/body_coercion.clj

or decoding the body yourself something like that with chesire: (json/parse-string "{\"@id\": 1}" (fn [s] (if (= (first s) \@) (subs s 1) s)))

That might be another thing worthy of an FAQ entry. :) Just don't convert random strings to keywords. It's both simple and easy. :strs exists as a replacement for :keys. (get m "a") is not much worse than (:a m) (and (m "a") also works if m is guaranteed to be not nil). If you don't want to proliferate strings, hide them behind functions, which is probably a good practice for keywords just as well, so you don't end up having (get-in m [:a :b :c]) in 15 different places.

Thanks I guess i don't understand what you mean by random, the json has string fields whose values i want, and keywords make that easier then strings. I'm not currently using whatever the json author thought "@" meant and it's conflict with the clojure runtime seems like an incidental translation issue of the :as :json functionality attached to clj-http. That being said, i probably will give up on this for the moment as i don't see an easy way, and to your point, working with strings isn't that much harder.

Given that it's @, :strs won't help much unfortunately so it was my mistake in mentioning it. But you still have get and calling maps as functions. You still can write a tiny let-like macro similar to (str-let [{:keys [a b c]} m] ...) that expands into (let [a (get m "@a"), b (get m "@b"), c (get m "@c")] ...). Yet another approach would be to create something similar to https://github.com/mfikes/cljs-bean but for maps with strings, with custom converters. Actually sounds like a potentially neat and useful project.

yeah, i can get by with get-in lol.

it's just annoying after you drill down 3 branches in a json object to suddenly hit this and have to redo all the code.

Another reason to keep all the get-ins in a single location. :) Behind some interface that you don't have to change even if the underlying data becomes different or starts requiring a different approach for some reason. But yeah, that's a separate topic.