From 33f553da2ca9010b2a89e470fa278330f2698cc7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Paul=20O=E2=80=99Shannessy?= Date: Tue, 24 Feb 2015 12:48:57 -0800 Subject: [PATCH] 4d90b9bdf3fc4ccfd2ccbaf9a590b16f06746b55 and #3255 --- blog/2015/02/24/streamlining-react-elements.html | 4 ++-- blog/index.html | 4 ++-- feed.xml | 4 ++-- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/blog/2015/02/24/streamlining-react-elements.html b/blog/2015/02/24/streamlining-react-elements.html index 045a4d1404..a9605ad606 100644 --- a/blog/2015/02/24/streamlining-react-elements.html +++ b/blog/2015/02/24/streamlining-react-elements.html @@ -108,7 +108,7 @@

The problem is that we don’t have a convenient way to tell when you’re done mutating.

Problem: Mutating Props You Don’t Own #

-

If you mutate something, you destroy the original value. Therefore, there is nothing to diff against. Imaging something like this:

+

If you mutate something, you destroy the original value. Therefore, there is nothing to diff against. Imagine something like this:

var element = this.props.child;
 element.props.count = this.state.count;
 return element;
@@ -199,7 +199,7 @@
 
In 0.13 we introduced a new callback-refs API that doesn’t suffer from these problems but we’ll keep on a nice declarative alternative to the current semantics for refs. As always, we won’t deprecate something until we’re sure that you’ll have a nice upgrade path.

 
Keyed Objects as Maps #

 
In React 0.12, and earlier, you could use keyed objects to provide an external key to an element or a set. This pattern isn’t actually widely used. It shouldn’t be an issue for most of you.

-
<div></div>
+
<div>{ {a: <span />, b: <span />} }</div>
 
Problem: Relies on Enumeration Order #

 
The problem with this pattern is that it relies on enumeration order of objects. This is technically unspecified, even though implementations now agree to use insertion order. Except for the special case when numeric keys are used.

 
Problem: Using Objects as Maps is Bad #

diff --git a/blog/index.html b/blog/index.html
index e58f29e15b..31814ee014 100644
--- a/blog/index.html
+++ b/blog/index.html
@@ -108,7 +108,7 @@
 

 
The problem is that we don’t have a convenient way to tell when you’re done mutating.

 
Problem: Mutating Props You Don’t Own #

-
If you mutate something, you destroy the original value. Therefore, there is nothing to diff against. Imaging something like this:

+
If you mutate something, you destroy the original value. Therefore, there is nothing to diff against. Imagine something like this:

 
var element = this.props.child;
 element.props.count = this.state.count;
 return element;
@@ -199,7 +199,7 @@
 
In 0.13 we introduced a new callback-refs API that doesn’t suffer from these problems but we’ll keep on a nice declarative alternative to the current semantics for refs. As always, we won’t deprecate something until we’re sure that you’ll have a nice upgrade path.

 
Keyed Objects as Maps #

 
In React 0.12, and earlier, you could use keyed objects to provide an external key to an element or a set. This pattern isn’t actually widely used. It shouldn’t be an issue for most of you.

-
<div></div>
+
<div>{ {a: <span />, b: <span />} }</div>
 
Problem: Relies on Enumeration Order #

 
The problem with this pattern is that it relies on enumeration order of objects. This is technically unspecified, even though implementations now agree to use insertion order. Except for the special case when numeric keys are used.

 
Problem: Using Objects as Maps is Bad #

diff --git a/feed.xml b/feed.xml
index 8bcbe43a93..41bd8da31d 100644
--- a/feed.xml
+++ b/feed.xml
@@ -21,7 +21,7 @@
 </code></pre></div>
 <p>The problem is that we don’t have a convenient way to tell when you’re done mutating.</p>
 <h3><a class="anchor" name="problem-mutating-props-you-dont-own"></a>Problem: Mutating Props You Don’t Own <a class="hash-link" href="#problem-mutating-props-you-dont-own">#</a></h3>
-<p>If you mutate something, you destroy the original value. Therefore, there is nothing to diff against. Imaging something like this:</p>
+<p>If you mutate something, you destroy the original value. Therefore, there is nothing to diff against. Imagine something like this:</p>
 <div class="highlight"><pre><code class="language-js" data-lang="js"><span class="kd">var</span> <span class="nx">element</span> <span class="o">=</span> <span class="k">this</span><span class="p">.</span><span class="nx">props</span><span class="p">.</span><span class="nx">child</span><span class="p">;</span>
 <span class="nx">element</span><span class="p">.</span><span class="nx">props</span><span class="p">.</span><span class="nx">count</span> <span class="o">=</span> <span class="k">this</span><span class="p">.</span><span class="nx">state</span><span class="p">.</span><span class="nx">count</span><span class="p">;</span>
 <span class="k">return</span> <span class="nx">element</span><span class="p">;</span>
@@ -112,7 +112,7 @@
 <p>In 0.13 we introduced a new callback-refs API that doesn’t suffer from these problems but we’ll keep on a nice declarative alternative to the current semantics for refs. As always, we won’t deprecate something until we’re sure that you’ll have a nice upgrade path.</p>
 <h2><a class="anchor" name="keyed-objects-as-maps"></a>Keyed Objects as Maps <a class="hash-link" href="#keyed-objects-as-maps">#</a></h2>
 <p>In React 0.12, and earlier, you could use keyed objects to provide an external key to an element or a set. This pattern isn’t actually widely used. It shouldn’t be an issue for most of you.</p>
-<div class="highlight"><pre><code class="language-js" data-lang="js"><span class="o">&lt;</span><span class="nx">div</span><span class="o">&gt;&lt;</span><span class="err">/div&gt;</span>
+<div class="highlight"><pre><code class="language-js" data-lang="js"><span class="o">&lt;</span><span class="nx">div</span><span class="o">&gt;</span><span class="p">{</span> <span class="p">{</span><span class="nx">a</span><span class="o">:</span> <span class="o">&lt;</span><span class="nx">span</span> <span class="o">/&gt;</span><span class="p">,</span> <span class="nx">b</span><span class="o">:</span> <span class="o">&lt;</span><span class="nx">span</span> <span class="o">/&gt;</span><span class="p">}</span> <span class="p">}</span><span class="o">&lt;</span><span class="err">/div&gt;</span>
 </code></pre></div><h3><a class="anchor" name="problem-relies-on-enumeration-order"></a>Problem: Relies on Enumeration Order <a class="hash-link" href="#problem-relies-on-enumeration-order">#</a></h3>
 <p>The problem with this pattern is that it relies on enumeration order of objects. This is technically unspecified, even though implementations now agree to use insertion order. Except for the special case when numeric keys are used.</p>
 <h3><a class="anchor" name="problem-using-objects-as-maps-is-bad"></a>Problem: Using Objects as Maps is Bad <a class="hash-link" href="#problem-using-objects-as-maps-is-bad">#</a></h3>