This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-03-31
Channels
- # admin-announcements (1)
- # beginners (16)
- # boot (25)
- # braid-chat (7)
- # cider (4)
- # cljsfiddle (6)
- # cljsrn (1)
- # clojure (256)
- # clojure-austin (4)
- # clojure-ireland (1)
- # clojure-poland (15)
- # clojure-russia (80)
- # clojure-uk (2)
- # clojurescript (30)
- # core-async (14)
- # core-typed (3)
- # cursive (35)
- # datomic (1)
- # editors (28)
- # hoplon (32)
- # immutant (1)
- # jobs (8)
- # jobs-discuss (1)
- # juxt (6)
- # leiningen (8)
- # liberator (7)
- # off-topic (16)
- # om (69)
- # onyx (38)
- # re-frame (10)
- # spacemacs (1)
- # untangled (117)
Guys my parser defined in ns eat-info-front.common.parser init parser and reconciler in ns eat-info-front.common.core i'm init app in ns eat-info-front.personal.core call #(om/transact! this `[(add-persons {:persons ~%})]) in ns eat-info-front.personal.core throw core.cljs:9611 Uncaught Error: No method in multimethod 'eat-info-front.common.parser/mutate' for dispatch value: eat-info-front.personal.core/add-persons
I do not understand why the function mutate is sought in namespace that declares the root component?
@a.espolov: because you're using syntax quoting
this should do it:
#(om/transact! this `[(~'add-persons {:persons ~%})])
@anmonteiro: thx, i'm use copy/paste from old project
I’m observing a state in my om-next app where a component is not rendering with the most recent data available in the app-state. What’s more, this behavior doesn’t occur when the component in question is used directly with add-root! . I’ll provide the client code below. (The server just provides a list, which makes its way into the client app-state when I would expect it to.)
here is the query for the top level component in the kanban demo: https://github.com/Jannis/om-next-kanban-demo/blob/master/src/kanban/app.cljs#L19
though i think some of those queries may be there just to trigger normalization for the first render, so i'm not sure
i think for this kanban sample, if he started with a normalized app state, he would only need one or two queries in "App"
out of curiosity, why does it render the second time I type into the input, even though the root has not declared IQuery?
To clarify that bit, evaluating om/app-state shows the data being set by the reader, but a rerender doesn’t fire until the next change
@isak: that's a good point I never thought of. Copy and paste normalized app state back into your application (from chrome devtools) and get rid of the extra joins. No reason for a more mature app to have them.
queries are not only for normalization purposes
you can have apps with queries and not have a normalized app state
for clarification: if you declare a query in one of your components, that query must compose to the root
there's simply no way around that
after all, you're passing the Root component to the add-root!
call. How can you expect Om to know about queries far deep in the UI tree if Om only has knowledge about the Root?
i.e. if they don't compose, the Om Indexer can't know about queries deep in the tree, which means things will break
Ok. I’m struggling to get the right IQuery in the root. What I have so far, is causing no rerender on any state change.
i think it is problematic to have it wrapped in {:comp } unless that is reflected in your app state
once again, that's just not true
it really depends whether you're using normalization or not
if you're using recursive parsing or not
[{:comp (om/get-query Component)}]
is definitely a valid query
hrm, he hasn't shown the app-state here, or did I miss some messages?
OK that clarifies things. In short, to make that work:
- Root needs to aggregate its child's query and pass the props down
- there should be a read method for :comp
or whatever but that will only be hit on the first render
once you set-query!
the read method that'll be hit will be the :search/resulsts
@isak: what do you mean as is?
without a query in the root?
that's not a valid query
in that case, the Root is stealing Component
's query
still not valid
still the same problem
stealing a query is the same as not having a query
there's still no path from Parent->Child
@anmonteiro: i saw this: http://anmonteiro.com/2016/01/om-next-query-syntax/ . you mentioned this:
;; this one reads every sub-key
'[{:some/key [*]}]
- is that a convention or does om.next provide support for it?@anmonteiro: given that our component is loading search results on the fly, what data should the Root be querying and passing to it?
@isak there's support for it in e.g. db->tree
@uwo: your search results are going to end up in the app-state, right?
so pass that
@anmonteiro: i see, thanks
We’re having a rough time trying to wire anything to the Root. I hate to ask, but does anyone have a moment to jump onto the hangout where we’re screen sharing?