Fork me on GitHub
#om
<
2015-10-08
>
dnolen03:10:57

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

paulb05:10:55

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)

paulb05:10:36

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

danielgrosse06:10:45

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?

hmadelaine07:10:05

Hello @danielgrosse , you have to clone the Om repo

git clone 
and then install it locally :
lein install

danielgrosse09:10:51

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

hmadelaine09:10:11

@danielgrosse: you are welcome ! Enjoy the tutorial simple_smile

danielgrosse09:10:15

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

hmadelaine09:10:18

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

mcgivernsa09:10:13

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

hmadelaine09:10:12

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

resources/public/js

monjohn13:10:26

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

dnolen13:10:25

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

jannis13:10:31

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

jannis14:10:00

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

dnolen14:10:15

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

dnolen14:10:40

parent components invoke child component queries

dnolen14:10:01

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

dnolen14:10:19

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

jannis14:10:42

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?

jannis14:10:04

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

dnolen14:10:22

that’s a bad example because that is just gratuitous

dnolen14:10:29

the title component obviously doesn’t need a query

dnolen14:10:58

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

jannis14:10:22

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

dnolen14:10:32

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

dnolen14:10:58

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

dnolen14:10:12

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

jannis14:10:53

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?

spinningtopsofdoom14:10:29

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

spinningtopsofdoom14:10:35

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

spinningtopsofdoom14:10:16

an om component is not a react component

dnolen14:10:38

@jannis do not map UI concepts into the queries

jannis14:10:34

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

dnolen14:10:15

@jannis: @spinningtopsofdoom points are right on as well

dnolen14:10:31

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

dnolen14:10:55

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

dnolen14:10:23

then later MAYBE

dnolen14:10:28

but hopefully you can go back to NO

jannis14:10:38

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

dnolen14:10:05

sure but the question how much should spread that logic

dnolen14:10:13

header and menu are stateless

dnolen14:10:23

so that right there knocks them out of the running

jannis14:10:41

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.

dnolen14:10:32

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

jannis15:10:10

Oh, definitely 😉

jannis15:10:32

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

dnolen15:10:00

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