title: Is it ok to return an empty object in React when calling setState() to mutate a collection?
body: <h1>Background</h1>
  
  <p>I've been playing around with React and made a simple todo list app to explore some concepts. While testing my code, I realized that returning a new state from <code>setState()</code> doesn't seem to be necessary when mutating/updating a state stored collection. </p>
  
  <p>According to several other StackOverflow questions and the React documentation, the code I wrote should either not work, or produce unexpected results. However, in all of my testing, the code does seem to work and is more readable and concise than the suggested methods for mutating collections. </p>
  
  <p>Why does my code work, and what, if any, is the danger of using it as a pattern?</p>
  
  <p>I've created two versions of my app. One which uses a method for updating collections as mentioned <a href="https://stackoverflow.com/questions/23966438/what-is-the-preferred-way-to-mutate-a-react-state">in this question</a>, and another which has <code>setState()</code> return an empty object instead. I've uploaded full versions of the app to CodePen so you can see that they behave identically.  </p>
  
  <ul>
  <li><a href="https://codepen.io/GrimEcho/pen/XEMMJE" rel="nofollow noreferrer">original</a></li>
  <li><a href="https://codepen.io/GrimEcho/pen/MVppwE" rel="nofollow noreferrer">empty return</a></li>
  <li>A <a href="https://codepen.io/GrimEcho/pen/MVppwE" rel="nofollow noreferrer">third version</a> simplifies the state mutation even more and also seems to work.</li>
  </ul>
  
  <h1>Code Segments</h1>
  
  <p>Here is the key code segment from the original. I'm using a callback for setState() as a way to guarantee that the state read and state write happen automatically (in case of asynchronous state changes between calls).</p>
  
  <pre><code>addTask(taskText) {
          this.setState(prevState =&gt; {
              const updatedTasks = prevState.tasks;
              updatedTasks.set(prevState.uid, taskText);   // use the original, un-incremented uid
              return {
                  uid: ++prevState.uid,   // increment prev uid and store it as new state
                  tasks: updatedTasks, // set tasks to updated tasks
              }
          }, this.logState);
      }
  </code></pre>
  
  <p><br/></p>
  
  <p>However, it seems that returning the actual changed state is unnecessary for collections (or any other reference-value object). As the following code also works. The only differences are that I hoisted the uid to a class property and didn't bother to return the updated map.</p>
  
  <pre><code>addTask(taskText) {
      this.setState(prevState =&gt; {
          const updatedTasks = prevState.tasks;
          updatedTasks.set(this.uid, taskText);   // use the original, un-incremented uid
          this.uid++;
          return {
              // return an empty object
              //uid: ++prevState.uid,   // update uid to one more than prev uid
              //tasks: updatedTasks, // set tasks to updated tasks
          }
      }, this.logState);
  }
  </code></pre>
  
  <p><br/></p>
  
  <p>If I don't care about wrapping the mutation inside of an arrow function as an asynchrounous guard, then the method can be simplified even further:</p>
  
  <pre><code>addTask(taskText) {
          this.state.tasks.set(this.uid, taskText);   // use the original, un-incremented uid
          this.uid++;
          this.setState({});
  }
  </code></pre>
  
  <p><br/></p>
  
  <p>It seems that the only thing that really matters is the <code>setState()</code> call itself. My initial understanding was that React was pretty efficient, and onyl checks for state changes that it's told about. However, the last example seems to indicate <code>setState()</code> causes React to examine all of its known state for any changes (regardless of how they got there), and then update/render accordingly. </p>
  
  <p>Changes to primitives would still need to be wrapped inside the returned setState() object, but for objects (or at least Maps), what is the downside to eliminating the complexity and just using a naked setState() call?</p>
  
  <hr/>
  
  <h1>Reference</h1>
  
  <p>I'm using the following:</p>
  
  <ul>
  <li>React and ReactDOM v16.2.0 (15.1.0 on the CodePens)</li>
  <li>Babel 6.26.0 (with stage-2 support for class properties)</li>
  <li>ECMAScript 6</li>
  </ul>