From 49499bbf58bfef6864db7ce0c866b27bf45dded7 Mon Sep 17 00:00:00 2001 From: Julen Ruiz Aizpuru Date: Wed, 30 Jul 2014 13:49:59 +0200 Subject: [PATCH] Docs: added note about setState() side-effects --- docs/ref-02-component-api.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/ref-02-component-api.md b/docs/ref-02-component-api.md index 0fa8ac1c..f2b5732d 100644 --- a/docs/ref-02-component-api.md +++ b/docs/ref-02-component-api.md @@ -27,6 +27,8 @@ Merges nextState with the current state. This is the primary method you use to t > `setState()` does not immediately mutate `this.state` but creates a pending state transition. Accessing `this.state` after calling this method can potentially return the existing value. > > There is no guarantee of synchronous operation of calls to `setState` and calls may be batched for performance gains. +> +> `setState()` will always trigger a re-render unless conditional rendering logic is implemented in `shouldComponentUpdate()`. If mutable objects are being used and the logic cannot be implemented in `shouldComponentUpdate()`, calling `setState()` only when the new state differs from the previous state will avoid unnecessary re-renders. ### replaceState