This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-04-26
Channels
- # admin-announcements (4)
- # beginners (3)
- # boot (78)
- # cider (13)
- # cljs-dev (29)
- # cljs-edn (8)
- # cljsjs (11)
- # cljsrn (15)
- # clojure (81)
- # clojure-beijing (2)
- # clojure-belgium (3)
- # clojure-canada (1)
- # clojure-dusseldorf (8)
- # clojure-greece (6)
- # clojure-russia (40)
- # clojure-sg (1)
- # clojure-uk (59)
- # clojurebridge (1)
- # clojurescript (101)
- # core-logic (1)
- # cursive (3)
- # data-science (1)
- # datomic (60)
- # emacs (4)
- # error-message-catalog (12)
- # funcool (1)
- # hoplon (60)
- # jobs (1)
- # jobs-discuss (40)
- # leiningen (5)
- # liberator (1)
- # mount (22)
- # off-topic (8)
- # om (16)
- # onyx (53)
- # re-frame (11)
- # reagent (2)
- # specter (4)
- # testing (18)
- # untangled (51)
Is anyone else seeing this warning when compiling with advanced optimizations on?
@currentoor: @tomjack FWIW those are not real warnings
It's a CLJS bug http://dev.clojure.org/jira/browse/CLJS-1607
The warnings shouldn't really be emitted, so your code will run just fine
@anmonteiro: thanks!
But if I make Metric
and Meta
components with their own om.next/idents then I do have access to these fields in render.
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?
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.
from what I can tell, you could query for [:db/id :row/metrics :row/meta]
and it will work
the data in row/metrics
and row/meta
will not be normalized, but it will show up
when you specify a join, db->tree assumes an ident will be there
or maybe untangled does
not sure, but that’s been my experience
it just eats it
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
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
in which case, if you query for the keyword itself, who cares what the sub-keys are
just give me what’s at that keyword
although I guess you might only want one subkey, not all of them
eh, i see it both ways
actually, that is right...a list of items cannot possibly render correctly unless they have an ident
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.
so, that is the overall answer. It should work on to-one relations without idents/normalization. But to-many cannot work correctly.
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
oh wow that was very thorough, thank you very much!
If anyone cares, I noticed that the online version of the tutorial wasn't rendering the query editor correctly. I've fixed that.
Do you really always need idents for a list? Thinking of e.g. stuff analogous to card/many string
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?
There is nothing keeping you from putting a vector in your app state that contains sub-structure....e.g.:
{ :a [ {:x 1} ] }
and just doing this query: [:a]
which will return a vector of maps...
@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?
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.