Mi about sablono HOT 6 CLOSED

I'm not sure what the problem is here. The code snippet above
doesn't generate a warning for me, even if I remove all :key
attributes. You certainly don't have to litter :key
and :react-key attributes everywhere. Have you read:

http://facebook.github.io/react/docs/multiple-components.html#dynamic-children

from sablono.

As far as I know, you only need a key with on/build. React doesn't optimize
the internal structure of an component.
Am 02.03.2014 03:57 schrieb "Sean Grove" [email protected]:

Something about the way Sablono is rendering makes it extremely difficult
know when a key is required or not to avoid the warning: Each child in an
array should have a unique "key" prop. Check the render method of undefined.,
and of course the massive performance penalty that goes along with it.

For example, in the following:

[:li.file_item {:key (:src media)}
[:a
{:key "a" ;; If this key isn't here, we get the warning
:href "#"
:on-click (constantly false)
:target "_blank"}
[:img {:key "img" :src (str "/assets/images/" (get icon-map extension "file") "_icon.png")}]
[:span {:key "span"} (:name media)]]]

The [:a] tag has no siblings, but React is seeing the children of [:li] as
an array with one element:

[image: d6]https://f.cloud.github.com/assets/35296/2303355/3c739956-a1b6-11e3-9aa0-f96385a09211.png

The current solution is to litter :key and :react-key entries everywhere
(on sablono-tags and om-components, respectively) in a
very-difficult-to-track-down way. Not 100% sure of the causes yet.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/18
.

from sablono.

Sean and I were talking about this earlier and I hacked together a bare-bones example that seems to display the problem:

(ns test.core
  (:require-macros
   [dommy.macros :refer [node sel sel1]])
  (:require
   [dommy.utils :as utils]
   [dommy.core :as dommy :refer [attr]]
   [om.core :as om :include-macros true]
   [om.dom :as omd :include-macros true]
   [sablono.core :as html :refer [html] :include-macros true]))

(enable-console-print!)

(defn inner-component
  [{val :val} owner]
  (om/component
   (html
    [:li val])))

(defn main-sablono
  [{:keys [some-coll]} owner]
  (om/component
   (html
    [:div
     [:ul.build-one
      (om/build inner-component (first some-coll))]
     [:ul.no-key
      (om/build-all inner-component some-coll)]
     [:ul.unique-key
      (om/build-all inner-component some-coll {:key :id})]])))

(defn main-plain
  [{:keys [some-coll]} owner]
  (om/component
   (omd/div
    nil
    (omd/ul nil (om/build inner-component (first some-coll)))
    (apply
     omd/ul nil
     (om/build-all inner-component some-coll))
    (apply
     omd/ul nil
     (om/build-all inner-component some-coll {:key :id})))))

(def my-data (atom {:some-coll [{:id 1 :val "foo"}
                                {:id 2 :val "bar"}]}))

(defn load!
  []
  (let [root-el (sel1 :#root)]
    ;; (om/root main-plain my-data {:target root-el})))
    (om/root main-sablono my-data {:target root-el})))

(set! (.-onload js/window) load!)

If I run the example with the main-sablono component, I see this warning:

Each child in an array should have a unique "key" prop. Check the render method of undefined. See http://fb.me/react-warning-keys for more information. 

If I comment out these lines from the main-sablono component (that is, the center ul):

[:ul.no-key
    (om/build-all inner-component some-coll)]

...the warning goes away.

If I use the main-plain component instead of main-sablono, the warning does not show up.

The dependencies in project.clj are:

  :dependencies [[org.clojure/clojure "1.5.1"]
                 [org.clojure/clojurescript "0.0-2173"]
                 [om "0.5.0"]
                 [prismatic/dommy "0.1.2"]
                 [sablono "0.2.6" :exclusions [org.clojure/clojurescript]]]

  :plugins [[lein-cljsbuild "1.0.2"]]

From reading the React docs and Om source-code, it seems like build never tries to pass in a key if the m options map is nil. However, if build gets passed an options map, it will attempt to set the :key value from the options map.

It seems to me actually that Om's default dom helpers would display the same issue that Sean found, but apparently that's not the case. This is as far as I've gotten debugging the issue, but I'll take another look tomorrow when I have time. In the meantime hopefully this helps someone else figure out what is going on...

from sablono.

Can we close this? Is this a problem with sablono?

from sablono.

Closing this now ...

from sablono.

Yeah, leaving it up to sgrove if he wants to try digging deeper on this...I'm happy to help if so.

from sablono.