What’s the deal with animation? Is it a react concern; something we handle via lifecycle hooks?

react-motion is pretty awesome and works well with om next

https://github.com/chenglou/react-motion

I recommend watching the video on that site

Clearly, this doesn't handle all animation concerns, but it handles about 80% of them, and does so in a way that is declarative and doesn't muck up your components/state/etc

@anmonteiro: hi! one question, how do you develop/test/play with om.next, do you do changes in a project and lein install and use the snapshot?

http://stackoverflow.com/questions/34477057/including-om-next-source

@marianoguerra: ^^

@cjmurphy: thanks!, the thing is that I'm trying to get tempid migration to work on an example I'm building, so I would like to add some debugging to the om.next side to know what expects

this means I need to change it and the changes be reflected in my project

the only thing I can think right now is to do the change, lein install, and restart figwheel, but that's slow 😕

I may just do the actual question: what is the format of the response from the remote so that the tempids parameter on migrate has the mappings I'm returning

That's probably what I would be doing if needed to. No too slow is it??

I tried :value {:tempids {...}} :value {...} {:db/id {...}}

No idea on remotes from me sorry 😞

https://github.com/awkay/om-tutorial/blob/master/src/main/om_tutorial/simulated_server.cljs deals with tempids, might be worth a look

@danielstockton: I started there and I'm using the code in code.cljs but in the simulated server he seems to return {:tempids {...}} which doesn't work for me

Whatever you return from :action will be under a :result key in the response, I think.

@marianoguerra: you should return the tempids in :value {:tempids {}}

if that's in a mutate the frontend will see something like {:tudu.item/create {:tempids []}} right?

shouldn't it be a map and not a vector?

A map, yes

edited

I wasn't recompiling between stop/start 😕

tempid migration working on tudu example

https://github.com/marianoguerra-atik/tudu-v1/commit/cfd75b4584ae52c8c3e610d8032a4df6710406e0

@drcode: awesome, thanks

Why, in the Normalization tutorial must you normalise from the RootView? Why can't you normalise using the Person component - it's the one with the actual Ident?

@bones: the RootView-component is rigged to the reconciler. The reconciler checks the query of the component you add trough add-root

Keep in mind Person is a strange query

the query only asks for some properties

bones: are you trying to see the normalization through om/tree->db ?

it does make more sense of asking for those properties in the context of a list

But if I'm just doing om/tree->db to see what normalisation looks like, why do I need anything but the component with the Ident?

@seanirby: yip, that's the one

@bones: RootView just adds :list/one to the query

normalization doesn't make much sense without some sort of list

think about it

if you look at Person, those are just properties

'[:name :points :age]

If I understand correctly if you pass the Person query to tree->db then it will look at persons query against the data you give it, that doesn't make sense because Person doesn't query anything in the top level of that data, RootView does

indeed

*if you pass the Person component

only the top level keys get interpreted by your parser

that was what i meant, you give queries to db->tree

in this case this is :list/one and :list/two

Oh, so tree->db uses the parser somehow when normalising?

I was thinking it would just grab whatever Ident was on an component you fed it and normalise the data like that

But looking at it now, it RootView doesn't have an Ident so it can't have worked that way

@bones: the reconciler knows RootView has a path to Person, internally it knows when resolving that path it needs to keep the ident of Person in mind

think in terms of links

(om/get-query) links your components

Yip, the RootView uses Person to construct it's query

When you change the app-state with set-query, are these stored in some other part of the reconciler to what you pass in as app-state?

bones: i recommend checking out "awkway"'s tutorials on github. I think they're much clearer

*awkay

jeeze i can't type tonight

@seanirby: I flipping between awakes and the normalisation one

bones: nice

@seanirby @iwankaramazow thanks for your help - just going through the source for tree->db

: )

bones: NP. Glad I could help

indeed NP 😄

@anmonteiro I would like your feedback before proposing a change to om, it's a small optimization, here: https://github.com/omcljs/om/blob/master/src/main/om/next.cljs#L1488

I would like to add a check, if (empty? tempids) then skip the migrate call

for example, with the code here: https://github.com/awkay/om-tutorial/blob/master/src/main/om_tutorial/core.cljs#L36

it would save a walk through the whole state when there are no tempids to replace

@marianoguerra: I think that's a concern of the migrate function that people implement

Om's default migrate does it: https://github.com/omcljs/om/blob/master/src/main/om/next.cljs#L1685

yes, I was thinking that option too

ok, added to the todo example

I have a simple ident query and receive {[:login/show :main] :login} as props, however once it re-renders I receive it in the form of {:login/show {:main :login}} messing up my render function. Any ideas?

@rauh: https://github.com/omcljs/om/blob/master/src/main/om/next/impl/parser.cljc#L20 - sounds like what you want may be {[:login/show :main] [:login]} (assuming you want the :login prop of the data that [:login/show :main] refers to)?

Oh, sorry {[:login/show :main] :login} is not the query.

Ignore what I wrote then.

My query is [[:login/show :main]], an ident

Yeah, that makes sense. Sounds like a bug.

I'll try to make a minimal example

Random question: does a call to (om.next/class->any reconciler SomeClass) generate a n anonymous instance of a component SomeClass on the fly, or does it return an actual, matching instance in your application?

Guys how to create ui tree on om.next, example: 1. remote read method for :xyz returned list - is 1 lvl from ui tree 2. click on tree node call remote read method for :xyz/item by unique key returned 2 lvl from ui tree ?

@george.w.singer: matching instance

Thanks!

@dnolen: I've given a bit more thought to the query/"routing" stuff in conjunction with @tony.kay and, without writing any code, here's what I've drafted as something that could work: Restricting set-query! to the following: 1) only allow setting an instance query if - a) the instance has a ref (so that it can be used with subquery later) - b) there's only one instance of this class in its data-path (which I believe is preferrable over classpath) - c) if none of the above, we interpret it as setting the class's query (the case where we want to change the query of all posts - leaves of the UI tree - in a dashboard) 2) Modify get-query to work with the new semantics of set-query when working with instances 3) build-index will be fixed for free because it just uses get-query on the root 4) full-query also fixed for free because it uses the indexes

@anmonteiro: sounds interesting, can you please make a Om wiki idea page summarizing these thoughts, I can weigh in on it later today

@dnolen: definitely

thanks much

@dnolen: put it under "Om Next Design", here's the permalink: https://github.com/omcljs/om/wiki/Transitioning-the-Indexer-from-the-static-tree-to-the-runtime-tree

@anmonteiro: great thanks

where does the reconciler store state like query params?

@danielstockton: app state

what if i use datascript? does it know how to store it?

i presume not, in which case, are there some hooks for that?

no idea

Don't think there are any hooks

i probably have to work this out in my merge function right?

It's a good time to bring up these things regarding queries though

havent worked with many queries until now and just had this thought when reading they change the app state

do you know where in the code this gets handled for the usual atom-based app-state?

Params are only stored in app-state when you changed them at runtim

runtime*

i guess its this bit https://github.com/omcljs/om/blob/master/src/main/om/next.cljs#L694

if you set normal query params they'll be stored in the class

I'm assuming you knew this, but just for completion

yes, that bit

ok, thanks

yeah, i assumed it was only when calling set-query

@marianoguerra: glad to see you got the tempid stuff figured out for tudu . I've tried it out and can confirm that the errors I saw yesterday are no longer there.

This whole editing messages thing in slack still amazes me.

@anmonteiro: This looks like the other place it boils down to. I guess we'd need a more generic way of reading/writing the query

:save-queries and :load-queries on the reconciler perhaps?

which other place?

Oh, sorry https://github.com/omcljs/om/blob/master/src/main/om/next.cljs#L257

right, yes

I could perhaps work on a PR for this, if it seems like a sensible thing? @dnolen?

I'd be more inclined to a protocol just like ILocalState

it's ultimately David's decision though

@danielstockton: this is not something I’m interested in yet

Ok, I'll wait till the other work on queries settles a bit

@danielstockton: seems like a sensible decision to me. These things around set & get query might change in the near future

a protocol might actually not make sense because you'd need to implement it in every component, thought macros could take care of that. Just thinking out loud

I thought it was similar to some other hooks that are stored on the reconciler. If om philosophy is to put everything in a single state store, doesn't seem useful to be able to define it per component. But might be wrong?

no you might be right

@dnolen: I opened a PR yesterday to revert my buggy change, in case you haven't seen it. not sure how many people work off of master, but if many do might be good to merge it

@jlongster: thanks for fixing that and the bump - merged

np. will think about it more at some point but my queries are running fast enough for now

Let's say I have a Parent component and a Child component, and Parent's query is [:someread {:parent (om/get-query Child)}], when my app state updates, and it's relevant to the child but not the parent, does the reconciler rerun the read with the query defined by the parent, or just the Child components query?

@futuro: you transact on a component, which will re-render that component and any other reads you pass at the end of a transaction

so it depends on the component you transact and the keys you pass to be re-read (om can't work out exactly what you need to re-read, this can be different for each mutation)

https://github.com/omcljs/om/wiki/Documentation-%28om.next%29#transact shows how you might pass keys that need to be read

@danielstockton: oh, cool

thank you

@dnolen: FWIW, I have an initial version of what's detailed in the design document working that seems to be solving the issue

sweet!

i.e. child components correctly indexed when changing a child query

pretty exciting

though there's the need to store queries in the component class, which I'm not sure you're going to be a fan of

because we don't have the reconciler available when getting an updated query for the class

@anmonteiro: seems like there would be a way to thread that through

@dnolen: I don't know what you mean by that

@anmonteiro: isn’t there some solution that permits the reconciler being available?

or indexer

@dnolen: could we store the reconciler in the component class? I'm also thinking that's not a good thing

not suggesting that, haven’t seen any code yet so I’m talking without any real knowledge about your approach

I understand

but I would avoid storing anything on the class if possible

I imagined that would be the case

it’s just a modularity problem

i.e. multiple reconcilers stuff like that

makes sense

the reason why I chose to store the query in the class is because we allow queries to change in a class-wise fashion

i.e. what I exposed to you yesterday ("should we allow all the posts in a Dashboard to change their query?")

if we omit this requirement we just don't need to do it at all

I understand the rationale, just saying don’t use the class itself as the index

make data structure for that and put it somewhere

somewhere being?

ideally the indexer

since it’s already managing similar relationships

my problem is that we don't have access to the reconciler.. or the indexer

right but I don’t understand how that is possible

because as we (get-query Class) from the root

we need to see the updated stuff

there’s nothing async here, you can always opt to use dynamic binding

currently there's a binding being set up in the render method

for *reconciler*

But I don't think that's available

hrm..

right but why can't you set this up yourself for where you need it is all I’m saying

That's good feedback, I'll circle back and try to incorporate it

thanks!

I'm thinking that we could probably set the binding in set-query!

@dnolen: I might still be making wrong assumptions about this problem which is complecting the solution. The fundamental question that I have now is: Should we see the runtime query structure when we (get-query RootClass), or only when we (get-query RootInstance)? I think I keep trying to support both and this will eventually lead me nowhere

although even when we get-query of the root instance, it will still have calls to get-query of classes inside, which I think obviates the need to support both

@anmonteiro: ah no you want need to be able switch to the right thing

(get-query X) where X is a variable thing somehow

that's where I'm currently blocked

which might lead me to tinker with the query manager thing again