@paulb there’s no specific reason for that in the tutorial other than to show something less trivial

I mean to say I was expecting that to eval to {:app/counter {:db/id 1 :app/title "Foo" :app/count 1}} (vector becomes a map) but in fact it evals to {:app/counter [{:db/id 1 :app/title "Foo" :app/count 1}]} (vector stays and map goes inside of it)

now I see though, it's copying the pattern of Datomic Pull

Good Morning. As It tried the om-datascript demo, leiningen didn’t find the om 0.9.0 snapshot. How can I build this by myself an integrate it into the project?

Hello @danielgrosse , you have to clone the Om repo

git clone 

lein install

@hmadelaine: Thank you, that worked. :thumbsup:

@danielgrosse: you are welcome ! Enjoy the tutorial

Just did it.

After going into the namespace, om wasn’t available. Only after I pasted the whole code into the REPL. Is this normal?

Did you clean your project after installation of the new jar ?

do you mean that om wasn't defined in the repl when you pasted the snippets in there?

there is an issue filed for that https://github.com/omcljs/om/issues/391

When I install a new version of Om, I suppress the directory :

resources/public/js

@dnolen: Great tutorial! I really like how your break it down to the level of creating individual files. Makes it clear exactly where the action is happening, particularly between om and figwheel. I also missed that you need to clone and install om locally, so it might be helpful to put that at the top of the docs. Thanks for sharing all your great work!

@monjohn: that last bit will happen eventually - need to do some kind of release first

@dnolen: How does nesting om.next components work with regards to queries and props? I.e. are the parent and child components' queries totally independent? Do you have to pass (om/props this) down from the parent's render function to the child's factory?

I've looked at the todomvc example but I can't quite figure out how it's meant to be done right.

they are not totally independent, that’s not really possible

parent components invoke child component queries

parents don’t know what those subqueries will be precisely and they shouldn’t care

all this happens via static methods on startup, same as Relay

So if I have e.g. a Header component that has a Title child, the om/IQuery implementation of Header would have to include the query of the Title component?

And you have to always extract what the child component needs as props from (om/props this) in the parent and pass it down?

that’s a bad example because that is just gratuitous

the title component obviously doesn’t need a query

most components should be completely stateless - i.e. they don’t have queries (which are a stateful feature)

Hm hm, ok. I guess I'm not sure where to draw the line

@jannis don’t abuse queries, if a component does need a query don’t write one

generally a component should have a query only if it maps to some compound value - an entity that would reside in a service or in a DB

even if it’s local, the unit should be - “this is a model"

What if e.g. an App component has a Header component that has multiple Menu children, each rendering a list of links to objects in the DB? Which of these components would have queries?

@jannis: I think you're conflating components with UI elements. I'm viewing a component as where queries / state management takes place.

and inside the render method I create react elements / call functions which create react elements (passing in the state managed by the Om component)

an om component is not a react component

@jannis do not map UI concepts into the queries

Not sure I am. If a component needs to render a list of objects, I would have assumed that to correspond to a query for those objects. Anyway, I think I'll wait a bit to see an example that's more complex than the two-level todomvc app. It sounds like I just don't get queries yet. 😉

@jannis: @spinningtopsofdoom points are right on as well

@jannis: in your example Menu nor Header might need queries at all

the answer to the question - "does this need a query" should almost always be NO

then later MAYBE

but hopefully you can go back to NO

But the App component would need a query to extract objects from the application state to pass on to the header/menus, I assume?

sure but the question how much should spread that logic

header and menu are stateless

so that right there knocks them out of the running

That's my question exactly: how far (or not) to spread the query logic. I can see myself end up with a massive query for everything in the App component.

right, so will probably take some playing around with to build up an intuition for it

Oh, definitely 😉

@dnolen

Oops

Could it be that om/update-state! doesn't currently lead to a rerender?

very likely feel free to file an issue but please demonstrate that it can be done in a minimal way outside of whatever it is that you’re building

Sure