This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-03-02
Channels
- # aws-lambda (1)
- # beginners (28)
- # boot (54)
- # cider (11)
- # clara (28)
- # cljs-dev (74)
- # cljsrn (13)
- # clojure (342)
- # clojure-austin (3)
- # clojure-dusseldorf (4)
- # clojure-france (2)
- # clojure-greece (11)
- # clojure-italy (42)
- # clojure-poland (7)
- # clojure-russia (11)
- # clojure-spec (44)
- # clojure-uk (156)
- # clojure-ukraine (4)
- # clojurescript (102)
- # cursive (17)
- # datascript (19)
- # datomic (17)
- # dirac (39)
- # emacs (22)
- # funcool (56)
- # hoplon (25)
- # jobs (3)
- # jobs-discuss (31)
- # leiningen (2)
- # luminus (4)
- # lumo (3)
- # off-topic (47)
- # om (51)
- # onyx (57)
- # re-frame (13)
- # reagent (57)
- # remote-jobs (15)
- # ring (9)
- # ring-swagger (7)
- # robots (2)
- # rum (6)
- # specter (16)
- # sql (7)
- # test-check (37)
- # untangled (7)
- # yada (5)
how do I fix:
Warning: Each child in an array or iterator should have a unique "key" prop.
?
that’s a React thing, not particularly related to Om
(dom/svg #js {}
(for [w windows]
(do
(. js/console log(:db/id w)) ;; this proves they're different
(gui/window (assoc w :key (:db/id w))))))
^^ I still get an error, yet I clearly have an unique key passed to gui/window
What is going on here?is gui/window
an Om Next component?
use :react-key
for those
I know it’s confusing, sorry..
@anmonteiro : that fixed it; thanks! there's no way I would have guessed / found that
static om/IQuery
(query [this] ...)
I've read through the OmNext wiki. I've done quite a few examples. This I still don't understand -- is the "..." query supposed to be
(1) constant OR
(2) can be dependent on [this] ?
The other confusion is that how is the "passed in (om/props this)" and "whatever the query returns" merged together?so computed is via om/get-computed, state is via om/get-state .... but whatever we get from querying -- is it just merged right in with (om/props this) ?
props are not magical
they’re whatever the parser returns
what are for you the “original props”?
Sy I have:
(defui Window ....
om/static IQuery
(query [_] ...)
(render [this]
... (om/props this) ... <-- what does this return )
)
(def window (om/factory Window))
... some other code ...
(window Y)
okay, so Y is being passed as to Window, accessible via (om/props this)
but then based on the query, we read data X, and X is also accessible via (om/props this)
so is X and Y just "merged" into a single map?the point that confuses me is (window ...) <-- the ... is pased as (om/props this) but (parser (query ...)) <-- this is also returned as (om/props this) so are the two just merged ?
@qqq that is not how it works
Root props are what the parser returns. They’re passed to your root component
it’s then your responsibility to tear apart those root props and pass whatever keys you want to the children of the root
as I said above, there’s no magic involved
1) child gui elements define om/IQuery 2) child gui elements do NOT make queries 3) root gui elements combine the om/IQuery of child gui elements 4) root gui element makes ONE QUERY total 5) root gui element gets result of query, accessible via (om/props this) 6) root gui element tears results apart, passes it to child via (child XYZ) the child, gets XYZ as (om/props this) is the above correct ?
if by “makes query” you mean a parser invocation, yes
@anmonteiro : thanks for clarifying this. I
I INCORRECTLY thought: each element makes its own query based on what om/IQuery returns TRUTH is: child defines om/IQuery only so PARENT knows that child needs
besides https://github.com/omcljs/om/wiki/DataScript-Integration-Tutorial is there more info on datascript/om next interaction? I'm particularly interested in the role of * query * set-query * ident given that datascript is doing all the indexing and has it's own query language
@matthavener filter mutates local state through om/set-state!' ? if it is, how can parser access a component local state in its
read` method?
@qqq but why?
I don't think you want two databases for that. Datascript gives you namespaced keywords... You probably can create an atom with two db connections in it or something, but I don't see any benefit
suppose I'm an idiot and only learn the hard way, and want to see what happens if I try 2 dbs
Is there not the same problem with a single datascript db?
I was thinking more about how om knows which components need to be re-rendered, unless you specify them as trailing keywords to transact.
Sure, it can know if something has changed..
What I mean to say is that I think you'll need to write a custom merge function anyway, that passes the query to merge! so the reconciler knows what components need re-rendering.
You could come up with your own merge function that worked on an atom with two dbs probably, but it still sounds like a terrible idea.
Ok, if you say so 😛