I’m not sure if it’s possible for two different components (query engine hits maximum call stack for me), but you might go with recursive queries http://book.fulcrologic.com/#_recursive_queries

Making item contain item s works fine indeed. It would be handy to have a list abstraction between them though, as I this would be a meaningful concept in this particular context. I.e., the same list of items might show up twice in different places, and I’m not sure how to do that (easily) unless I make list s concrete thing. However, if that’s not an option, I’ll have to work around it somehow.

If you don’t have any additional data associated with the list entity itself (so that you need it only for rendering purpose), then you might go with something like

(declare ItemList)

(defsc Item [this {:item/keys [label more]}]
  {:query         (fn [] [:item/id :item/label {:item/more '...}])
   :ident         :item/id
   :initial-state (fn [{:keys [id label more]}]
                    {:item/id    id
                     :item/label label
                     :item/more  (mapv #(comp/get-initial-state Item %) more)})}
  (div
    (div label)
    (div {:style {:paddingLeft "16px"}}
      ((comp/factory ItemList) {:items more}))))

(def ui-item (comp/factory Item {:keyfn :item/id}))

(defsc ItemList [this {:keys [items]}]
  (div
    (for [item items]
      (ui-item item))))

(def ui-item-list (comp/factory ItemList))

(defsc Root [this {:root/keys [items]}]
  {:query         [{:root/items (get-query Item)}]
   :initial-state {:root/items [{:id    1
                                 :label "A"
                                 :more  [{:id    2
                                          :label "B"}
                                         {:id    3
                                          :label "C"}]}
                                {:id    4
                                 :label "X"
                                 :more  [{:id    5
                                          :label "Y"
                                          :more [{:id    6
                                                  :label "Z"}]}]}]}}
  (ui-item-list {:items items}))

Alas, I would need the lists to have idents so that I could reference them. Thanks for the idea, though!

A potential solution that came to mind, that feels very, very dirty, is to essentially embed the behaviour of both lists and items in the item, and switch between them conditionally.

Yep, I’ve also just thought about something like that, e.g. using union query on the item. But that adds quite a bit of complexity…

Yeah, certainly not ideal!

Mutually recursive components are at odds, as you’ve found, with dynamic queries (the query is evaluated at runtime by asking components for their queries). It is probably true that there is some implementation of get-query for which this could work, but it would be a dramatic expansion of how that system works. So, the short answer is “no”.

I think there might be a way of leveraging union queries with recursion…but I’d have to code an example to get it clear in my own head. another option is to consider that you could choose an arbitrary “max depth” and code components like List1, List2, List3 that use the same function for render (and other commonality like the ident), so that get-query is never a recursive call chain. It’s a bit more code (not a terrible lot), and doesn’t really affect how you implement the data model at all. It works with load, though it does send a “longer” query than … gets you…but it is also easy to understand. A macro can also be created that churns out such a thing with a single declaration if you prefer less visible code.

A set number of recursion levels wouldn’t really work in this case, unfortunately. Alright, too bad, but good to know that I shouldn’t head down that road. It seems direct recursion is what comes closest to the structure that I want to enable.

I don’t see any immediate problems. The general philosophy is you can throw whatever you want in the component options and grab them for your own purposes at any time. The wise-ness of a particular routing solution is usually revealed by its runtime behavior over time.

Thank you!

Right…copy react-factory and customize it. If you want complete interop, look at macro-create-element in dom.cljs. You’d need to write a wrapper for it, but it is what the regular DOM macros emit calls to when the macro cannot fully expand at compiler time (thus the name).

Thank you!