Fork me on GitHub
#om
<
2017-03-02
>
qqq01:03:18

how do I fix: Warning: Each child in an array or iterator should have a unique "key" prop. ?

anmonteiro01:03:54

that’s a React thing, not particularly related to Om

qqq01:03:53

(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?

anmonteiro01:03:38

is gui/window an Om Next component?

qqq01:03:08

(def window (om/factory Window)) (in the gui namespace)

anmonteiro01:03:15

use :react-key for those

anmonteiro01:03:38

I know it’s confusing, sorry..

qqq01:03:09

@anmonteiro : that fixed it; thanks! there's no way I would have guessed / found that

qqq01:03:19

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?

qqq01:03:58

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) ?

anmonteiro01:03:14

props are not magical

anmonteiro01:03:25

they’re whatever the parser returns

qqq01:03:50

yes, I understand the (defmulti read om/dispatch), (defmethod read ...)

qqq01:03:59

so say the parser returns X

qqq01:03:06

is this X merged together with the original (om/props this) ?

anmonteiro01:03:21

what are for you the “original props”?

qqq01:03:21

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?

qqq01:03:11

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 ?

anmonteiro01:03:56

@qqq that is not how it works

anmonteiro01:03:26

Root props are what the parser returns. They’re passed to your root component

anmonteiro01:03:46

it’s then your responsibility to tear apart those root props and pass whatever keys you want to the children of the root

anmonteiro01:03:55

as I said above, there’s no magic involved

qqq01:03:55

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 ?

anmonteiro01:03:56

if by “makes query” you mean a parser invocation, yes

qqq01:03:03

@anmonteiro : thanks for clarifying this. I

qqq01:03:39

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

qqq01:03:45

this makes so much more snese now

qqq03:03:35

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

mavbozo07:03:04

@matthavener filter mutates local state through om/set-state!' ? if it is, how can parser access a component local state in its read` method?

qqq07:03:59

when using Om with datascript, is it possible to have 2 datascript dbs?

qqq08:03:32

I want one for gui-db, and one for diagrams-db

qqq08:03:47

one is client local db info

qqq08:03:53

the other is stuff I want to serialize with the server

danielstockton08:03:31

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

qqq08:03:07

suppose I'm an idiot and only learn the hard way, and want to see what happens if I try 2 dbs

qqq08:03:21

if I do :state (atom {:gui-db .. :data-db ... }) I run into the following problem

qqq08:03:29

when I transact on gui-db, the state atom doesn't change, so there's no re-render

danielstockton08:03:02

Is there not the same problem with a single datascript db?

qqq08:03:40

no, because the db-conn is an atom

qqq08:03:46

so when it's derefered, it returns a different value

danielstockton08:03:33

I was thinking more about how om knows which components need to be re-rendered, unless you specify them as trailing keywords to transact.

danielstockton08:03:44

Sure, it can know if something has changed..

danielstockton08:03:05

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.

danielstockton08:03:29

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.

qqq08:03:54

just got it working by adding a counter to force the @state to update

qqq08:03:57

and it's a great idea

danielstockton08:03:43

Ok, if you say so 😛