This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-07-25
Channels
- # admin-announcements (2)
- # beginners (36)
- # boot (37)
- # cider (65)
- # cljsrn (92)
- # clojars (3)
- # clojure (225)
- # clojure-austin (5)
- # clojure-belgium (2)
- # clojure-brasil (3)
- # clojure-china (1)
- # clojure-greece (2)
- # clojure-mexico (3)
- # clojure-news (2)
- # clojure-quebec (1)
- # clojure-russia (14)
- # clojure-spec (24)
- # clojure-uk (53)
- # clojurescript (34)
- # cursive (14)
- # datascript (9)
- # datomic (4)
- # defnpodcast (8)
- # devcards (30)
- # dirac (7)
- # editors (7)
- # emacs (1)
- # figwheel (1)
- # hoplon (85)
- # immutant (2)
- # incanter (1)
- # luminus (5)
- # off-topic (41)
- # om (18)
- # onyx (11)
- # perun (2)
- # re-frame (11)
- # reagent (9)
- # ring (3)
- # spacemacs (2)
- # spirituality-ethics (1)
- # test-check (19)
- # testing (12)
- # untangled (14)
- # yada (9)
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 https://github.com/omcljs/om/pull/696 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.