@ag I think I am struggling with the same issue. First, I have :route/data for my Root component, that then based on active route parser the corresponding components’ query. But I never get my data normalised. Just today I realised that my component needs to be at the top level in the graph, I can’t have it nested deeper. I would appreciate someone more experienced to write a short blog on when it’s expected to have normalized / non-normalized data.

Can anyone share how they handle a 'detail view' (/users/123) i.e. get the route-params from the app-state and somehow pass that to the component query? I'm using compassus and pulling :route/params out of app-state in my Wrapper component, but i'm not sure how to pass it through to the view component query.

Anyone can suggest why this

Uncaught Error: Union components must implement Ident

@alex-glv did you recently implement a union query somewhere (probably a component that displays heterogenous types.

They need an ident or the components don't know what to pull out of the list

Ah cheers @danielstockton , I added :normalize true, now need an ident as per tutorial

that's strange. I have a component which have union query and its child component don't have Ident

and I never see that error

@mavbozo maybe you don’t have

:normalize true

well, I don't have :normalize true in my reconciler options

if you're doing normalization yourself, it leaves it up to you whether you use the ident or do it some other way

@danielstockton Ah I see, so, if the query of a component is of sort {:some/key […]} then that component should implement ident? And you’re correct, I was doing the normalization myself until I decided to see what happens when I don’t.

yep, if using the default normalization

@danielstockton I have a bidi route mapped to : which sets params. I have a component which compassus mounts when : is the route. That component PostShow has a query: [{:post/show [:post/title ...]}] and a read method which looks something like: {:value (om/db->tree query [:post/by-id (get-in state [:params :id])])}

I think that would translate to your user show scenario

thats the part i was missing, the read method

everything else is the same, thanks

ok I missed the extra state at the end of db->tree

but it should work for you

i suppose this means that you load all the posts in advance?

but i can change my read method to load them on demand

Yeah the index view is the posts list. But I guess you could have a remote on :user/show

@dnolen @anmonteiro Would you be interested in relaxing the language spec for parameter maps or perhaps even developing it further? In a product I’m working on, we’ve adopted the Om Next query language in other parts of the system, as well and have found two extensions of parameter maps extremely useful: 1. Use variable paths (e.g. [?user ?db/id] in ({:user [:user/name]} {:db/id [?user ?db/id]})) to bind to values deep inside the params (in this case they could be {:user {:db/id <id>}}). 2. Use parameter paths (e.g. [:user/account :db/id] in ({:users [:user/name]} {[:user/account :db/id] ?account-id}) to express such things as “query only the users who belong to the account with ID <id>. 1 is something Om Next would have to do when binding params. I could provide an implementation for this — if you’re interested. 2 is something that’s really up to read implementations. It could be supported without any extra effort in Om Next by relaxing ParamMapExpr := EdnMap(Keyword, EdnValue), replacing Keyword with something more flexible. I checked the code and nothing seems to be enforcing parameter names to be keywords at the moment anyway. Would you be up for relaxing this?

@jannis that’s interesting but need to think about that one

Sure. I’m happy to discuss improvements or problems of the idea whenever you want. 🙂

I have a weird issue with om.next and klipse

klispse uses om.next

Now, when I’m evaluating code - inside klipse - that loads react, it seems that om.next remounts everything

Have a look here: https://goo.gl/NGAh4Z

You see the container on the left is updated by the code on the left

But then when react is loaded, the component is remounted and goes back to its insitial state

I have tried to make shouldComponent => false but it didn’t help

With the debugger and a few printings to the console, I have discover that componentDidMount was called again after react is loaded

Any idea?

That link just has a HelloWorld in blue. Is it the right one?

Oh! On my computer it is blue for a short time and then back to the original state

Click on the link. I think its missing code

@viebel I get your behavior too

I'm not sure this is a Om Next issue

hrm.. you might have to keep track of which libraries are already loaded in the environment

React wants to control the DOM, and you're changing it yourself

but then you require React again, and it takes control over the DOM again

what I would try to do is ignore the (require 'cljsjs.react) call, because your environment has already loaded it

@anmonteiro I was also thinking of preventing react from being load twice - this will probably solve the issue

@viebel right, not only React, but every foreign library that Klipse has already loaded to its environment

Im already doing it. But not with cljsjs packages yet..

Thx for your tip @anmonteiro. Now it works fine

You can even run om.next code inside klipse (that is built with om.next). Live demo: http://app.klipse.tech/?container&cljs_in.gist=viebel/69a7c0cdf289bad342fefe82fdeb7179