Fork me on GitHub

It's been a while that I've worked with more complex Om Next queries - if I have a root query like [{:screen [{:layout [{:title [{:users <user attributes>}]}]}], is there a way to normalize based on the {:users ...} query without having all intermediate levels (`:screen`, :layout, :title) in the denormalized app state?


Is there any kind of sugar for adding docstrings to components? Or do I have to defui ^{:doc "Some documentation"} MyComponent?


I'd like to transact! to create an entity, then navigate to that entity. I could bake the navigation (updating the current route) into the mutation action, but that feels like the wrong level of abstraction to me. In particular, there are other times I want to create the entity without navigating to it, and that doesn't seem like it should be a separate mutation. Is there a preferred solution for this?


I guess I'm really trying to do two mutations—one to create the thing, and a second to navigate—but the second depends on the id from the first.


@anmonteiro: saw that you submitted a patch for the singleton issue, thanks! I think I may have found another union/recursion issue with db->tree, this time without singletons in the recursion. I used your om-727 branch when running these tests. Can you confirm?

(deftest union-recursion
  (let [state {:curr-view      [:main :view]
               :main           {:view {:curr-item [[:sub-item/by-id 2]]}}
               :sub-item/by-id {2 {:foo :baz :sub-items [[:sub-item/by-id 4]]}
                                4 {:foo :bar}}}]
    ;; Fails: empty map on recursion
    (is (= (om/db->tree '[{:curr-view {:settings [*] :main [{:curr-item [:foo {:sub-items ...}]}]}}] state state)
          {:curr-view {:curr-item [{:foo :baz :sub-items [{:foo :bar}]}]}}))
    ;; Succeeds: full data on recursion
    (is (= (om/db->tree [{:main [{:view [{:curr-item [:foo {:sub-items '...}]}]}]}] state state)
          {:main {:view {:curr-item [{:foo :baz :sub-items [{:foo :bar}]}]}}}))))


@ethangracer: yeah, seems like a bug


file an issue?


@ethangracer: sure, go ahead. including just that failing case should be enough


@ethangracer: hrm, actually let me check one more thing before that


yeah, bug. The problem is that db->tree is assuming the recursion on the union when in fact the recursion is on the join


ok, will file that in a few


@ethangracer: thanks, fix should be simple, I should have something in a few minutes


should be the same as applied to db->tree


awesome. ah, got it -- the union-expr doesn’t need to be passed down if the query is recursive. these algorithms are super intricate


my hunch was right


@anmonteiro you’re awesome, thanks again. I hope your contributions (and the speed with which you contribute) have been recognized by others in here, but they have absolutely been appreciated by all of us at NAVIS.