Skip to content

Commit 0328b63

Browse files
authored
Update thinking-in-react.md
Please refer to https://justsimply.dev for the thinking behind these proposed changes.
1 parent 8994112 commit 0328b63

File tree

1 file changed

+12
-14
lines changed

1 file changed

+12
-14
lines changed

content/docs/thinking-in-react.md

Lines changed: 12 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -35,13 +35,13 @@ Our JSON API returns some data that looks like this:
3535

3636
The first thing you'll want to do is to draw boxes around every component (and subcomponent) in the mock and give them all names. If you're working with a designer, they may have already done this, so go talk to them! Their Photoshop layer names may end up being the names of your React components!
3737

38-
But how do you know what should be its own component? Just use the same techniques for deciding if you should create a new function or object. One such technique is the [single responsibility principle](https://en.wikipedia.org/wiki/Single_responsibility_principle), that is, a component should ideally only do one thing. If it ends up growing, it should be decomposed into smaller subcomponents.
38+
But how do you know what should be its own component? Use the same techniques for deciding if you should create a new function or object. One such technique is the [single responsibility principle](https://en.wikipedia.org/wiki/Single_responsibility_principle), that is, a component should ideally only do one thing. If it ends up growing, it should be decomposed into smaller subcomponents.
3939

40-
Since you're often displaying a JSON data model to a user, you'll find that if your model was built correctly, your UI (and therefore your component structure) will map nicely. That's because UI and data models tend to adhere to the same *information architecture*, which means the work of separating your UI into components is often trivial. Just break it up into components that represent exactly one piece of your data model.
40+
Since you're often displaying a JSON data model to a user, you'll find that if your model was built correctly, your UI (and therefore your component structure) will map nicely. That's because UI and data models tend to adhere to the same *information architecture*, which means the work of separating your UI into components is often trivial. Break it up into components that represent exactly one piece of your data model.
4141

4242
![Component diagram](../images/blog/thinking-in-react-components.png)
4343

44-
You'll see here that we have five components in our simple app. We've italicized the data each component represents.
44+
You'll see here that we have five components in our app. We've italicized the data each component represents.
4545

4646
1. **`FilterableProductTable` (orange):** contains the entirety of the example
4747
2. **`SearchBar` (blue):** receives all *user input*
@@ -51,7 +51,7 @@ You'll see here that we have five components in our simple app. We've italicized
5151

5252
If you look at `ProductTable`, you'll see that the table header (containing the "Name" and "Price" labels) isn't its own component. This is a matter of preference, and there's an argument to be made either way. For this example, we left it as part of `ProductTable` because it is part of rendering the *data collection* which is `ProductTable`'s responsibility. However, if this header grows to be complex (i.e. if we were to add affordances for sorting), it would certainly make sense to make this its own `ProductTableHeader` component.
5353

54-
Now that we've identified the components in our mock, let's arrange them into a hierarchy. This is easy. Components that appear within another component in the mock should appear as a child in the hierarchy:
54+
Now that we've identified the components in our mock, let's arrange them into a hierarchy. Components that appear within another component in the mock should appear as a child in the hierarchy:
5555

5656
* `FilterableProductTable`
5757
* `SearchBar`
@@ -70,19 +70,19 @@ To build a static version of your app that renders your data model, you'll want
7070

7171
You can build top-down or bottom-up. That is, you can either start with building the components higher up in the hierarchy (i.e. starting with `FilterableProductTable`) or with the ones lower in it (`ProductRow`). In simpler examples, it's usually easier to go top-down, and on larger projects, it's easier to go bottom-up and write tests as you build.
7272

73-
At the end of this step, you'll have a library of reusable components that render your data model. The components will only have `render()` methods since this is a static version of your app. The component at the top of the hierarchy (`FilterableProductTable`) will take your data model as a prop. If you make a change to your underlying data model and call `ReactDOM.render()` again, the UI will be updated. It's easy to see how your UI is updated and where to make changes since there's nothing complicated going on. React's **one-way data flow** (also called *one-way binding*) keeps everything modular and fast.
73+
At the end of this step, you'll have a library of reusable components that render your data model. The components will only have `render()` methods since this is a static version of your app. The component at the top of the hierarchy (`FilterableProductTable`) will take your data model as a prop. If you make a change to your underlying data model and call `ReactDOM.render()` again, the UI will be updated. You can see how your UI is updated and where to make changes. React's **one-way data flow** (also called *one-way binding*) keeps everything modular and fast.
7474

75-
Simply refer to the [React docs](/docs/) if you need help executing this step.
75+
Refer to the [React docs](/docs/) if you need help executing this step.
7676

7777
### A Brief Interlude: Props vs State {#a-brief-interlude-props-vs-state}
7878

7979
There are two types of "model" data in React: props and state. It's important to understand the distinction between the two; skim [the official React docs](/docs/interactivity-and-dynamic-uis.html) if you aren't sure what the difference is.
8080

8181
## Step 3: Identify The Minimal (but complete) Representation Of UI State {#step-3-identify-the-minimal-but-complete-representation-of-ui-state}
8282

83-
To make your UI interactive, you need to be able to trigger changes to your underlying data model. React makes this easy with **state**.
83+
To make your UI interactive, you need to be able to trigger changes to your underlying data model. React achieves this with **state**.
8484

85-
To build your app correctly, you first need to think of the minimal set of mutable state that your app needs. The key here is [DRY: *Don't Repeat Yourself*](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself). Figure out the absolute minimal representation of the state your application needs and compute everything else you need on-demand. For example, if you're building a TODO list, just keep an array of the TODO items around; don't keep a separate state variable for the count. Instead, when you want to render the TODO count, simply take the length of the TODO items array.
85+
To build your app correctly, you first need to think of the minimal set of mutable state that your app needs. The key here is [DRY: *Don't Repeat Yourself*](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself). Figure out the absolute minimal representation of the state your application needs and compute everything else you need on-demand. For example, if you're building a TODO list, keep an array of the TODO items around; don't keep a separate state variable for the count. Instead, when you want to render the TODO count, take the length of the TODO items array.
8686

8787
Think of all of the pieces of data in our example application. We have:
8888

@@ -91,7 +91,7 @@ Think of all of the pieces of data in our example application. We have:
9191
* The value of the checkbox
9292
* The filtered list of products
9393

94-
Let's go through each one and figure out which one is state. Simply ask three questions about each piece of data:
94+
Let's go through each one and figure out which one is state. Ask three questions about each piece of data:
9595

9696
1. Is it passed in from a parent via props? If so, it probably isn't state.
9797
2. Does it remain unchanged over time? If so, it probably isn't state.
@@ -117,7 +117,7 @@ For each piece of state in your application:
117117
* Identify every component that renders something based on that state.
118118
* Find a common owner component (a single component above all the components that need the state in the hierarchy).
119119
* Either the common owner or another component higher up in the hierarchy should own the state.
120-
* If you can't find a component where it makes sense to own the state, create a new component simply for holding the state and add it somewhere in the hierarchy above the common owner component.
120+
* If you can't find a component where it makes sense to own the state, create a new component solely for holding the state and add it somewhere in the hierarchy above the common owner component.
121121

122122
Let's run through this strategy for our application:
123123

@@ -135,14 +135,12 @@ You can start seeing how your application will behave: set `filterText` to `"bal
135135

136136
So far, we've built an app that renders correctly as a function of props and state flowing down the hierarchy. Now it's time to support data flowing the other way: the form components deep in the hierarchy need to update the state in `FilterableProductTable`.
137137

138-
React makes this data flow explicit to make it easy to understand how your program works, but it does require a little more typing than traditional two-way data binding.
138+
React makes this data flow explicit to help you understand how your program works, but it does require a little more typing than traditional two-way data binding.
139139

140140
If you try to type or check the box in the current version of the example, you'll see that React ignores your input. This is intentional, as we've set the `value` prop of the `input` to always be equal to the `state` passed in from `FilterableProductTable`.
141141

142142
Let's think about what we want to happen. We want to make sure that whenever the user changes the form, we update the state to reflect the user input. Since components should only update their own state, `FilterableProductTable` will pass callbacks to `SearchBar` that will fire whenever the state should be updated. We can use the `onChange` event on the inputs to be notified of it. The callbacks passed by `FilterableProductTable` will call `setState()`, and the app will be updated.
143143

144-
Though this sounds complex, it's really just a few lines of code. And it's really explicit how your data is flowing throughout the app.
145-
146144
## And That's It {#and-thats-it}
147145

148-
Hopefully, this gives you an idea of how to think about building components and applications with React. While it may be a little more typing than you're used to, remember that code is read far more than it's written, and it's extremely easy to read this modular, explicit code. As you start to build large libraries of components, you'll appreciate this explicitness and modularity, and with code reuse, your lines of code will start to shrink. :)
146+
Hopefully, this gives you an idea of how to think about building components and applications with React. While it may be a little more typing than you're used to, remember that code is read far more than it's written, and it's less difficult to read this modular, explicit code. As you start to build large libraries of components, you'll appreciate this explicitness and modularity, and with code reuse, your lines of code will start to shrink. :)

0 commit comments

Comments
 (0)