From 050085ddebf29273505cd7f56ed702d948a76f87 Mon Sep 17 00:00:00 2001 From: petehunt Date: Sun, 14 Jul 2013 18:46:50 -0700 Subject: [PATCH] fix markup bugs --- _includes/nav_docs.html | 4 ++-- docs/03-interactivity-and-dynamic-uis.md | 1 + 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/_includes/nav_docs.html b/_includes/nav_docs.html index 5c9fd3e2..eec25456 100644 --- a/_includes/nav_docs.html +++ b/_includes/nav_docs.html @@ -2,8 +2,8 @@

Quick start

diff --git a/docs/03-interactivity-and-dynamic-uis.md b/docs/03-interactivity-and-dynamic-uis.md index c684e658..1aaa6844 100644 --- a/docs/03-interactivity-and-dynamic-uis.md +++ b/docs/03-interactivity-and-dynamic-uis.md @@ -74,6 +74,7 @@ A common pattern is to create several stateless components that just render data ### What *shouldn't* go in state? `this.state` should only contain the minimal amount of data needed to represent your UI's state. As such, it should not contain: + * **Computed data.** Don't worry about precomputing values based on state -- it's easier to ensure that your UI is consistent if you do all computation within `render()`. For example, if you have an array of list items in state and you want to render the count as a string, simply render `this.state.listItems.length + ' list items'` in your `render()` method rather than storing it on state. * **React components.** Build them in `render()` based on underlying props and state. * **Duplicated data from props.** Try to use props as the source of truth where possible. Because props can change over time, it's appropriate to store props in state to be able to know its previous values. \ No newline at end of file