Fork me on GitHub
#untangled
<
2016-04-26
>
currentoor05:04:43

Is anyone else seeing this warning when compiling with advanced optimizations on?

anmonteiro08:04:11

@currentoor: @tomjack FWIW those are not real warnings

anmonteiro09:04:52

The warnings shouldn't really be emitted, so your code will run just fine

currentoor21:04:16

But if I make Metric and Meta components with their own om.next/idents then I do have access to these fields in render.

currentoor21:04:05

So my question is, are nested queries without idents acceptable, maybe I'm doing something wrong? Or are om.next/idents necessary in a situation like this?

tony.kay22:04:34

So, db->tree should "just work" on queries even if the database value is nested...which is what fills out the result. Even if you use idents in the database to make a graph...the algorithm (as far as I remember) does not try to leverage the component metadata to figure the query out. I don't remember joins requiring an ident. The experiment is easy enough to verify.

ethangracer22:04:34

from what I can tell, you could query for [:db/id :row/metrics :row/meta] and it will work

ethangracer22:04:56

the data in row/metrics and row/meta will not be normalized, but it will show up

ethangracer22:04:19

when you specify a join, db->tree assumes an ident will be there

ethangracer22:04:22

or maybe untangled does

tony.kay22:04:30

not sure that is true

ethangracer22:04:30

not sure, but that’s been my experience

ethangracer22:04:40

it just eats it

tony.kay22:04:58

could be a bug. There is nothing that says a join has to cross an ident in the design of the default db format...but perhaps that changed

ethangracer22:04:50

yeah i’m not sure. the only way I can explain it to myself is that a join implies the keyword points to multiple things

ethangracer22:04:04

in which case, if you query for the keyword itself, who cares what the sub-keys are

ethangracer22:04:09

just give me what’s at that keyword

ethangracer22:04:05

although I guess you might only want one subkey, not all of them

ethangracer22:04:11

eh, i see it both ways

tony.kay22:04:49

right, the to-one case is detected by the data in situ...is it a vector? to-many

tony.kay22:04:57

is it a map? to-one

tony.kay22:04:39

I'm doing a quick experiment, then we can ask on #C06DT2YSY depending on the result

tony.kay22:04:03

hm...for a to-one case, it works for me

tony.kay22:04:15

(completely non-normalized db)

tony.kay22:04:54

ah....to-many does not see right

tony.kay22:04:16

actually, that is right...a list of items cannot possibly render correctly unless they have an ident

tony.kay22:04:03

therefore, there is never any need for db->tree to treat a vector in app state as anything other than a vector of idents. List of objects should always be normallized and have idents, or you cannot keep the list rendered correctly on updates.

tony.kay22:04:09

so, that is the overall answer. It should work on to-one relations without idents/normalization. But to-many cannot work correctly.

tony.kay22:04:57

I mean, technically you could make db->tree work without the ident, but for react and list-based reasons (path optimization, etc) you would never want to render a list that way

currentoor22:04:02

oh wow that was very thorough, thank you very much!

tony.kay22:04:11

welcome....made me think simple_smile

tony.kay22:04:35

If anyone cares, I noticed that the online version of the tutorial wasn't rendering the query editor correctly. I've fixed that.

tomjack23:04:45

Do you really always need idents for a list? Thinking of e.g. stuff analogous to card/many string

tomjack23:04:48

Sometimes I do (apply dom/div nil ...) if I don't care about fancy list stuff

tomjack23:04:05

Seems odd to me that you can't do similar things with "card/many map"

tony.kay23:04:28

in a list, technically you need a unique react key, which means you know a unique thing for each item. So, technically, no you don't need an ident; however, if you want path opt to work for items in your list you do, and since you already have a unique thing to make react work, why not code it?

tony.kay23:04:51

if they are just strings, then react isn't going to interact with them

tony.kay23:04:59

so in that sense, you're right

tony.kay23:04:29

There is nothing keeping you from putting a vector in your app state that contains sub-structure....e.g.:

tony.kay23:04:55

{ :a [ {:x 1} ] } and just doing this query: [:a] which will return a vector of maps...

tony.kay23:04:23

the point is if you put it in the query, then the join is implying UI structure

tony.kay23:04:21

@tomjack: honestly I can probably play devil's advocate and argue it either way. From a pure function/query syntax perspective: it is doable, so why not do it?

tony.kay23:04:14

I'd have to walk through other combos on the syntax...remembering that idents are vectors and lists are vectors...that could cause some complication...then there are unions and recursive queries.

tony.kay23:04:47

off the top of me head I see no technical reason for the restriction, just a good reason to tolerate it for components you define

tony.kay23:04:10

this is probably a better discussion on #C06DT2YSY