Also, (om/get-query MyComponent) works, but (om/get-unbound-query MyComponent) returns the same error. Are these meant to be used on instantiated components only?

All work correctly on instantiated components, so I will assume that’s the expected usage

@chris-andrews: yes those are only for instantiated components currently

@dnolen: thanks for clearing that up for me!

The docs page for get-query and get-unbound-query list MyComponent for the argument, as opposed to get-params, which lists x. set-query! lists some-component as an argument. Would it make sense for me to update the docs so they all list some-component, so it is hopefully clear that they should be used this way?

@chris-andrews: hrm, I’ll need to think about whether the current behavior should be relaxed

so no don’t change the docs

ok, sounds good

is there an om project online that uses tempids other than the om-tutorial?

@adam: Yep, my pastebin experiment does: https://github.com/Jannis/copaste/blob/master/src/app/parsing/copaste.cljs#L29

It's not the prettiest piece of code but perhaps it can give some ideas

thanks @jannis.

Just started learning clojure and om and have come across something that hurts my brain a little. I have been working through the wiki page on [Normalization](https://github.com/omcljs/om/wiki/Components,-Identity-&-Normalization).

If you run the last example without the om/add-root! call and you call (deref reconciler) you get the same value as init-data. Once you add the om/add-root! call the derefed value becomes a normalized view of the data. I don't understand if the reconciler is immutable? If so, how does the deref value change by calling om/add-root!?

@rgbboy: reconciler internally keeps an atom with a state in it, which can change

@jetmind: Ahhh ok. I am very new to all this. I just found out about the bang convention for functions that mutate.

@rgbboy: when you add-root! with a map as :state or an atom and set :normalization true, the reconciler will normalize the data

@anmonteiro: regarding the normalization

I can’t seem to reproduce what’s in the example — partial information with just the idents

@txus: sorry what are you referring to?

as in, having somewhere {:user/id 1 :user/name “bar”} and somewhere {:user/id 1}

I don’t think I understand how the reconciler finds out they are the same thing, because I have a defui User with an om/Ident of [:user/by-id (:id user)] but the reconciler doesn’t seem to pick it up

I’m wondering how would it know at all — through the tree of components, checking if any has an ident?

@txus: could you provide more context? I don't remember what you're talking about

hm, so, my real case: I have :app/users and :app/sections, which are lists. Then I have an :app/current-user and an :app/current-section, and they have respectively [:user/by-id :foo] and [:section/by-id :bar]. There exists a User component with an om/Ident and a Section component as well, and they are both rendered through a RootView (indirectly, through more components). Now, for some reason the :app/current-section gets normalized to :app/current-section [[:section/by-id nil] [:section/by-id nil]]

but the :app/current-user gets normalized correctly

do you have this code somewhere?

have you tried om/tree->db with your init-data and your root component to test normalization?

yeah, the value of :app/current-section is [[:section/by-id nil] [:section/by-id nil]] there already @anmonteiro

so I figured it’s normalization that goes wrong in the first place

I'd say if normalization goes wrong in the first place

your queries might be wrong

or it is a bug in Om (unlikely)

if you could post the component tree w/ respective queries somewhere

I could take a look

@txus: ^^

hmmm I found what was different

the root query queried for [:app/current-user {:app/current-section [:section/id :section/name]}]

but changing it to [:app/current-user :app/current-section] made it work uhm

@anmonteiro: I’m getting another no queries exist for etc… https://gist.github.com/txus/4b421085c2c922dbc687

that’s the component tree with their queries. I scoped everything to {:root because I thought that was the way to avoid this — making the extra step so that the RootView is actually scoped to :root

but I feel scoping everything is not really getting me anything, as I still seem to get wrong the query paths?

give me a moment

sure

right

so

I haven't tried it yet

but it seems that your queries don't match your data

so there could be something right there

hm in which way don’t they match? I can’t see it :S

(I think 99% of my problems is not really seeing when my queries match my data heh)

RootView is doing something odd

with the unquote splicing

wait, actually that's not wrong

it's just complected

what's wrong with [{:root ~(om/get-query UserProfilesView)}]

@txus: everything looks OK with queries & data for me

where are you getting this error?

I tried code from your gist and everything is ok:

(cljs.pprint/pprint (om/tree->db RootView init-data init-data))
{:root {:app/users [[:user/by-id :guest]]},
 :user/by-id {:guest {:user/name "guest", :user/id :guest}},
 :om.next/tables #{:user/by-id}}

@jetmind: you are aware that the 3rd arg to tree->db should be true or false right?

it's working for you because a map is truthy

yeah, the last param should be boolean

@anmonteiro: I used the unquote splicing because in practice there are more queries there so it’s easier to stack them

@anmonteiro: yeah, right, thanks for clarification. I guess I have confused what tree->db vs db->tree takes

@txus: so your problem might be right there

stealing queries again

can't be sure though

ag now I’m getting a problem in query_template. With this root query: [{:root [{:app/users [:user/id :user/name :user/authenticated]} :app/current-section]}]

does this look wrong?

@txus I do not recommend grabbing at straws with queries

you really should be able to test this stuff just by writing some parses

as in actually write some tests verifying the behavior of query

if these work then you can isolate the issue to something about your components

@dnolen: you’re right. I’ll start testing normalization and then build on that

nice podcast with @dnolen talking about Om.next http://blog.cognitect.com/cognicast/093, good one David

@wilkerlucio: thanks!

@wilkerlucio: thx for sharing

I’m having a bit of a problem with local state. I’m not sure I understand why a call to set-state! is failing and throwing the same error as above (`“No queries exist..”`)

Coming from vanilla React, I’m confused by how set-state! is supposed to work — I would have thought that it completely ignored the reconciler

(I guess it does — that’s probably part of my confusion)

@pletcher: that’s probably not a state problem

also Om set state has absolutely no connection to React facilities

other than we ride on the state map

I see — thanks

@pletcher: all API originated state transitions involve the reconciler in some way

set-state!, set-query!, transact!, merge!

Hmm, cool — I think I’m having to get rid of some of the assumptions that I brought in from React And (this is probably a dumb question) it’s taken as given that the component hierarchy mirrors the query hierarchy? i.e., there’s no more reaching into a flat(-ish) map from anywhere in the component tree — it’s all about passing parts of the query hierarchy down through components?

@pletcher: in Om Next components are dumb

they don’t do anything - no control logic at all

beyond the most simple reacting to user events

the app state is flat (via normalization or custom storage)

queries create the ui data tree which simply fed into dumb components

the whole thing is designed to be incremental

so we can run queries and recompute any subtree

so this erases any need to cache stuff yourself in the component tree with local state

cool — I think I’m starting to wrap my head around it — thanks!

Finally had a chance to figure out the problem I was having: I have a router that swaps in a different view in my Root component. When that component updates, it updates its query with the view’s query by calling om/set-query!, but Root’s static query stays the same — just [:view]. Pretty sure that’s the wrong way to go about it

@pletcher: my latest iteration was that as well, but called [:route]. The only downside to that I can see is that the client is refetching from the server on each view change and isn't specifying what fields it wants, but is just receiving what the server gives it. Now I'm doing something like [{:route {:index [:content ] :contact [:content] :etc [:content]}}] and then changing that in (defmethod read :route) to only send one of those to the server at a time. I'm unsure if this is much better, but at least the client is describing what it needs and the root query has the full map to start with.

Is the om.next TodoMVC Example https://github.com/swannodette/om-next-demo still the best place to look for example of om.next integration with Datomic?

@iwillig: it’s out of date but it does gives the basic idea yes

not sure when I’ll have any time to update it, too busy with other more pressing Om Next things now

sure

thanks

om.previous question: I’m rendering of set of ordered child components, and then I reorder them and that updates fine, but the state that I pass to them does not get updated, any ideas why that might be? I tried moving it from init-state to just state but still no luck. Looks like: https://gist.github.com/blissdev/218641072d7e915d1e3b

the :render-position does not seem to update upon re-render in the new order

if it helps i’m using set-state! to set the new element-sort

tried using get-render-state but I think I’m probably attacking the wrong problem

@blissdev: you must supply React ref correctly

@thosmos interesting — I might try something like what you’re doing now. Thanks for the tip!

@dnolen I’m not sure I understand, do you mean the react-key?

@blissdev: oops yeah React key

@dnolen Correctly? I thought it needed to be a unique string? Does it need to be globally unique? Something else?

I’ll reread the docs and see where I’m going wrong. Thanks for the pointer.