You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Update thinking-in-react.md (#2095)
Please refer to https://justsimply.dev for the thinking behind these proposed changes.
* Update thinking-in-react.md (#2098)
Follow up to reactjs/react.dev#2095 (comment)
* Add missing function call to example (#2102)
An example for useEffect omitted the actual invocation of the function in question.
* Fix conflict
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.
48
-
49
-
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.
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:
68
-
>>>>>>> 92ad9c2f7abb36a306f563fe48b7f52649929608
69
55
70
56
*`FilterableProductTable`
71
57
*`SearchBar`
@@ -85,46 +71,28 @@ Now that we've identified the components in our mock, let's arrange them into a
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.
94
-
95
-
Refer to the [React docs](/docs/) if you need help executing this step.
To make your UI interactive, you need to be able to trigger changes to your underlying data model. React achieves this with **state**.
111
-
112
-
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.
113
-
>>>>>>> 92ad9c2f7abb36a306f563fe48b7f52649929608
114
87
115
-
Think of all of the pieces of data in our example application. We have:
* Identify every component that renders something based on that state.
158
-
* Find a common owner component (a single component above all the components that need the state in the hierarchy).
159
-
* Either the common owner or another component higher up in the hierarchy should own the state.
160
-
* 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.
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.
183
-
>>>>>>> 92ad9c2f7abb36a306f563fe48b7f52649929608
184
-
185
-
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`.
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