This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-10-27
Channels
- # announcements (13)
- # asami (12)
- # babashka (65)
- # beginners (62)
- # calva (14)
- # cider (8)
- # clara (11)
- # clj-kondo (16)
- # clojure (86)
- # clojure-europe (12)
- # clojure-gamedev (4)
- # clojure-nl (2)
- # clojure-sg (4)
- # clojure-uk (5)
- # clojurescript (206)
- # clojureverse-ops (11)
- # community-development (7)
- # conjure (12)
- # core-async (2)
- # core-logic (13)
- # cursive (49)
- # datalevin (1)
- # datomic (30)
- # deps-new (3)
- # duct (8)
- # events (5)
- # fulcro (10)
- # helix (5)
- # jobs (1)
- # klipse (5)
- # lsp (178)
- # luminus (1)
- # malli (8)
- # meander (3)
- # membrane (13)
- # missionary (1)
- # nrepl (5)
- # other-languages (4)
- # pedestal (4)
- # reitit (3)
- # releases (1)
- # reveal (27)
- # shadow-cljs (89)
- # tools-build (6)
- # tools-deps (11)
- # vim (2)
- # xtdb (64)
Cool talk by Malcolm Sparks, strikes close to the RAD philosophy: https://youtu.be/jTpP4WsUgfQ?t=1228
Can I use union queries if the key I want to switch is not the entity’s :ident
? To clarify, lots of my entities share a common :db/id
that they use for their :ident
, but I have a component that uses a case
expression on a different key in order to decide what to render. It seems that union queries assume it’s the ident that is the switching key…
No. Union queries have no other information available BUT the ident during denormalization, and they have to use that to decide which of the union elements is the subquery. Using native IDs in the data model is fine, but it is better to give each ID an entity-specific name at the resolver layer. You could also give each entity a "type" field of some kind, and generate idents that way (use the type field as the first element of the idents).
BTW: a concat
of get-query
will almost never do what you want. The resulting query will have metadata that only knows the ident function of the container, which will break normalization in 99% of cases...e.g. won't do the right thing if you were to load or merge using that component as the normalizing component
Oh that’s good to know, thanks for the heads up. I ended up solving it at the resolver layer as you suggested.
I got this working:
:query (fn [] (concat (comp/get-query EntityA) (comp/get-query EntityB) ...))
But it feels less than ideal (lots of wasted query computing)