All of the frameworks discussed in this module are powered by JavaScript, and all allow you to use domain-specific languages (DSLs) in order to build your applications. In particular, React has popularized the use of JSX for writing its components, while Ember utilizes Handlebars. Unlike HTML, these languages know how to read data variables, and this data can be used to streamline the process of writing your UI.
-
-
Angular apps often make heavy use of TypeScript. TypeScript is not concerned with the writing of user interfaces, but it is a domain-specific language, and has significant differences to vanilla JavaScript.
-
-
DSLs can't be read by the browser directly; they must be transformed into JavaScript or HTML first. Transformation is an extra step in the development process, but framework tooling generally includes the required tools to handle this step, or can be adjusted to include this step. While it is possible to build framework apps without using these domain-specific languages, embracing them will streamline your development process and make it easier to find help from the communities around those frameworks.
-
-
JSX
-
-
JSX, which stands for JavaScript and XML, is an extension of JavaScript that brings HTML-like syntax to a JavaScript environment. It was invented by the React team for use in React applications, but can be used to develop other applications — like Vue apps, for instance.
This expression represents an HTML <header> element with a <h1> element inside. The curly braces around subject on line 4 tell the application to read the value of the subject constant and insert it into our <h1>.
-
-
When used with React, the JSX from the previous snippet would be compiled into this:
When ultimately rendered by the browser, the above snippet will produce HTML that looks like this:
-
-
<header>
- <h1>Hello, World!</h1>
-</header>
-
-
Handlebars
-
-
The Handlebars templating language is not specific to Ember applications, but it is heavily utilized in Ember apps. Handlebars code resembles HTML, but it has the option of pulling data in from elsewhere. This data can be used to influence the HTML that an application ultimately builds.
-
-
Like JSX, Handlebars uses curly braces to inject the value of a variable. Handlebars uses a double-pair of curly braces, instead of a single pair.
TypeScript is a superset of JavaScript, meaning it extends JavaScript — all JavaScript code is valid TypeScript, but not the other way around. TypeScript is useful for the strictness it allows developers to enforce on their code. For instance, consider a function add(), which takes integers a and b and returns their sum.
-
-
In JavaScript, that function could be written like this:
-
-
function add(a, b) {
- return a + b;
-}
-
-
This code might be trivial for someone accustomed to JavaScript, but it could still be clearer. JavaScript lets us use the + operator to concatenate strings together, so this function would technically still work if a and b were strings — it just might not give you the result you'd expect. What if we wanted to only allow numbers to be passed into this function? TypeScript makes that possible:
-
-
function add(a: number, b: number) {
- return a + b;
-}
-
-
The : number written after each parameter here tells TypeScript that both a and b must be numbers. If we were to use this function and pass '2' into it as an argument, TypeScript would raise an error during compilation, and we would be forced to fix our mistake. We could write our own JavaScript that raises these errors for us, but it would make our source code significantly more verbose. It probably makes more sense to let TypeScript handle such checks for us.
-
-
Writing components
-
-
As mentioned in the previous chapter, most frameworks have some kind of component model. React components can be written with JSX, Ember components with Handlebars, and Angular and Vue components with a templating syntax that lightly extends HTML.
-
-
Regardless of their opinions on how components should be written, each framework's components offer a way to describe the external properties they may need, the internal state that the component should manage, and the events a user can trigger on the component's markup.
-
-
The code snippets in the rest of this section will use React as an example, and are written with JSX.
-
-
Properties
-
-
Properties, or props, are external data that a component needs in order to render. Suppose you're building a website for an online magazine, and you need to be sure that each contributing writer gets credit for their work. You might create an AuthorCredit component to go with each article. This component needs to display a portrait of the author and a short byline about them. In order to know what image to render, and what byline to print, AuthorCredit needs to accept some props.
-
-
A React representation of this AuthorCredit component might look something like this:
{props.src}, {props.alt}, and {props.byline} represent where our props will be inserted into the component. To render this component, we would write code like this in the place where we want it rendered (which will probably be inside another component):
-
-
<AuthorCredit
- src="./assets/zelda.png"
- alt="Portrait of Zelda Schiff"
- byline="Zelda Schiff is editor-in-chief of the Library Times."
-/>
-
-
This will ultimately render the following <figure> element in the browser, with its structure as defined in the AuthorCredit component, and its content as defined in the props included on the AuthorCredit component call:
-
-
<figure>
- <img
- src="assets/zelda.png"
- alt="Portrait of Zelda Schiff"
- >
- <figcaption>
- Zelda Schiff is editor-in-chief of the Library Times.
- </figcaption>
-</figure>
-
-
State
-
-
We talked about the concept of state in the previous chapter — a robust state-handling mechanism is key to an effective framework, and each component may have data that needs its state controlled. This state will persist in some way as long as the component is in use. Like props, state can be used to affect how a component is rendered.
-
-
As an example, consider a button that counts how many times it has been clicked. This component should be responsible for tracking its own count state, and could be written like this:
useState() is a React hook which, given an initial data value, will keep track of that value as it is updated. The code will be initially rendered like so in the browser:
-
-
<button>Clicked 0 times</button>
-
-
The useState() call keeps track of the count value in a robust way across the app, without you needing to write code to do that yourself.
-
-
Events
-
-
In order to be interactive, components need ways to respond to browser events, so our applications can respond to our users. Frameworks each provide their own syntax for listening to browser events, which reference the names of the equivalent native browser events.
-
-
In React, listening for the click event requires a special property, onClick. Let’s update our CounterButton code from above to allow it to count clicks:
In this version we are using additional useState() functionality to create a special setCount() function, which we can invoke to update the value of count. We call this function on line 4, and set count to whatever its current value is, plus one.
-
-
Styling components
-
-
Each framework offers a way to define styles for your components — or for the application as a whole. Although each framework’s approach to defining the styles of a component is slightly different, all of them give you multiple ways to do so. With the addition of some helper modules, you can style your framework apps in Sass or Less, or transpile your CSS stylesheets with PostCSS.
-
-
Handling dependencies
-
-
All major frameworks provide mechanisms for handling dependencies — using components inside other components, sometimes with multiple hierarchy levels. As with other features, the exact mechanism will differ between frameworks, but the end result is the same. Components tend to import components into other components using the standard JavaScript module syntax, or at least something similar.
-
-
Components in components
-
-
One key benefit of component-based UI architecture is that components can be composed together. Just like you can write HTML tags inside each other to build a website, you can use components inside other components to build a web application. Each framework allows you to write components that utilize (and thus depend on) other components.
-
-
For example, our AuthorCredit React component might be utilized inside an Article component. That means that Article would need to import AuthorCredit.
-
-
import AuthorCredit from "./components/AuthorCredit";
-
-
Once that’s done, AuthorCredit could be used inside the Article component like this:
-
-
...
-
-<AuthorCredit />
-
- ...
-
-
Dependency injection
-
-
Real-world applications can often involve component structures with multiple levels of nesting. An AuthorCredit component nested many levels deep might, for some reason, need data from the very root level of our application.
-
-
Let's say that the magazine site we're building is structured like this:
Our App component has data that our AuthorCredit component needs. We could rewrite Home and Article so that they know to pass props down, but this could get tedious if there are many, many levels between the origin and destination of our data. It's also excessive: Home and Article don’t actually make use of the author's portrait or byline, but if we want to get that information into the AuthorCredit, we will need to change Home and Author to accommodate it.
-
-
The problem of passing data through many layers of components is called prop drilling, and it’s not ideal for large applications.
-
-
To circumvent prop drilling, frameworks provide functionality known as dependency injection, which is a way to get certain data directly to the components that need it, without passing it through intervening levels. Each framework implements dependency injection under a different name, and in a different way, but the effect is ultimately the same.
In the context of a framework, a component’s lifecycle is a collection of phases a component goes through from the time it is rendered by the browser (often called mounting) to the time that it is removed from the DOM (often called unmounting). Each framework names these lifecycle phases differently, and not all give developers access to the same phases. All of the frameworks follow the same general model: they allow developers to perform certain actions when the component mounts, when it renders, when it unmounts, and at many phases in between these.
-
-
The render phase is the most crucial to understand, because it is repeated the most times as your user interacts with your application. It's run every time the browser needs to render something new, whether that new information is an addition to what's in the browser, a deletion, or an edit of what’s there.
Just as with lifecycles, frameworks take different-but-similar approaches to how they render your applications. All of them track the current rendered version of your browser's DOM, and each makes slightly different decisions about how the DOM should change as components in your application re-render. Because frameworks make these decisions for you, you typically don't interact with the DOM yourself. This abstraction away from the DOM is more complex and more memory-intensive than updating the DOM yourself, but without it, frameworks could not allow you to program in the declarative way they’re known for.
-
-
The Virtual DOM is an approach whereby information about your browser's DOM is stored in JavaScript memory. Your application updates this copy of the DOM, then compares it to the "real" DOM — the DOM that is actually rendered for your users — in order to decide what to render. The application builds a "diff" to compare the differences between the updated virtual DOM and the currently rendered DOM, and uses that diff to apply updates to the real DOM. Both React and Vue utilize a virtual DOM model, but they do not apply the exact same logic when diffing or rendering.
The Incremental DOM is similar to the virtual DOM in that it builds a DOM diff to decide what to render, but different in that it doesn't create a complete copy of the DOM in JavaScript memory. It ignores the parts of the DOM that do not need to be changed. Angular is the only framework discussed so far in this module that uses an incremental DOM.
The Glimmer VM is unique to Ember. It is not a virtual DOM nor an incremental DOM; it is a separate process through which Ember's templates are transpiled into a kind of "byte code" that is easier and faster to read than JavaScript.
-
-
Routing
-
-
As mentioned in the previous chapter, routing is an important part of the web experience. To avoid a broken experience in sufficiently complex apps with lots of views, each of the frameworks covered in this module provides a library (or more than one library) that helps developers implement client-side routing in their applications.
-
-
Testing
-
-
All applications benefit from test coverage that ensures your software continues to behave in the way that you'd expect, and web applications are no different. Each framework's ecosystem provides tooling that facilitates the writing of tests. Testing tools are not built into the frameworks themselves, but the command-line interface tools used to generate framework apps give you access to the appropriate testing tools.
-
-
Each framework has extensive tools in its ecosystem, with capabilities for unit and integration testing alike.
-
-
Testing Library is a suite of testing utilities that has tools for many JavaScript environments, including React, Vue, and Angular. The Ember docs cover the testing of Ember apps.
-
-
Here’s a quick test for our CounterButton written with the help of React Testing Library — it tests a number of things, such as the button's existence, and whether the button is displaying the correct text after being clicked 0, 1, and 2 times:
-
-
import React from "react";
-import { render, fireEvent } from "@testing-library/react";
-import "@testing-library/jest-dom/extend-expect";
-
-import CounterButton from "./CounterButton";
-
-it("renders a semantic with an initial state of 0", () => {
- const { getByRole } = render(<CounterButton />);
- const btn = getByRole("button");
-
- expect(btn).toBeInTheDocument();
- expect(btn).toHaveTextContent("Clicked 0 times");
-});
-
-it("Increments the count when clicked", () => {
- const { getByRole } = render(<CounterButton />);
- const btn = getByRole("button");
-
- fireEvent.click(btn);
- expect(btn).toHaveTextContent("Clicked 1 times");
-
- fireEvent.click(btn);
- expect(btn).toHaveTextContent("Clicked 2 times");
-});
-
-
Summary
-
-
At this point you should have more of an idea about the actual languages, features, and tools you'll be using as you create applications with frameworks. I'm sure you’re enthusiastic to get going and actually do some coding, and that's what you are going to do next! At this point you can choose which framework you'd like to start learning first:
+
+## Domain-specific languages
+
+All of the frameworks discussed in this module are powered by JavaScript, and all allow you to use domain-specific languages (DSLs) in order to build your applications. In particular, React has popularized the use of **JSX** for writing its components, while Ember utilizes **Handlebars**. Unlike HTML, these languages know how to read data variables, and this data can be used to streamline the process of writing your UI.
+
+Angular apps often make heavy use of **TypeScript**. TypeScript is not concerned with the writing of user interfaces, but it is a domain-specific language, and has significant differences to vanilla JavaScript.
+
+DSLs can't be read by the browser directly; they must be transformed into JavaScript or HTML first. [Transformation is an extra step in the development process](/en-US/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Overview#Transformation), but framework tooling generally includes the required tools to handle this step, or can be adjusted to include this step. While it is possible to build framework apps without using these domain-specific languages, embracing them will streamline your development process and make it easier to find help from the communities around those frameworks.
+
+### JSX
+
+[JSX](https://reactjs.org/docs/introducing-jsx.html), which stands for JavaScript and XML, is an extension of JavaScript that brings HTML-like syntax to a JavaScript environment. It was invented by the React team for use in React applications, but can be used to develop other applications — like Vue apps, for instance.
+
+The following shows a simple JSX example:
+
+```js
+const subject = "World";
+const header = (
+
+
Hello, {subject}!
+
+);
+```
+
+This expression represents an HTML [``](/en-US/docs/Web/HTML/Element/header) element with a [`
`](/en-US/docs/Web/HTML/Element/Heading_Elements) element inside. The curly braces around `subject` on line 4 tell the application to read the value of the `subject` constant and insert it into our `
`.
+
+When used with React, the JSX from the previous snippet would be compiled into this:
+
+```js
+var subject = "World";
+var header = React.createElement("header", null,
+ React.createElement("h1", null, "Hello, ", subject, "!")
+);
+```
+
+When ultimately rendered by the browser, the above snippet will produce HTML that looks like this:
+
+```html
+
+
Hello, World!
+
+```
+
+### Handlebars
+
+The [Handlebars](https://handlebarsjs.com/) templating language is not specific to Ember applications, but it is heavily utilized in Ember apps. Handlebars code resembles HTML, but it has the option of pulling data in from elsewhere. This data can be used to influence the HTML that an application ultimately builds.
+
+Like JSX, Handlebars uses curly braces to inject the value of a variable. Handlebars uses a double-pair of curly braces, instead of a single pair.
+
+Given this Handlebars template:
+
+```html
+
+
Hello, \{{subject}}!
+
+```
+
+And this data:
+
+```js
+{
+ subject: "World"
+}
+```
+
+Handlebars will build HTML like this:
+
+```html
+
+
Hello, World!
+
+```
+
+### TypeScript
+
+[TypeScript](https://www.typescriptlang.org/) is a _superset_ of JavaScript, meaning it extends JavaScript — all JavaScript code is valid TypeScript, but not the other way around. TypeScript is useful for the strictness it allows developers to enforce on their code. For instance, consider a function `add()`, which takes integers `a` and `b` and returns their sum.
+
+In JavaScript, that function could be written like this:
+
+```js
+function add(a, b) {
+ return a + b;
+}
+```
+
+This code might be trivial for someone accustomed to JavaScript, but it could still be clearer. JavaScript lets us use the `+` operator to concatenate strings together, so this function would technically still work if `a` and `b` were strings — it just might not give you the result you'd expect. What if we wanted to only allow numbers to be passed into this function? TypeScript makes that possible:
+
+```js
+function add(a: number, b: number) {
+ return a + b;
+}
+```
+
+The `: number` written after each parameter here tells TypeScript that both `a` and `b` must be numbers. If we were to use this function and pass `'2'` into it as an argument, TypeScript would raise an error during compilation, and we would be forced to fix our mistake. We could write our own JavaScript that raises these errors for us, but it would make our source code significantly more verbose. It probably makes more sense to let TypeScript handle such checks for us.
+
+## Writing components
+
+As mentioned in the previous chapter, most frameworks have some kind of component model. React components can be written with JSX, Ember components with Handlebars, and Angular and Vue components with a templating syntax that lightly extends HTML.
+
+Regardless of their opinions on how components should be written, each framework's components offer a way to describe the external properties they may need, the internal state that the component should manage, and the events a user can trigger on the component's markup.
+
+The code snippets in the rest of this section will use React as an example, and are written with JSX.
+
+### Properties
+
+Properties, or **props**, are external data that a component needs in order to render. Suppose you're building a website for an online magazine, and you need to be sure that each contributing writer gets credit for their work. You might create an `AuthorCredit` component to go with each article. This component needs to display a portrait of the author and a short byline about them. In order to know what image to render, and what byline to print, `AuthorCredit` needs to accept some props.
+
+A React representation of this `AuthorCredit` component might look something like this:
+
+```js
+function AuthorCredit(props) {
+ return (
+
+
+ {props.byline}
+
+ );
+}
+```
+
+`{props.src}`, `{props.alt}`, and `{props.byline}` represent where our props will be inserted into the component. To render this component, we would write code like this in the place where we want it rendered (which will probably be inside another component):
+
+```js
+
+```
+
+This will ultimately render the following [`
`](/en-US/docs/Web/HTML/Element/figure) element in the browser, with its structure as defined in the `AuthorCredit` component, and its content as defined in the props included on the `AuthorCredit` component call:
+
+```html
+
+
+
+ Zelda Schiff is editor-in-chief of the Library Times.
+
+
+```
+
+### State
+
+We talked about the concept of **state** in the previous chapter — a robust state-handling mechanism is key to an effective framework, and each component may have data that needs its state controlled. This state will persist in some way as long as the component is in use. Like props, state can be used to affect how a component is rendered.
+
+As an example, consider a button that counts how many times it has been clicked. This component should be responsible for tracking its own _count_ state, and could be written like this:
+
+```js
+function CounterButton() {
+ const [count] = useState(0);
+ return (
+
+ );
+}
+```
+
+[`useState()`](https://reactjs.org/docs/hooks-reference.html#usestate) is a **[React hook](https://reactjs.org/docs/hooks-intro.html)** which, given an initial data value, will keep track of that value as it is updated. The code will be initially rendered like so in the browser:
+
+```html
+
+```
+
+The `useState()` call keeps track of the `count` value in a robust way across the app, without you needing to write code to do that yourself.
+
+### Events
+
+In order to be interactive, components need ways to respond to browser events, so our applications can respond to our users. Frameworks each provide their own syntax for listening to browser events, which reference the names of the equivalent native browser events.
+
+In React, listening for the [`click`](/en-US/docs/Web/API/Element/click_event) event requires a special property, `onClick`. Let’s update our `CounterButton` code from above to allow it to count clicks:
+
+```js
+function CounterButton() {
+ const [count, setCount] = useState(0);
+ return (
+
+ );
+}
+```
+
+In this version we are using additional `useState()` functionality to create a special `setCount()` function, which we can invoke to update the value of `count`. We call this function on line 4, and set `count` to whatever its current value is, plus one.
+
+## Styling components
+
+Each framework offers a way to define styles for your components — or for the application as a whole. Although each framework’s approach to defining the styles of a component is slightly different, all of them give you multiple ways to do so. With the addition of some helper modules, you can style your framework apps in [Sass](https://sass-lang.com/) or [Less](http://lesscss.org/), or transpile your CSS stylesheets with [PostCSS](https://postcss.org/).
+
+## Handling dependencies
+
+All major frameworks provide mechanisms for handling dependencies — using components inside other components, sometimes with multiple hierarchy levels. As with other features, the exact mechanism will differ between frameworks, but the end result is the same. Components tend to import components into other components using the standard [JavaScript module syntax](/en-US/docs/Web/JavaScript/Guide/Modules), or at least something similar.
+
+### Components in components
+
+One key benefit of component-based UI architecture is that components can be composed together. Just like you can write HTML tags inside each other to build a website, you can use components inside other components to build a web application. Each framework allows you to write components that utilize (and thus depend on) other components.
+
+For example, our `AuthorCredit` React component might be utilized inside an `Article` component. That means that `Article` would need to import `AuthorCredit`.
+
+```js
+import AuthorCredit from "./components/AuthorCredit";
+```
+
+Once that’s done, `AuthorCredit` could be used inside the `Article` component like this:
+
+```js
+ ...
+
+
+
+ ...
+```
+
+### Dependency injection
+
+Real-world applications can often involve component structures with multiple levels of nesting. An `AuthorCredit` component nested many levels deep might, for some reason, need data from the very root level of our application.
+
+Let's say that the magazine site we're building is structured like this:
+
+```js
+
+
+
+
+
+
+
+```
+
+Our `App` component has data that our `AuthorCredit` component needs. We could rewrite `Home` and `Article` so that they know to pass props down, but this could get tedious if there are many, many levels between the origin and destination of our data. It's also excessive: `Home` and `Article` don’t actually make use of the author's portrait or byline, but if we want to get that information into the `AuthorCredit`, we will need to change `Home` and `Author` to accommodate it.
+
+The problem of passing data through many layers of components is called prop drilling, and it’s not ideal for large applications.
+
+To circumvent prop drilling, frameworks provide functionality known as dependency injection, which is a way to get certain data directly to the components that need it, without passing it through intervening levels. Each framework implements dependency injection under a different name, and in a different way, but the effect is ultimately the same.
+
+Angular calls this process [dependency injection](https://angular.io/guide/dependency-injection); Vue has [`provide()` and `inject()` component methods](https://vuejs.org/v2/api/#provide-inject); React has a [Context API](https://reactjs.org/docs/context.html); Ember shares state through [services](https://guides.emberjs.com/release/services/).
+
+### Lifecycle
+
+In the context of a framework, a component’s **lifecycle** is a collection of phases a component goes through from the time it is rendered by the browser (often called _mounting_) to the time that it is removed from the DOM (often called _unmounting_). Each framework names these lifecycle phases differently, and not all give developers access to the same phases. All of the frameworks follow the same general model: they allow developers to perform certain actions when the component _mounts_, when it _renders_, when it _unmounts_, and at many phases in between these.
+
+The _render_ phase is the most crucial to understand, because it is repeated the most times as your user interacts with your application. It's run every time the browser needs to render something new, whether that new information is an addition to what's in the browser, a deletion, or an edit of what’s there.
+
+This [diagram of a React component's lifecycle](http://projects.wojtekmaj.pl/react-lifecycle-methods-diagram/) offers a general overview of the concept.
+
+## Rendering elements
+
+Just as with lifecycles, frameworks take different-but-similar approaches to how they render your applications. All of them track the current rendered version of your browser's DOM, and each makes slightly different decisions about how the DOM should change as components in your application re-render. Because frameworks make these decisions for you, you typically don't interact with the DOM yourself. This abstraction away from the DOM is more complex and more memory-intensive than updating the DOM yourself, but without it, frameworks could not allow you to program in the declarative way they’re known for.
+
+The **Virtual DOM** is an approach whereby information about your browser's DOM is stored in JavaScript memory. Your application updates this copy of the DOM, then compares it to the "real" DOM — the DOM that is actually rendered for your users — in order to decide what to render. The application builds a "diff" to compare the differences between the updated virtual DOM and the currently rendered DOM, and uses that diff to apply updates to the real DOM. Both React and Vue utilize a virtual DOM model, but they do not apply the exact same logic when diffing or rendering.
+
+You can [read more about the Virtual DOM in the React docs](https://reactjs.org/docs/faq-internals.html#what-is-the-virtual-dom).
+
+The **Incremental DOM** is similar to the virtual DOM in that it builds a DOM diff to decide what to render, but different in that it doesn't create a complete copy of the DOM in JavaScript memory. It ignores the parts of the DOM that do not need to be changed. Angular is the only framework discussed so far in this module that uses an incremental DOM.
+
+You can [read more about the Incremental DOM on the Auth0 blog](https://auth0.com/blog/incremental-dom/).
+
+The **Glimmer VM** is unique to Ember. It is not a virtual DOM nor an incremental DOM; it is a separate process through which Ember's templates are transpiled into a kind of "byte code" that is easier and faster to read than JavaScript.
+
+## Routing
+
+As [mentioned in the previous chapter, routing](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Introduction#Routing) is an important part of the web experience. To avoid a broken experience in sufficiently complex apps with lots of views, each of the frameworks covered in this module provides a library (or more than one library) that helps developers implement client-side routing in their applications.
+
+## Testing
+
+All applications benefit from test coverage that ensures your software continues to behave in the way that you'd expect, and web applications are no different. Each framework's ecosystem provides tooling that facilitates the writing of tests. Testing tools are not built into the frameworks themselves, but the command-line interface tools used to generate framework apps give you access to the appropriate testing tools.
+
+Each framework has extensive tools in its ecosystem, with capabilities for unit and integration testing alike.
+
+[Testing Library](https://testing-library.com/) is a suite of testing utilities that has tools for many JavaScript environments, including React, Vue, and Angular. The Ember docs cover the [testing of Ember apps](https://guides.emberjs.com/release/testing/).
+
+Here’s a quick test for our `CounterButton` written with the help of React Testing Library — it tests a number of things, such as the button's existence, and whether the button is displaying the correct text after being clicked 0, 1, and 2 times:
+
+```js
+import React from "react";
+import { render, fireEvent } from "@testing-library/react";
+import "@testing-library/jest-dom/extend-expect";
+
+import CounterButton from "./CounterButton";
+
+it("renders a semantic with an initial state of 0", () => {
+ const { getByRole } = render();
+ const btn = getByRole("button");
+
+ expect(btn).toBeInTheDocument();
+ expect(btn).toHaveTextContent("Clicked 0 times");
+});
+
+it("Increments the count when clicked", () => {
+ const { getByRole } = render();
+ const btn = getByRole("button");
+
+ fireEvent.click(btn);
+ expect(btn).toHaveTextContent("Clicked 1 times");
+
+ fireEvent.click(btn);
+ expect(btn).toHaveTextContent("Clicked 2 times");
+});
+```
+
+## Summary
+
+At this point you should have more of an idea about the actual languages, features, and tools you'll be using as you create applications with frameworks. I'm sure you’re enthusiastic to get going and actually do some coding, and that's what you are going to do next! At this point you can choose which framework you'd like to start learning first:
+
+- [React](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/React_getting_started)
+- [Ember](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Ember_getting_started)
+- [Vue](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Vue_getting_started)
+
+> **备注：** We only have three framework tutorial series available now, but we hope to have more available in the future.
+
+{{PreviousMenuNext("Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Introduction","Learn/Tools_and_testing/Client-side_JavaScript_frameworks/React_getting_started", "Learn/Tools_and_testing/Client-side_JavaScript_frameworks")}}
+
+## In this module
+
+- [Introduction to client-side frameworks](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Introduction)
+- [Framework main features](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Main_features)
+- React
+
+ - [Getting started with React](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/React_getting_started)
+ - [Beginning our React todo list](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/React_todo_list_beginning)
+ - [Componentizing our React app](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/React_components)
+ - [React interactivity: Events and state](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/React_interactivity_events_state)
+ - [React interactivity: Editing, filtering, conditional rendering](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/React_interactivity_filtering_conditional_rendering)
+ - [Accessibility in React](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/React_accessibility)
+ - [React resources](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/React_resources)
+
+- Ember
+
+ - [Getting started with Ember](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Ember_getting_started)
+ - [Ember app structure and componentization](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Ember_structure_componentization)
+ - [Ember interactivity: Events, classes and state](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Ember_interactivity_events_state)
+ - [Ember Interactivity: Footer functionality, conditional rendering](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Ember_conditional_footer)
+ - [Routing in Ember](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Ember_routing)
+ - [Ember resources and troubleshooting](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Ember_resources)
+
+- Vue
+
+ - [Getting started with Vue](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Vue_getting_started)
+ - [Creating our first Vue component](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Vue_first_component)
+ - [Rendering a list of Vue components](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Vue_rendering_lists)
+ - [Adding a new todo form: Vue events, methods, and models](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Vue_methods_events_models)
+ - [Styling Vue components with CSS](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Vue_styling)
+ - [Using Vue computed properties](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Vue_computed_properties)
+ - [Vue conditional rendering: editing existing todos](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Vue_conditional_rendering)
+ - [Focus management with Vue refs](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Vue_refs_focus_management)
+ - [Vue resources](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Vue_resources)
+
+- Svelte
+
+ - [Getting started with Svelte](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Svelte_getting_started)
+ - [Starting our Svelte Todo list app](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Svelte_Todo_list_beginning)
+ - [Dynamic behavior in Svelte: working with variables and props](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Svelte_variables_props)
+ - [Componentizing our Svelte app](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Svelte_components)
+ - [Advanced Svelte: Reactivity, lifecycle, accessibility](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Svelte_reactivity_lifecycle_accessibility)
+ - [Working with Svelte stores](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Svelte_stores)
+ - [TypeScript support in Svelte](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Svelte_TypeScript)
+ - [Deployment and next steps](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Svelte_deployment_next)
diff --git a/files/zh-cn/learn/tools_and_testing/client-side_javascript_frameworks/react_components/index.html b/files/zh-cn/learn/tools_and_testing/client-side_javascript_frameworks/react_components/index.html
deleted file mode 100644
index 91bb19e04c42d8..00000000000000
--- a/files/zh-cn/learn/tools_and_testing/client-side_javascript_frameworks/react_components/index.html
+++ /dev/null
@@ -1,450 +0,0 @@
----
-title: Componentizingapp
-slug: Learn/Tools_and_testing/Client-side_JavaScript_frameworks/React_components
-translation_of: Learn/Tools_and_testing/Client-side_JavaScript_frameworks/React_components
----
-
At this point, our app is a monolith. Before we can make it do things, we need to break it apart into manageable, descriptive components. React doesn’t have any hard rules for what is and isn’t a component – that’s up to you! In this article we will show you a sensible way to break our app up into components.
To show a sensible way of breaking our todo list app into components.
-
-
-
-
-
Defining our first component
-
-
Defining a component can seem tricky until you have some practice, but the gist is:
-
-
-
If it represents an obvious "chunk" of your app, it's probably a component
-
If it gets reused often, it's probably a component.
-
-
-
That second bullet is especially valuable: making a component out of common UI elements allows you to change your code in one place and see those changes everywhere that component is used. You don't have to break everything out into components right away, either. Let's take the second bullet point as inspiration and make a component out of the most reused, most important piece of the UI: a todo list item.
-
-
Make a <Todo />
-
-
Before we can make a component, we should create a new file for it. In fact, we should make a directory just for our components. The following commands make a components directory and then, within that, a file called Todo.js. Make sure you're in the root of your app before you run these!
Our new Todo.js file is currently empty! Open it up and give it its first line:
-
-
import React from "react";
-
-
Since we're going to make a component called Todo, you can start adding the code for that to Todo.js too, as follows. In this code, we define the function and export it on the same line:
This is OK so far, but our component has to return something! Go back to src/App.js, copy the first <li> from inside the unordered list, and paste it into Todo.js so that it reads like this:
Note: Components must always return something. If at any point in the future you try to render a component that does not return anything, React will display an error in your browser.
-
-
-
Our Todo component is complete, at least for now; now we can use it. In App.js, add the following line near the top of the file to import Todo:
-
-
import Todo from "./components/Todo";
-
-
With this component imported, you can replace all of the <li> elements in App.js with <Todo /> component calls. Your <ul> should read like this:
When you look back at your browser, you'll notice something unfortunate: your list now repeats the first task three times!
-
-
-
-
We don't only want to eat; we have other things to — well — to do. Next we'll look at how we can make different component calls render unique content.
-
-
Make a unique<Todo />
-
-
Components are powerful because they let us re-use pieces of our UI, and refer to one place for the source of that UI. The problem is, we don't typically want to reuse all of each component; we want to reuse most parts, and change small pieces. This is where props come in.
-
-
What's in a name?
-
-
In order to track the names of tasks we want to complete, we should ensure that each <Todo /> component renders a unique name.
-
-
In App.js, give each <Todo /> a name prop. Let’s use the names of our tasks that we had before:
When your browser refreshes, you will see… the exact same thing as before. We gave our <Todo /> some props, but we aren't using them yet. Let's go back to Todo.js and remedy that.
-
-
First modify your Todo() function definition so that it takes props as a parameter. You can console.log() your props as we did before, if you'd like to check that they are being received by the component correctly.
-
-
Once you're confident that your component is getting its props, you can replace every occurrence of Eat with your name prop. Remember: when you're in the middle of a JSX expression, you use curly braces to inject the value of a variable.
-
-
Putting all that together, your Todo() function should read like this:
Now your browser should show three unique tasks. Another problem remains though: they're all still checked by default.
-
-
-
-
Is it completed?
-
-
In our original static list, only Eat was checked. Once again, we want to reuse most of the UI that makes up a <Todo /> component, but change one thing. That's a good job for another prop! Give each <Todo /> call in App.js a new prop of completed. The first (Eat) should have a value of true; the rest should be false:
As before, we must go back to Todo.js to actually use these props. Change the defaultChecked attribute on the <input /> so that its value is equal to the completed prop. Once you’re done, the Todo component's <input /> element will read like this:
And your browser should update to show only Eat being checked:
-
-
-
-
If you change each <Todo /> component’s completed prop, your browser will check or uncheck the equivalent rendered checkboxes accordingly.
-
-
Gimme some id, please
-
-
Right now, our <Todo /> component gives every task an id attribute of todo-0. This is bad HTML because id attributes must be unique (they are used as unique identifiers for document fragments, by CSS, JavaScript, etc.). This means we should give our component an id prop that takes a unique value for each Todo.
-
-
To follow the same pattern we had initially, let's give each instance of the <Todo /> component an ID in the format of todo-i, where i gets larger by one every time:
Now go back to Todo.js and make use of the id prop. It needs to replace the value of the id attribute of the <input /> element, as well as the value of its label's htmlFor attribute:
We’re making good use of React so far, but we could do better! Our code is repetitive. The three lines that render our <Todo /> component are almost identical, with only one difference: the value of each prop.
-
-
We can clean up our code with one of JavaScript's core abilities: iteration. To use iteration, we should first re-think our tasks.
-
-
Tasks as data
-
-
Each of our tasks currently contains three pieces of information: its name, whether it has been checked, and its unique ID. This data translates nicely to an object. Since we have more than one task, an array of objects would work well in representing this data.
-
-
In src/index.js, make a new const beneath the final import, but above ReactDOM.render():
This array is now available to the App component as props.tasks. You can console.log() it to check, if you’d like.
-
-
-
Note: ALL_CAPS constant names have no special meaning in JavaScript; they’re a convention that tells other developers "this data will never change after being defined here”.
-
-
-
Rendering with iteration
-
-
To render our array of objects, we have to turn each one into a <Todo /> component. JavaScript gives us an array method for transforming data into something else: Array.prototype.map().
-
-
Above the return statement of App(), make a new const called taskList and use map() to transform it. Let's start by turning our tasks array into something simple: the name of each task:
This gets us some of the way towards showing all the components again, but we’ve got more work to do: the browser currently renders each task's name as unstructured text. We’re missing our HTML structure — the <li> and its checkboxes and buttons!
-
-
-
-
To fix this, we need to return a <Todo /> component from our map() function — remember that JSX allows us to mix up JavaScript and markup structures! Let's try the following instead of what we have already:
Look again at your app; now our tasks look more like they used to, but they’re missing the names of the tasks themselves. Remember that each task we map over has the id, name, and checked properties we want to pass into our <Todo /> component. If we put that knowledge together, we get code like this:
Now the app looks like it did before, and our code is less repetitive.
-
-
Unique keys
-
-
Now that React is rendering our tasks out of an array, it has to keep track of which one is which in order to render them properly. React tries to do its own guesswork to keep track of things, but we can help it out by passing a key prop to our <Todo /> components. key is a special prop that's managed by React – you cannot use the word key for any other purpose.
-
-
Because keys should be unique, we're going to re-use the id of each task object as its key. Update your taskList constant like so:
You should always pass a unique key to anything you render with iteration. Nothing obvious will change in your browser, but if you do not use unique keys, React will log warnings to your console and your app may behave strangely!
-
-
Componentizing the rest of the app
-
-
Now that we've got our most important component sorted out, we can turn the rest of our app into components. Remembering that components are either obvious pieces of UI, or reused pieces of UI, or both, we can make two more components:
-
-
-
<Form/>
-
<FilterButton/>
-
-
-
Since we know we need both, we can batch some of the file creation work together with a terminal command. Run this command in your terminal, taking care that you're in the root directory of your app:
Do the same things you did to create Form.js inside FilterButton.js, but call the component FilterButton() and copy the HTML for the first button inside the <div> element with the class of filters from App.js into the return statement.
Note: You might notice that we are making the same mistake here as we first made for the <Todo /> component, in that each button will be the same. That’s fine! We’re going to fix up this component later on, in Back to the filter buttons.
-
-
-
Importing all our components
-
-
Let's make use of our new components.
-
-
Add some more import statements to the top of App.js, to import them.
-
-
Then, update the return statement of App() so that it renders our components. When you’re done, App.js will read like this:
With this in place, we’re almost ready to tackle some interactivity in our React app!
-
-
Summary
-
-
And that's it for this article — we've gone into some depth on how to break up your app nicely into components, end render them efficiently. Now we'll go on to look at how we handle events in React, and start adding some interactivity.
diff --git a/files/zh-cn/learn/tools_and_testing/client-side_javascript_frameworks/react_components/index.md b/files/zh-cn/learn/tools_and_testing/client-side_javascript_frameworks/react_components/index.md
new file mode 100644
index 00000000000000..35d74fa0139e7a
--- /dev/null
+++ b/files/zh-cn/learn/tools_and_testing/client-side_javascript_frameworks/react_components/index.md
@@ -0,0 +1,486 @@
+---
+title: Componentizingapp
+slug: Learn/Tools_and_testing/Client-side_JavaScript_frameworks/React_components
+translation_of: Learn/Tools_and_testing/Client-side_JavaScript_frameworks/React_components
+---
+{{LearnSidebar}}{{PreviousMenuNext("Learn/Tools_and_testing/Client-side_JavaScript_frameworks/React_todo_list_beginning","Learn/Tools_and_testing/Client-side_JavaScript_frameworks/React_interactivity_events_state", "Learn/Tools_and_testing/Client-side_JavaScript_frameworks")}}
+
+At this point, our app is a monolith. Before we can make it do things, we need to break it apart into manageable, descriptive components. React doesn’t have any hard rules for what is and isn’t a component – that’s up to you! In this article we will show you a sensible way to break our app up into components.
+
+
+ To show a sensible way of breaking our todo list app into components.
+
+
+
+
+
+## Defining our first component
+
+Defining a component can seem tricky until you have some practice, but the gist is:
+
+- If it represents an obvious "chunk" of your app, it's probably a component
+- If it gets reused often, it's probably a component.
+
+That second bullet is especially valuable: making a component out of common UI elements allows you to change your code in one place and see those changes everywhere that component is used. You don't have to break everything out into components right away, either. Let's take the second bullet point as inspiration and make a component out of the most reused, most important piece of the UI: a todo list item.
+
+## Make a ``
+
+Before we can make a component, we should create a new file for it. In fact, we should make a directory just for our components. The following commands make a `components` directory and then, within that, a file called `Todo.js`. Make sure you're in the root of your app before you run these!
+
+```bash
+mkdir src/components
+touch src/components/Todo.js
+```
+
+Our new `Todo.js` file is currently empty! Open it up and give it its first line:
+
+```js
+import React from "react";
+```
+
+Since we're going to make a component called `Todo`, you can start adding the code for that to `Todo.js` too, as follows. In this code, we define the function and export it on the same line:
+
+```js
+export default function Todo() {
+ return (
+
+ );
+}
+```
+
+This is OK so far, but our component has to return something! Go back to `src/App.js`, copy the first [`
`](/en-US/docs/Web/HTML/Element/li) from inside the unordered list, and paste it into `Todo.js` so that it reads like this:
+
+```js
+export default function Todo() {
+ return (
+
+
+
+
+
+
+
+
+
+
+ );
+}
+```
+
+> **备注：** Components must always return something. If at any point in the future you try to render a component that does not return anything, React will display an error in your browser.
+
+Our `Todo` component is complete, at least for now; now we can use it. In `App.js`, add the following line near the top of the file to import `Todo`:
+
+```js
+import Todo from "./components/Todo";
+```
+
+With this component imported, you can replace all of the `
` elements in `App.js` with `` component calls. Your `
` should read like this:
+
+```js
+
+
+
+
+
+```
+
+When you look back at your browser, you'll notice something unfortunate: your list now repeats the first task three times!
+
+
+
+We don't only want to eat; we have other things to — well — to do. Next we'll look at how we can make different component calls render unique content.
+
+## Make a _unique_ ``
+
+Components are powerful because they let us re-use pieces of our UI, and refer to one place for the source of that UI. The problem is, we don't typically want to reuse all of each component; we want to reuse most parts, and change small pieces. This is where props come in.
+
+### What's in a `name`?
+
+In order to track the names of tasks we want to complete, we should ensure that each `` component renders a unique name.
+
+In `App.js`, give each `` a name prop. Let’s use the names of our tasks that we had before:
+
+```js
+
+
+
+```
+
+When your browser refreshes, you will see… the exact same thing as before. We gave our `` some props, but we aren't using them yet. Let's go back to `Todo.js` and remedy that.
+
+First modify your `Todo()` function definition so that it takes `props` as a parameter. You can `console.log()` your `props` as we did before, if you'd like to check that they are being received by the component correctly.
+
+Once you're confident that your component is getting its `props`, you can replace every occurrence of `Eat` with your `name` prop. Remember: when you're in the middle of a JSX expression, you use curly braces to inject the value of a variable.
+
+Putting all that together, your `Todo()` function should read like this:
+
+```js
+export default function Todo(props) {
+ return (
+
+
+
+
+
+
+
+
+
+
+ );
+}
+```
+
+_Now_ your browser should show three unique tasks. Another problem remains though: they're all still checked by default.
+
+
+
+### Is it `completed`?
+
+In our original static list, only `Eat` was checked. Once again, we want to reuse _most_ of the UI that makes up a `` component, but change one thing. That's a good job for another prop! Give each `` call in `App.js` a new prop of `completed`. The first (`Eat`) should have a value of `true`; the rest should be `false`:
+
+```js
+
+
+
+```
+
+As before, we must go back to `Todo.js` to actually use these props. Change the `defaultChecked` attribute on the `` so that its value is equal to the `completed` prop. Once you’re done, the Todo component's `` element will read like this:
+
+```js
+
+```
+
+And your browser should update to show only `Eat` being checked:
+
+
+
+If you change each `` component’s `completed` prop, your browser will check or uncheck the equivalent rendered checkboxes accordingly.
+
+### Gimme some `id`, please
+
+Right now, our `` component gives every task an `id` attribute of `todo-0`. This is bad HTML because [`id` attributes](/en-US/docs/Web/HTML/Global_attributes/id) must be unique (they are used as unique identifiers for document fragments, by CSS, JavaScript, etc.). This means we should give our component an `id` prop that takes a unique value for each `Todo`.
+
+To follow the same pattern we had initially, let's give each instance of the `` component an ID in the format of `todo-i`, where `i` gets larger by one every time:
+
+```js
+
+
+
+```
+
+Now go back to `Todo.js` and make use of the `id` prop. It needs to replace the value of the `id` attribute of the `` element, as well as the value of its label's `htmlFor` attribute:
+
+```js
+
+
+
+
+```
+
+## So far, so good?
+
+We’re making good use of React so far, but we could do better! Our code is repetitive. The three lines that render our `` component are almost identical, with only one difference: the value of each prop.
+
+We can clean up our code with one of JavaScript's core abilities: iteration. To use iteration, we should first re-think our tasks.
+
+## Tasks as data
+
+Each of our tasks currently contains three pieces of information: its name, whether it has been checked, and its unique ID. This data translates nicely to an object. Since we have more than one task, an array of objects would work well in representing this data.
+
+In `src/index.js`, make a new `const` beneath the final import, but above `ReactDOM.render()`:
+
+```js
+const DATA = [
+ { id: "todo-0", name: "Eat", completed: true },
+ { id: "todo-1", name: "Sleep", completed: false },
+ { id: "todo-2", name: "Repeat", completed: false }
+];
+```
+
+Next, we'll pass `DATA` to `` as a prop, called `tasks`. The final line of `src/index.js` should read like this:
+
+```js
+ReactDOM.render(, document.getElementById("root"));
+```
+
+This array is now available to the App component as `props.tasks`. You can `console.log()` it to check, if you’d like.
+
+> **备注：** `ALL_CAPS` constant names have no special meaning in JavaScript; they’re a convention that tells other developers "this data will never change after being defined here”.
+
+## Rendering with iteration
+
+To render our array of objects, we have to turn each one into a `` component. JavaScript gives us an array method for transforming data into something else: [`Array.prototype.map()`](/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/map).
+
+Above the return statement of `App()`, make a new `const` called `taskList` and use `map()` to transform it. Let's start by turning our `tasks` array into something simple: the `name` of each task:
+
+```js
+const taskList = props.tasks.map(task => task.name);
+```
+
+Let’s try replacing all the children of the `
` with `taskList`:
+
+```js
+
+ {taskList}
+
+```
+
+This gets us some of the way towards showing all the components again, but we’ve got more work to do: the browser currently renders each task's name as unstructured text. We’re missing our HTML structure — the `
` and its checkboxes and buttons!
+
+
+
+To fix this, we need to return a `` component from our `map()` function — remember that JSX allows us to mix up JavaScript and markup structures! Let's try the following instead of what we have already:
+
+```js
+ const taskList = props.tasks.map(task => );
+```
+
+Look again at your app; now our tasks look more like they used to, but they’re missing the names of the tasks themselves. Remember that each task we map over has the `id`, `name`, and `checked` properties we want to pass into our `` component. If we put that knowledge together, we get code like this:
+
+```js
+const taskList = props.tasks.map(task => (
+
+));
+```
+
+Now the app looks like it did before, and our code is less repetitive.
+
+## Unique keys
+
+Now that React is rendering our tasks out of an array, it has to keep track of which one is which in order to render them properly. React tries to do its own guesswork to keep track of things, but we can help it out by passing a `key` prop to our `` components. `key` is a special prop that's managed by React – you cannot use the word `key` for any other purpose.
+
+Because keys should be unique, we're going to re-use the `id` of each task object as its key. Update your `taskList` constant like so:
+
+```js
+const taskList = props.tasks.map(task => (
+
+ )
+);
+```
+
+**You should always pass a unique key to anything you render with iteration.** Nothing obvious will change in your browser, but if you do not use unique keys, React will log warnings to your console and your app may behave strangely!
+
+## Componentizing the rest of the app
+
+Now that we've got our most important component sorted out, we can turn the rest of our app into components. Remembering that components are either obvious pieces of UI, or reused pieces of UI, or both, we can make two more components:
+
+- ``
+- ``
+
+Since we know we need both, we can batch some of the file creation work together with a terminal command. Run this command in your terminal, taking care that you're in the root directory of your app:
+
+```bash
+touch src/components/Form.js src/components/FilterButton.js
+```
+
+### The ``
+
+Open `components/Form.js` and do the following:
+
+- Import `React` at the top of the file, like we did in `Todo.js`.
+- Make yourself a new `Form()` component with the same basic structure as `Todo()`, and export that component.
+- Copy the `
+ );
+}
+
+export default Form;
+```
+
+### The \
+
+Do the same things you did to create `Form.js` inside `FilterButton.js`, but call the component `FilterButton()` and copy the HTML for the first button inside the `
` element with the `class` of `filters` from `App.js` into the `return` statement.
+
+The file should read like this:
+
+```js
+import React from "react";
+
+function FilterButton(props) {
+ return (
+
+ );
+}
+
+export default FilterButton;
+```
+
+> **备注：** You might notice that we are making the same mistake here as we first made for the `` component, in that each button will be the same. That’s fine! We’re going to fix up this component later on, in [Back to the filter buttons](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/React_interactivity_filtering_conditional_rendering#Back_to_the_filter_buttons).
+
+## Importing all our components
+
+Let's make use of our new components.
+
+Add some more `import` statements to the top of `App.js`, to import them.
+
+Then, update the `return` statement of `App()` so that it renders our components. When you’re done, `App.js` will read like this:
+
+```js
+import React from "react";
+import Form from "./components/Form";
+import FilterButton from "./components/FilterButton";
+import Todo from "./components/Todo";
+
+function App(props) {
+ const taskList = props.tasks.map(task => (
+
+ )
+ );
+ return (
+
+
+
+
+
+
+
+
3 tasks remaining
+
+ {taskList}
+
+
+ );
+}
+
+export default App;
+```
+
+With this in place, we’re _almost_ ready to tackle some interactivity in our React app!
+
+## Summary
+
+And that's it for this article — we've gone into some depth on how to break up your app nicely into components, end render them efficiently. Now we'll go on to look at how we handle events in React, and start adding some interactivity.
+
+{{PreviousMenuNext("Learn/Tools_and_testing/Client-side_JavaScript_frameworks/React_todo_list_beginning","Learn/Tools_and_testing/Client-side_JavaScript_frameworks/React_interactivity_events_state", "Learn/Tools_and_testing/Client-side_JavaScript_frameworks")}}
+
+## In this module
+
+- [Introduction to client-side frameworks](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Introduction)
+- [Framework main features](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Main_features)
+- React
+
+ - [Getting started with React](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/React_getting_started)
+ - [Beginning our React todo list](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/React_todo_list_beginning)
+ - [Componentizing our React app](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/React_components)
+ - [React interactivity: Events and state](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/React_interactivity_events_state)
+ - [React interactivity: Editing, filtering, conditional rendering](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/React_interactivity_filtering_conditional_rendering)
+ - [Accessibility in React](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/React_accessibility)
+ - [React resources](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/React_resources)
+
+- Ember
+
+ - [Getting started with Ember](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Ember_getting_started)
+ - [Ember app structure and componentization](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Ember_structure_componentization)
+ - [Ember interactivity: Events, classes and state](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Ember_interactivity_events_state)
+ - [Ember Interactivity: Footer functionality, conditional rendering](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Ember_conditional_footer)
+ - [Routing in Ember](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Ember_routing)
+ - [Ember resources and troubleshooting](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Ember_resources)
+
+- Vue
+
+ - [Getting started with Vue](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Vue_getting_started)
+ - [Creating our first Vue component](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Vue_first_component)
+ - [Rendering a list of Vue components](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Vue_rendering_lists)
+ - [Adding a new todo form: Vue events, methods, and models](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Vue_methods_events_models)
+ - [Styling Vue components with CSS](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Vue_styling)
+ - [Using Vue computed properties](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Vue_computed_properties)
+ - [Vue conditional rendering: editing existing todos](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Vue_conditional_rendering)
+ - [Focus management with Vue refs](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Vue_refs_focus_management)
+ - [Vue resources](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Vue_resources)
+
+- Svelte
+
+ - [Getting started with Svelte](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Svelte_getting_started)
+ - [Starting our Svelte Todo list app](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Svelte_Todo_list_beginning)
+ - [Dynamic behavior in Svelte: working with variables and props](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Svelte_variables_props)
+ - [Componentizing our Svelte app](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Svelte_components)
+ - [Advanced Svelte: Reactivity, lifecycle, accessibility](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Svelte_reactivity_lifecycle_accessibility)
+ - [Working with Svelte stores](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Svelte_stores)
+ - [TypeScript support in Svelte](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Svelte_TypeScript)
+ - [Deployment and next steps](/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Svelte_deployment_next)
diff --git a/files/zh-cn/learn/tools_and_testing/client-side_javascript_frameworks/react_getting_started/index.html b/files/zh-cn/learn/tools_and_testing/client-side_javascript_frameworks/react_getting_started/index.html
deleted file mode 100644
index c701d9690eb5ee..00000000000000
--- a/files/zh-cn/learn/tools_and_testing/client-side_javascript_frameworks/react_getting_started/index.html
+++ /dev/null
@@ -1,480 +0,0 @@
----
-title: React 入门
-slug: >-
- Learn/Tools_and_testing/Client-side_JavaScript_frameworks/React_getting_started
-tags:
- - JavaScript
- - React
- - 初学者
- - 学习
- - 客户端
- - 框架
-translation_of: >-
- Learn/Tools_and_testing/Client-side_JavaScript_frameworks/React_getting_started
----
-
表达式中的元素就像以前写的 HTML 一样，都拥有属性，并且遵循 attribute="value" 的模式。在第三行，开始标签 <div> 有着 className 属性。这个属性与在 HTML 中的 class 属性相同，但是由于 JSX 就是 JavaScript, 我们不能使用 class 属性 - 这个是关键字，意味着 JavaScript 已经用它执行其它任务，使用 class 属性将会在我们的代码中产生冲突。由于同样的原因，一些其它的 HTML 属性在 JSX 中也有着不同的书写方式，当我们碰到它们时，我们将会详述。
import React from 'react';
-import ReactDOM from 'react-dom';
-import './index.css';
-import App from './App';
-import * as serviceWorker from './serviceWorker';
-
-ReactDOM.render(<App />, document.getElementById('root'));
-
-// If you want your app to work offline and load faster, you can change
-// unregister() to register() below. Note this comes with some pitfalls.
-// Learn more about service workers: https://bit.ly/CRA-PWA
-serviceWorker.unregister();
+ 
+ 
