This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-04-02
Channels
- # announcements (1)
- # architecture (1)
- # aws (21)
- # babashka (37)
- # beginners (173)
- # boot (12)
- # chlorine-clover (5)
- # cider (36)
- # clara (11)
- # clj-kondo (25)
- # clojure (128)
- # clojure-europe (7)
- # clojure-finland (3)
- # clojure-germany (2)
- # clojure-nl (57)
- # clojure-uk (23)
- # clojurescript (71)
- # clojurex (1)
- # core-async (30)
- # core-typed (5)
- # cursive (35)
- # datomic (8)
- # duct (4)
- # emacs (8)
- # exercism (41)
- # fulcro (116)
- # jackdaw (4)
- # jobs-discuss (6)
- # juxt (4)
- # kaocha (16)
- # leiningen (14)
- # malli (5)
- # observability (4)
- # off-topic (2)
- # pathom (19)
- # pedestal (29)
- # re-frame (64)
- # reitit (18)
- # ring (8)
- # shadow-cljs (3)
- # sql (13)
- # tools-deps (32)
- # tree-sitter (5)
- # yada (17)
it's attached to the query structure itself - so the [:product/id ...] will be tagged with metadata that it's a product
the metadata doesn't get passed through; it's just held in client state and picked up as the data comes back - then you have all the information you need for normalization
simple example with all the sub-queries spelled out instead of hierarchically derived (have the latter, too):
(re-frame/reg-event-fx
::start
interceptors
(fn-traced [{:keys [db]} [_ code]]
{:db db/default-db
::dfr/fetch {:remote :default
:target {:op :replace
:target [:ui/set :set]}
:marker [:ui/set :loading?]
:query [{[:set/code code]
[:set/id :set/code :set/name :set/type :block/code
:block/name :set/card-count :set/released-at :set/icon-svg
{:set/prints
(df/query entity/Print
[:print/id
:print/collector-number
:gatherer/uri
:gatherer/image-uri
{:>/card (df/query entity/Card
[:card/id
:card/name
:card/color-identity
:scryfall/image-uris
{:card/inventory (df/query entity/Inventory
[:inventory/qty
:print/id])}
{:card/faces [:card.face/id
:card.face/name
:card/supertypes
:card/types
:card/type-line
:gatherer/image-uri
:card/oracle-text]}])}
{:>/inventory (df/query entity/Inventory
[:print/id
:inventory/qty])}
])}]}]}}))
when the data comes back, the normalization engine just checks the metadata attached to the original query, and normalizes accordingly
so it looks like you annotate each level of query with an “entity” that allows you to associate the ident info
each "entity" is just a map, effectively, with info on how to normalize (where to in the database, and which field is the ID), as well as a list of all query-able fields, for convenience, if you just want to grab everything
not on the query-side, no; no plans to do so either (not obvious to me where the benefit is?); I do use spec for validation of mutations, though
we have a lot of specs right now of all our domain entities. it feels like a great extension to those to specify some normalization behavior