morning!
Morning
morning!
Unambiguous data attributes are just so nice. You know exactly what it is (within your app), it can be serialized and passed over the wire, and the data has zero dependencies.
I'm also suprised about how suprised I am about this. I wrote my first real Clojure code nearly 9 years ago, and I had no idea how important the data part and the unambiguous part were. At that point, I just liked the REPL and the ->> macro with map/filter/reduce.
When you say unambiguous, are you referring to namespaced keys?
Yes.
quick example from what I'm toying with right now,
(def realizers
{:doc/slug {:key :doc
:source :datomic}})
(defn realize [request]
(reduce (fn [realized [k v]]
(cond-> realized
(= :datomic (get-in realizers [k :source]))
(assoc (get-in realizers [k :key])
(d/entity mblog.state/datomic [k v]))))
{}
request))
(realize {:request/id #uuid "85b45e6d-a617-4286-9c99-594f1c3a0c6c"
:session/id #uuid "2be72578-6d49-4685-88b5-1a789f2c9a84"
:doc/slug "enklere-7"})
;; => {:doc {:db/id 17592186045502}}credits go to @magnars for this, he calls this "reified parameters". By attaching behavior to parameters, you can push the responsibility for toil to the edge of your system, and just work on nice data-at-hand in the middle.
Re-watching Rich's talks now, I hear Rich advocating for the same thing, I just didn't get it the first time.
Rich was inspired by RDF as far as I know.
That's why I wanted different words than qualified Clojure keywords. The ideas aren't Clojure specific. Though I haven't talked to anybody who are into unambiguous data attributes who aren't also into Clojure π
I assume instead of no nice you meant so nice?
I used gemini to understand the meaning, and it said no nice was a so nice typo:smile:
@seancorfield yes, thank you! Typo indeed.
> Though I havenβt talked to anybody who are into unambiguous data attributes who arenβt also into Clojure π (edited) I have, but itβs been with a bunch RDF nerds so thatβs not too surprising π
It's too bad that namespaced keywords don't gel so well with vanilla JSON.
Not JSON's only downside, of course
That's why we have JSON-LD
> It's too bad that namespaced keywords don't gel so well with vanilla JSON. and also, HTML attributes! It's a shame both keys and values must be strings.
That's why we have XML π
so we want β’ brevity (EDN, JSON, not XML) β’ namespaced keys (EDN, XML, not JSON) β’ no ordering (EDN, JSON, not XML) ?
We don't want another format, that's for sure π personally, I am satisfied with EDN (especially Hiccup) in a pure Clojure context. Venturing beyond that, I find that the W3C specs are great and I like to pick from those. They all work together to create a strong and well-documented tech stack, even the community ones, it's quite elegant.