Fork me on GitHub
#om
<
2016-03-31
>
a.espolov14:03:57

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

a.espolov14:03:48

I do not understand why the function mutate is sought in namespace that declares the root component?

anmonteiro14:03:24

@a.espolov: because you're using syntax quoting

anmonteiro14:03:44

this should do it:

#(om/transact! this `[(~'add-persons {:persons ~%})])

a.espolov14:03:25

@anmonteiro: thx, i'm use copy/paste from old project

uwo15:03:43

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.)

uwo15:03:49

I’m on "1.0.0-alpha32"

isak15:03:49

uwo I think your Root needs an om/IQuery

isak15:03:06

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

uwo15:03:43

oh, so the Root needs all the data that might change below it?

isak15:03:48

though i think some of those queries may be there just to trigger normalization for the first render, so i'm not sure

isak15:03:16

that is my understanding

isak15:03:59

i think for this kanban sample, if he started with a normalized app state, he would only need one or two queries in "App"

cjmurphy15:03:03

Yes the lanes join iirc is just for normalization purposes.

uwo15:03:03

out of curiosity, why does it render the second time I type into the input, even though the root has not declared IQuery?

isak15:03:34

onChange/onKeypress type thing?

isak15:03:56

i think onChange fires when you blur, could that explain it?

uwo15:03:29

we do see the app state change immediately after onChange fires. just no rerender

csmith15:03:58

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

cjmurphy15:03:27

@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.

isak15:03:41

ah, i see

anmonteiro15:03:10

queries are not only for normalization purposes

anmonteiro15:03:45

you can have apps with queries and not have a normalized app state

anmonteiro15:03:20

for clarification: if you declare a query in one of your components, that query must compose to the root

anmonteiro15:03:26

there's simply no way around that

anmonteiro15:03:29

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?

anmonteiro15:03:08

i.e. if they don't compose, the Om Indexer can't know about queries deep in the tree, which means things will break

csmith15:03:17

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.

csmith15:03:41

I’m using [{:comp (om/get-query Component)}]

isak15:03:32

i think it is problematic to have it wrapped in {:comp } unless that is reflected in your app state

anmonteiro15:03:53

once again, that's just not true

anmonteiro15:03:06

it really depends whether you're using normalization or not

anmonteiro15:03:22

if you're using recursive parsing or not

anmonteiro15:03:48

[{:comp (om/get-query Component)}] is definitely a valid query

isak15:03:13

for his app-state? that is what we're talking about here

isak15:03:48

whether it is a valid query for a theoretical app isn't relevant

anmonteiro15:03:42

hrm, he hasn't shown the app-state here, or did I miss some messages?

isak15:03:24

my understanding is @csmith is referring to the one @uwo posted

csmith15:03:41

ah yes. uwo and I are working on this together

csmith15:03:57

We didn’t have a read method for :comp, so we’re working on that now

anmonteiro16:03:29

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

isak16:03:06

if he had left it as is, and just not wrapped it in :comp, would that have worked?

anmonteiro16:03:13

once you set-query! the read method that'll be hit will be the :search/resulsts

anmonteiro16:03:32

@isak: what do you mean as is?

anmonteiro16:03:35

without a query in the root?

isak16:03:43

i mean if he just set his query to [(om/get-query Component)]

isak16:03:54

for the Root

anmonteiro16:03:00

that's not a valid query

anmonteiro16:03:20

in that case, the Root is stealing Component's query

isak16:03:22

oops, without the wrapping vector

anmonteiro16:03:29

still not valid

anmonteiro16:03:33

still the same problem

isak16:03:50

why is stealing the query problematic?

anmonteiro16:03:26

stealing a query is the same as not having a query

anmonteiro16:03:36

there's still no path from Parent->Child

isak16:03:08

@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?

uwo16:03:11

@anmonteiro: given that our component is loading search results on the fly, what data should the Root be querying and passing to it?

anmonteiro16:03:07

@isak there's support for it in e.g. db->tree

anmonteiro16:03:50

@uwo: your search results are going to end up in the app-state, right?

anmonteiro16:03:53

so pass that

isak16:03:22

@anmonteiro: i see, thanks

uwo16:03:16

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?

csmith16:03:04

nm that idea. breaking for lunch. thanks for the help folks

csmith17:03:04

@cjmurphy: I’m back on the hangout if you’re still available

tomjack21:03:02

given the prevalence of syntax quote in queries, I wonder whether "Thinking With Links!" should mention ~'_? or should om be patched to look for ns/_ as well?

seanirby23:03:43

whats the link to the hangout? is it persistent?

uwo23:03:19

@seanirby: we use a hangout for work. it’s not related to clojurians simple_smile