Fork me on GitHub
#om
<
2015-11-17
>
tavistock03:11:34

is it always going to be called om.next?

thosmos06:11:17

I'm getting this error when I compile with optimizations advanced. I've been compiling with advanced for a while, so I'm wondering if there's a gotcha I'm missing? Uncaught #error {:message "No queries exist for component path (#object[jz \"function jz(){React.Component.apply(this,arguments);this.state=null!= this}\"])", :data {:type :om.next/no-queries}}

noonian06:11:28

I got that error (non minified) when I transacted in a component where in the query tree it has an ancestor component but in the render tree I short-circuit one of the components by pulling the data out myself and passing to its child. I’m not sure if that is a possibility in your app.

thosmos06:11:06

hmm, I don't exactly follow your use case. it works fine with simple optimizations

thosmos06:11:01

do you mean the comp that transacted was handed its props?

noonian06:11:12

I’m going build with optimizations and make sure my app still works

thosmos06:11:38

so its query had no read parser associated with it?

noonian06:11:23

I mean if you got the root query of my app, one of the queries in there came from component X with subcomponent Y, but in my render implementations, I never render X, I just pull out the data correctly to render Y so that Y gets the correct data. If you do that and then try to transact from Y you will get the no queries error.

noonian06:11:09

Yeah, so don’t do that heh

noonian06:11:34

It all worked until I added a transaction in Y though so I didn’t notice the bug for a while.

thosmos06:11:51

hmm, what I am doing is building on https://github.com/jdubie/om-next-router-example and added query params to the page query. I call (set-query! ...) just before doing the (transact! [(route-update ...)]) But all of that happens in the query and render root component

thosmos06:11:54

maybe I'll try a minimal mod to that example to capture the idea and see how it works

noonian06:11:09

Well, you also get that error anytime you transact from a component without a query. So the menu-entry from that example for instance.

noonian06:11:42

but I would hope/expect that the pages in there could transacted upon

thosmos06:11:06

but if the root component passes a callback to a query-free component, it can call that function which will trigger the transact that's closed over the root's "this", right?

noonian06:11:32

I would expect that you can also have components with queries as children of queryless components but I haven’t tried that.

thosmos06:11:23

hmm, actually it seems to be happening in the (set-query! this {:params ...}) that's called in the callback

noonian07:11:11

Huh, I think it’s a bug in Om. I just compiled my app with advance optimizations and one of my transactions that works with optimizations :none also throws that error.

grav12:11:32

How does Om handle {:key ?

grav12:11:18

I just wrote some Reagent, and there I have to specify the key explicitly, which makes good sense, since it’s a way for React to know which DOM nodes to mess with when a collection of components is updated.

grav12:11:38

So it seems magical that I never had to specify keys with Om

anmonteiro12:11:04

do you mean React child keys?

anmonteiro12:11:18

look into factory

anmonteiro12:11:46

it supports a :keyfn to use for the react key

grav12:11:18

Ah, I see

grav12:11:05

Do you know what it does when no :keyfn is specified?

grav12:11:21

Maybe there’s something I’m missing, but React cannot know if a piece of data that had index k in one render cycle now has index k+a in the next render cycle. How can Om know this?

jannis12:11:43

It can't, that's what :keyfn or the :react-key prop is for.

grav12:11:54

Okay, but compared to React, Om doesn’t warn if there’s no :keyfn or :react-key specified? That seems like a defect?

grav13:11:19

As I understand it, it has performance implications, if there’s no :key specified.

jannis13:11:30

It falls back to generating the key from :om-path which is more or less like indexes but I could be wrong.

jannis13:11:41

Well, it's fine unless you have a flexible number of children, I think.

grav13:11:09

Yes, exactly. React chooses not to use a fallback mechanism. I guess it’s just one of those places where Om is opinionated.

tony.kay16:11:55

@joshfrench: Mutation...I was wrong on the shrugged thing

tony.kay16:11:18

the action is needed on server, too, since parser might run more than once...needs to be side-effect free

joshfrench16:11:03

i haven’t worked with datomic much but in that case i don’t see how you’d be able to refer back to the transaction from outside of that fn

tony.kay16:11:51

@joshfrench: I agree. I'm at the conj. I'll ask David about it.

tony.kay16:11:15

seems like action's return value needs to be value

tony.kay16:11:53

He gave a great talk (for me at least)...very rapid, but covered a lot of bits and fleshed out the story nicely if you watch it in slo-mo

anmonteiro16:11:08

The video is still being processed, but here's the link for @dnolen 's talk: https://www.youtube.com/watch?v=MDZpSIngwm4

joshfrench16:11:12

re: that tempid migration problem i had yesterday, i’m pretty sure it has to do with unions. a simple example works fine, but when i throw unions into the mix i get that behavior where it nukes my app state. i think the telling clue is that when i make a mistake in the simple non-union version, it simply fails to migrate the IDs; it doesn’t blow away my data. https://gist.github.com/joshfrench/3c83bc0f40348dfd528b

jannis16:11:32

@joshfrench: Ah! I never tested tempid migraiton and unions, I guess it's quite possible that they break migrate.

joshfrench16:11:02

i’ve found other bugs with unions, so very well could be. filed an issue for it.

joshfrench17:11:52

but thanks for your examples @jannis, they were very helpful in verifying that my transactions were all in the right shape

tony.kay18:11:07

@jannis: @joshfrench Hey, on the action/tempid/Datomic thing. Just talked to David. It is a TODO to allow collection of return values from actions as part of parse, so that you can post-act on it before sending a response to the client

tony.kay18:11:28

so, workarounds/hacks are the only way to do it at the moment, but it is intended to eventually go in action

dnolen18:11:32

@joshfrench: probably just a bug, will need to look into that

tomayerst18:11:33

the querey example in the repl starts (in-ns 'om.tutorial.core) when I think it should say (in-ns 'om-tutorial.core)

tomayerst18:11:09

(at least that's what made it work for me)

dnolen18:11:01

@jannis fixed in master, the compute-react-key bug

joshfrench18:11:26

@tony.kay: thanks for clarifying!

jannis18:11:51

Are you guys having fun at conj?

dnolen18:11:59

good times!

dnolen18:11:06

heading back now simple_smile

tavistock22:11:18

i am working on some docs pages that are just a wrapper around your wiki, because I saw there was an open issue about it. is there a om logo. I am just going to use blue and green like clj/cljs logos.

tony.kay23:11:54

FYI: My Om Next Overview has been updated to include recent changes in naming. I'm working on the some docs for Mutation and Remotes next...coming soon.

chris-andrews23:11:57

@tony.kay: Your overview has been really helpful–thanks for putting that together

tony.kay23:11:17

welcome...more coming soon now that things are stabilizing