Merge pull request #1037 from camsong/master

Rename smart/dumb to presentational/container

Author: omnidan

docs/advanced/ExampleRedditAPI.md

@@ -180,7 +180,7 @@ export default function configureStore(initialState) {
 }
 ```
 
-## Smart Components
+## Container Components
 
 #### `containers/Root.js`
 
@@ -310,7 +310,7 @@ function mapStateToProps(state) {
 export default connect(mapStateToProps)(AsyncApp)
 ```
 
-## Dumb Components
+## Presentational Components
 
 #### `components/Picker.js`
 

docs/basics/ExampleTodoList.md

@@ -114,7 +114,7 @@ const todoApp = combineReducers({
 export default todoApp
 ```
 
-## Smart Components
+## Container Components
 
 #### `containers/App.js`
 
@@ -187,7 +187,7 @@ function select(state) {
 export default connect(select)(App)
 ```
 
-## Dumb Components
+## Presentational Components
 
 #### `components/AddTodo.js`
 

docs/basics/UsageWithReact.md

@@ -14,18 +14,18 @@ We will use React to build our simple todo app.
 npm install --save react-redux
 ```
 
-## Smart and Dumb Components
+## Container and Presentational Components
 
-React bindings for Redux embrace the idea of [separating “smart” and “dumb” components](https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0).
+React bindings for Redux embrace the idea of [separating container and presentational components](https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0).
 
-It is advisable that only top-level components of your app (such as route handlers) are aware of Redux. Components below them should be “dumb” and receive all data via props.
+It is advisable that only top-level components of your app (such as route handlers) are aware of Redux. Components below them should be presentational and receive all data via props.
 
 <table>
     <thead>
         <tr>
             <th></th>
-            <th scope="col" style="text-align:left">“Smart” Components</th>
-            <th scope="col" style="text-align:left">“Dumb” Components</th>
+            <th scope="col" style="text-align:left">Container Components</th>
+            <th scope="col" style="text-align:left">Presentational Components</th>
         </tr>
     </thead>
     <tbody>
@@ -52,7 +52,7 @@ It is advisable that only top-level components of your app (such as route handle
     </tbody>
 </table>
 
-In this todo app, we will only have a single “smart” component at the top of our view hierarchy. In more complex apps, you might have several of them. While you may nest “smart” components, we suggest that you pass props down whenever possible.
+In this todo app, we will only have a single container component at the top of our view hierarchy. In more complex apps, you might have several of them. While you may nest container components, we suggest that you pass props down whenever possible.
 
 ## Designing Component Hierarchy
 
@@ -75,13 +75,13 @@ I see the following components (and their props) emerge from this brief:
   - `filter: string` is the current filter: `'SHOW_ALL'`, `'SHOW_COMPLETED'` or `'SHOW_ACTIVE'`.
   - `onFilterChange(nextFilter: string)`: Callback to invoke when user chooses a different filter.
 
-These are all “dumb” components. They don’t know *where* the data comes from, or *how* to change it. They only render what’s given to them.
+These are all presentational components. They don’t know *where* the data comes from, or *how* to change it. They only render what’s given to them.
 
 If you migrate from Redux to something else, you’ll be able to keep all these components exactly the same. They have no dependency on Redux.
 
 Let’s write them! We don’t need to think about binding to Redux yet. You can just give them fake data while you experiment until they render correctly.
 
-## Dumb Components
+## Presentational Components
 
 These are all normal React components, so we won’t stop to examine them in detail. Here they go:
 

docs/recipes/ReducingBoilerplate.md

@@ -323,7 +323,7 @@ export default connect(state => ({
 }))(Posts)
 ```
 
-This is much less typing! If you’d like, you can still have “vanilla” action creators like `loadPostsSuccess` which you’d use from a “smart” `loadPosts` action creator.
+This is much less typing! If you’d like, you can still have “vanilla” action creators like `loadPostsSuccess` which you’d use from a container `loadPosts` action creator.
 
 **Finally, you can write your own middleware.** Let’s say you want to generalize the pattern above and describe your async action creators like this instead: