From a59d24144683c1648a4c6b9b4dd6d39943272c61 Mon Sep 17 00:00:00 2001 From: petehunt Date: Wed, 10 Jul 2013 17:18:13 -0700 Subject: [PATCH] further improvements --- docs/refactor/00-table-of-contents.md | 3 +++ docs/refactor/02-displaying-data.md | 4 ++++ docs/refactor/03-handling-user-input.md | 4 ++++ 3 files changed, 11 insertions(+) diff --git a/docs/refactor/00-table-of-contents.md b/docs/refactor/00-table-of-contents.md index d91434d6..1d07b817 100644 --- a/docs/refactor/00-table-of-contents.md +++ b/docs/refactor/00-table-of-contents.md @@ -3,6 +3,7 @@ - High information density -- assume the reader is adept at JS - Talk about best practices - JSFiddles for all code samples +- Provide background for some of the design decisions # Outline @@ -14,12 +15,14 @@ Motivation / Why React? Displaying data - Hello world example - Reactive updates +- Components are just functions - JSX syntax (link to separate doc?) Handling user input - Click handler example - Event handlers / synthetic events (link to w3c docs) - Under the hood: autoBind and event delegation (IE8 notes) +- React is a state machine - How state works - What should go in state? - What components should have state? diff --git a/docs/refactor/02-displaying-data.md b/docs/refactor/02-displaying-data.md index 6e2b8560..4da127bd 100644 --- a/docs/refactor/02-displaying-data.md +++ b/docs/refactor/02-displaying-data.md @@ -55,6 +55,10 @@ View the finished code in a web browser and type your name into the text field. The inputs to this component are called `props` -- short for "properties". They're passed as attributes in JSX syntax. You should think of these as immutable within the component, that is, **never write to this.props**. +## Components are just like functions + +React components are very simple. You can think of them as simple function that take in `props` and `state` (discussed later) and render HTML. Because they're so simple, it makes them very easy to reason about. + ## JSX syntax We strongly believe that components are the right way to separate concerns rather than "templates" and "display logic." We think that markup and the code that generates it are intimately tied together. Additionally, display logic is often very complex and using template languages to express it becomes cumbersome. diff --git a/docs/refactor/03-handling-user-input.md b/docs/refactor/03-handling-user-input.md index eec106aa..79f8e35f 100644 --- a/docs/refactor/03-handling-user-input.md +++ b/docs/refactor/03-handling-user-input.md @@ -42,6 +42,10 @@ Under the hood React does a few things to keep your code performant and easy to **Event delegation.** React doesn't actually attach event handlers to the nodes themselves. When React starts up, it starts listening for all events at the top level using a single event listener. When a component is mounted or unmounted, the event handlers are simply added or removed from a fast internal event mapping. When the event occurs, React knows how to dispatch it using this mapping. When there are no event handlers left in the mapping, React's event handlers are simple no-ops. To learn more about why this is fast, see [David Walsh's excellent blog post](http://davidwalsh.name/event-delegate). +## Components are just state machines + +React thinks of UIs as simple state machines. By thinking of a UI as being in various states and rendering those states, it's easy to keep your UI consistent. + ## How state works A common way to inform React of a data change is by calling `setState(data, callback)`. This method merges `data` into `this.state` and re-renders the component. When the component finishes re-rendering, the optional `callback` is called. Most of the time you'll never need to provide a `callback` since state tends to be so minimal.