This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-05-03
Channels
- # admin-announcements (6)
- # beginners (73)
- # boot (84)
- # cider (9)
- # cljs-edn (5)
- # cljs-site (8)
- # cljsrn (2)
- # clojure (158)
- # clojure-austin (1)
- # clojure-canada (1)
- # clojure-dusseldorf (2)
- # clojure-ireland (1)
- # clojure-russia (45)
- # clojure-sg (2)
- # clojure-uk (28)
- # clojurebridge (2)
- # clojurescript (142)
- # core-async (43)
- # cursive (23)
- # datascript (5)
- # datomic (9)
- # dirac (4)
- # emacs (23)
- # funcool (1)
- # garden (1)
- # hoplon (280)
- # jobs (1)
- # ldnclj (6)
- # leiningen (37)
- # luminus (6)
- # om (30)
- # om-next (1)
- # onyx (6)
- # perun (24)
- # re-frame (10)
- # reagent (20)
- # remote-jobs (1)
- # rethinkdb (2)
- # ring-swagger (4)
- # rum (3)
- # spacemacs (6)
- # untangled (36)
- # yada (5)
if I call initLocalState
, the result has some container {:omcljs$state {:my-state :football}}
wrapped around it. i think this is preventing me from doing: (om/set-state! c (.initLocalState c))
<— this sets an invalid state
@devth: initLocalState
is not supposed to be called directly
@devth: make a function init-state
or w/e and call it both in initLocalState
and in the reset code
How do you best debug "Warning: Each child in an array or iterator should have a unique 'key' prop"?
I saw that warning first in reagent. It happened when I was displaying a collection and didn’t provide a unique identifying key
my naive way of solving that was to assoc an id
key with a unique value, there is probably a more idiomatic way of doing this
I've encountered it fairly frequently, and sometimes it is hard to figure out which element is causing the problem.
This happens to me all the time, I usually create fns
that receive collections and then use them like this: (defn [& children] (dom/div nil children))
@dnolen: looking at #679 https://github.com/omcljs/om/issues/679
this is a fun one, and not related to the dynamic queries patch
I don’t think we’ve ever tried to have joins in recursive queries
so a query like [{:tree [:id {:counter [:value]} {:children ...}]}]
breaks when we have paths such as [:tree :children :counter]
because we only index [:tree :children]
and [:tree :counter]
@anmonteiro: sorry is there a typo in your example? Where’s the join? i.e. map in map?
@dnolen: not sure if there’s a typo, the join in this case would be {:counter [:value]}
every other bit of code are the data paths
ah, np
@anmonteiro: ah, hmm, seems to me like that should just work - would need to take a look to understand why it doesn't
@dnolen: 2 problems
1. class-path uses take-while
2. the build-index
function stops at first recursion
so a class-path like Comp Child Child Counter
is actually computed as Comp Child
because of take-while
I’m looking into it if that’s OK, should make for a fun one
@stuartsierra : If you are iterating over a list and mapping a component to each value, use :keyfn id
in om.next/factory
. Example:
I'm using om.now. When I call build-all
I know to add a :key
. But sometimes the warning shows up in other places, for example if I am conditionally rendering some components.