Fork me on GitHub
Alex H19:04:09

it's attached to the query structure itself - so the [:product/id ...] will be tagged with metadata that it's a product

Alex H19:04:26

I've built the same thing a year or so ago in re-frame and works just fine that way

Alex H19:04:47

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

Alex H19:04:45

simple example with all the sub-queries spelled out instead of hierarchically derived (have the latter, too):

  (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
                             (df/query entity/Print
                                        {:>/card (df/query entity/Card
                                                            {:card/inventory (df/query entity/Inventory
                                                            {:card/faces [:card.face/id
                                        {:>/inventory (df/query entity/Inventory

Alex H19:04:50

The only thing df/query does there is (with-meta ...)

Alex H19:04:24

when the data comes back, the normalization engine just checks the metadata attached to the original query, and normalizes accordingly

Alex H19:04:47

I think that's also pretty similar to what fulcro does internally


thanks, that helps


so it looks like you annotate each level of query with an “entity” that allows you to associate the ident info

Alex H19:04:48

yea, pretty much - the stuff I want normalized gets annotated

Alex H19:04:14

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


have you attempted to integrate anything with spec yet?

Alex H20:04:58

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


just checking


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


it makes sense why you wouldn’t care as much if you already had these descriptions with normalization without specs. I just already have them, and don’t want to write the same thing twice 😛