This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-08-03
Channels
- # announcements (12)
- # babashka (36)
- # beginners (126)
- # calva (26)
- # cider (10)
- # clj-kondo (71)
- # cljdoc (3)
- # cljsrn (2)
- # clojure (232)
- # clojure-australia (1)
- # clojure-europe (11)
- # clojure-france (20)
- # clojure-nl (4)
- # clojure-norway (1)
- # clojure-serbia (4)
- # clojure-uk (6)
- # clojurescript (62)
- # conjure (5)
- # cursive (12)
- # data-science (1)
- # datomic (57)
- # deps-new (1)
- # duct (3)
- # emacs (5)
- # events (8)
- # fulcro (6)
- # graalvm (5)
- # helix (3)
- # jobs (6)
- # jobs-discuss (3)
- # kaocha (4)
- # lsp (128)
- # malli (12)
- # missionary (22)
- # off-topic (1)
- # pathom (7)
- # polylith (27)
- # quil (1)
- # re-frame (20)
- # react (9)
- # reitit (12)
- # releases (8)
- # remote-jobs (3)
- # sci (3)
- # shadow-cljs (9)
- # spacemacs (10)
- # tools-deps (7)
- # vim (7)
- # xtdb (14)
Quick question about union queries: is it possible to union on an attibute that isnt the ident? I have a system where all products have a :product/sku
and a :product/type
. Products with different types need to be displayed/edited using different components. Is this a use-case for union queries, or would I be better off using pathom in lenient mode and requesting data for all types and dispatching on :product/type
?
Fulcro's UI interpretation of union queries is as follows:
When denormalizing a given edge (e.g. {:feed/entry [:image/id 22]}
) where the query for that join (:feed/entry) is a UNION, it uses the keyword portion of the ident to look up the subquery on the union component. Thus, the first element of the ident IS the index into the map of the union query.
So, resolution on the server of union queries is one thing, but the UI interpretation structure requires that you use idents that can dispatch this way.
Normally you use union queries when the underlying data is actually different (in complete identity). For example and image vs text object vs video. In those cases the keyword (first) of the ident will naturally vary, normalization will work properly, as will union query lookup.
In your case you've got a single kind of thing (a product) and you want to vary some display aspect based on a type field. This is not a good use-case for unions. Instead just dispatch your rendering on :product/type
and use plain functions to encapsulate those differences.
Thanks for the info!
Perhaps an additional bit of info to enlighten: Union queries can be seen as a kind of optimization: To not over-query when the possible things at a path have an orthogonal nature. This is true for the network and the UI, since every prop that you query for (or worse, have a sub*query for) entails overhead. If there is a lot of *overlap and very little orthogonality, then a union isn't really called for (the optimization doesn't win much, and the overlap in identity causes the issues above).