Fork me on GitHub
#om
<
2016-07-30
>
peeja16:07:52

I think I'm missing something conceptual here: The initial query composes to the root, but that composition doesn't take query changes into effect. If a subcomponent changes its query, the root query becomes incorrect. I understand that Om still feeds that subcomponent params by reading its new query, but it does mean that the root is still reading data it doesn't need to read anymore. Is that not a problem?

peeja16:07:09

Doesn't that mean you're potentially asking the remote server for data you don't need?

dnolen16:07:53

@peeja: that’s not how it works anymore

dnolen16:07:59

the root has the updated query

peeja16:07:08

Oh, I'm behind then

peeja16:07:18

That's pretty sweet. How does it know?

dnolen16:07:27

we just propagate the changes now

peeja16:07:55

Ah, because the indexer can assign each component a place in the query?

anmonteiro16:07:33

@peeja: it only works for “single children"

peeja16:07:44

Meaning, not for collections?

anmonteiro16:07:45

you can’t expect to change the query of a single component in a list

peeja16:07:50

Yeah, that makes sense

anmonteiro16:07:10

@peeja: if you’re seeing that’s not the case, I’d love to see a minimal case

anmonteiro16:07:32

granted you’re on a Om version that supports that behavior

peeja16:07:34

No, I'm a few alphas behind and also only playing with the list case anyhow 🙂

peeja16:07:53

The list case is too bad, but I can't imagine a way around it

peeja16:07:40

I guess you'd just want to avoid doing things that cause the root to reread too often?

peeja16:07:06

Oh, or just stop hitting the remote for all that data once you have it

peeja16:07:14

That actually seems fine

anmonteiro16:07:24

the list case just isn’t supported because it doesn’t make sense

anmonteiro16:07:33

for a single component to have a query different that its siblings

anmonteiro16:07:39

just use a union query for that

peeja16:07:45

Oh, interesting

peeja16:07:18

It doesn't make sense because of the query syntax, but it totally makes sense as a use case, no?

peeja16:07:38

I have a list of people, each one shows basic info

peeja16:07:47

I can click a button to reveal more info about them

anmonteiro16:07:58

minimum version is alpha33

anmonteiro16:07:01

for that to work

anmonteiro16:07:32

@peeja: doesn’t make sense because of the query syntax, and one more thing

anmonteiro16:07:56

how could you have an updated view from the root in that case? which of the children’s queries would you choose to compose?

anmonteiro16:07:09

at least one of the children would always be reported wrongly

peeja16:07:25

Right, I understand that

peeja16:07:37

I just mean that it's a reasonable thing to want to do, even if it doesn't fit the query model

anmonteiro16:07:53

@peeja: I’m happy to answer your questions relating to this, I’ve done the work to support that and it was not trivial at all to reach an understanding (even in my head 🙂 )

peeja16:07:26

Is it possible to "convert" one of the items into a different branch of a union on the fly?

peeja16:07:42

Like, you click "show more details" and it starts being served by the "more details" branch

anmonteiro16:07:10

something like that, yeah

anmonteiro16:07:18

imagine you have posts and photos

anmonteiro16:07:38

suddenly a photo becomes a post (that shows a photo)

anmonteiro16:07:55

just change the field that the union query dispatches on

anmonteiro16:07:02

no need to mess with queries, just with your data

peeja16:07:28

Oh, yeah, I guess that would work

peeja17:07:19

So, that makes sense to me in that case, because the actual data has changed

peeja17:07:28

The post has become a photo

peeja17:07:42

But if you click "more info", you're just changing UI state.

peeja17:07:24

eg, you wouldn't transact that mutation to the server

peeja17:07:00

But I guess I'm just pushing further into a case that the query syntax has no way to represent

peeja17:07:17

(and which would be difficult-to-impossible to represent)

anmonteiro17:07:25

@peeja: hrm, would it really be that complicated? a transaction that changes the type, and marks that ident as “dirty"

anmonteiro17:07:45

the remote transaction (which is guaranteed to run after the local) would just need to check for dirty stuff and send them to the server?

peeja17:07:04

You don't want to expand "more info" in every browser window, or for every user

peeja17:07:18

You just want to open up some more info about a person on your screen

peeja17:07:26

You just want your app to read a little more info

peeja17:07:39

That shouldn't change the server's state

anmonteiro17:07:23

@peeja: I don’t mean changing the server’s state at all

anmonteiro17:07:34

just remote re-reading that piece of data which is now stale on your frontend

peeja17:07:14

Oh, I see what you're saying.

peeja17:07:52

I feel like the whole point is that a transaction shouldn't be necessary. I'd like to be able to change my query and therefore be fed the data I asked for

peeja17:07:59

And, to be fair, i can

anmonteiro17:07:19

I think we’re talking about the same thing, with different implementations

peeja17:07:36

I mean, even in this case, the root query isn't fetching data I don't need, it's just not fetching all the data I need.

peeja17:07:02

To put this another way: if the root query contains a join query for a collection, but the component rendering one of the items in that collection has changed its query, is that a problem?

peeja17:07:43

It means the root query will ask for data I may not need, and may not ask for all the data I need. But the list item component will also be reading its own query.

peeja17:07:51

So, will it break at some point?

anmonteiro17:07:52

@peeja: depends. the new query won’t be viewed from the top

anmonteiro17:07:04

that’s the only problem

peeja17:07:12

Right. When does that become an issue?

anmonteiro17:07:20

the parser will still dispatch on the updated query when you set-query!

peeja17:07:28

If I then set-query! on the root component to change something unrelated to the list, causing it to re-read and re-render, will it cause my list item to have incomplete data, because it's rendering only the data that the root query knows to ask for?

peeja17:07:45

Or will list item retain the data its query read?

anmonteiro17:07:39

@peeja: when you re-render from the top, that component will not have the updated query visible

peeja17:07:25

Meaning that when that component asks for stuff out of its params that only its updated query knows about, it'll find nil?

anmonteiro17:07:11

I’m not sure if that’s what it means

peeja17:07:19

Fair enough. 🙂

marcin.cylke20:07:44

Could you help me with my problem?

marcin.cylke20:07:00

I'm clueless about the reasons for that behavior

peeja20:07:21

@marcin.cylke: Does people return a vector of multiple people sucessfully?

peeja20:07:26

I'd start there

marcin.cylke21:07:37

hmm.. didn't think of that

marcin.cylke21:07:55

I'll check this - I've always search for the problem with om