Gandalf The Blue

怎样使用React Testing Library

Jest vs React Testing Library

React初学者经常混淆在React中进行测试的工具。React Testing库不是Jest的替代品，因为它们彼此需要，并且它们每一个都有明确的任务。

describe-block是测试套件，而test-block（也可以it代替命名test）是测试用例。一个测试套件可以具有多个测试用例，而一个测试用例不必位于一个测试套件中。放入测试用例中的内容称为断言（例如，expect在Jest中），证明是成功的（绿色）或错误的（红色）。这里有两个断言应该成功：

describe('true is truthy and false is falsy', () => {
  test('true is truthy', () => {
    expect(true).toBe(true);
  });

  test('false is falsy', () => {
    expect(false).toBe(false);
  });
});

如果您使用的是create-react-app，则默认情况下Jest（和React Testing库）随安装一起提供。如果您使用自定义的React设置，则需要自己安装和设置Jest（和React Testing库）。

一旦通过Jest的测试运行程序npm test（或您在package.json中使用的任何脚本）运行测试，您将看到两个先前定义的测试的以下输出：

 PASS  src/App.test.js
  true is truthy and false is falsy
    ✓ true is truthy (3ms)
    ✓ false is falsy

Test Suites: 1 passed, 1 total
Tests:       2 passed, 2 total
Snapshots:   0 total
Time:        2.999s
Ran all test suites related to changed files.

Watch Usage
 › Press a to run all tests.
 › Press f to run only failed tests.
 › Press q to quit watch mode.
 › Press p to filter by a filename regex pattern.
 › Press t to filter by a test name regex pattern.
 › Press Enter to trigger a test run.

React Testing Library: 渲染一个组件

如果您使用的是create-react-app，则默认情况下将存在React Testing库。如果您使用自定义的React设置（例如，React with Webpack）或其他React框架，则需要自己安装。

import React from 'react';

const title = 'Hello React';

function App() {
  return <div>{title}</div>;
}

export default App;

import React from 'react';
import { render } from '@testing-library/react';

import App from './App';

describe('App', () => {
  test('renders App component', () => {
    render(<App />);
  });
});

RTL的render函数可以对任何JSX进行渲染。之后，您应该可以在测试中访问React组件。为了使自己确信它已经存在，可以使用RTL的调试功能：

import React from 'react';
import { render, screen } from '@testing-library/react';
import App from './App';

describe('App', () => {
  test('renders App component', () => {
    render(<App />);

    screen.debug();  });
});

<body>
  <div>
    <div>
      Hello React
    </div>
  </div>
</body>

很棒的一点是，React Testing库并不在乎实际的组件。让我们来看一下以下利用不同React功能（useState，event handler，props）和概念（受控组件）的React 组件：

import React from 'react';

function App() {
  const [search, setSearch] = React.useState('');

  function handleChange(event) {
    setSearch(event.target.value);
  }

  return (
    <div>
      <Search value={search} onChange={handleChange}>
        Search:
      </Search>

      <p>Searches for {search ? search : '...'}</p>
    </div>
  );
}

function Search({ value, onChange, children }) {
  return (
    <div>
      <label htmlFor="search">{children}</label>
      <input
        id="search"
        type="text"
        value={value}
        onChange={onChange}
      />
    </div>
  );
}

export default App;

<body>
  <div>
    <div>
      <div>
        <label
          for="search"
        >
          Search:
        </label>
        <input
          id="search"
          type="text"
          value=""
        />
      </div>
      <p>
        Searches for
        ...
      </p>
    </div>
  </div>
</body>

React Testing库用于像人类一样与您的React组件进行交互。人们看到的只是从React组件渲染的HTML，因此这就是为什么您将此HTML结构视为输出而不是两个单独的React组件的原因。

React Testing Library: 选择元素

渲染了React组件之后，React Testing库为您提供了不同的搜索功能来抓取元素。这些元素然后用于断言或用户交互：

import React from 'react';
import { render, screen } from '@testing-library/react';

import App from './App';

describe('App', () => {
  test('renders App component', () => {
    render(<App />);

    screen.getByText('Search:');  });
});

如果您真的不知道RTL渲染函数的渲染输出是什么，请始终使用RTL的调试函数。了解HTML结构之后，就可以开始使用RTL的屏幕对象功能选择元素。然后可以将所选元素用于用户交互或声明。我们将执行一个断言，检查该元素是否在DOM中：

import React from 'react';
import { render, screen } from '@testing-library/react';

import App from './App';

describe('App', () => {
  test('renders App component', () => {
    render(<App />);

    expect(screen.getByText('Search:')).toBeInTheDocument();  });
});

如果该元素不能被发现，getByText默认会抛出一个错误。这有助于在编写测试时提示您首先需要编写所选元素。少数人利用此行为来作为搜索函数，例如getByText隐式断言替换，而不是使用的显式断言expect：

import React from 'react';
import { render, screen } from '@testing-library/react';

import App from './App';

describe('App', () => {
  test('renders App component', () => {
    render(<App />);

    // implicit assertion    // because getByText would throw error    // if element wouldn't be there    screen.getByText('Search:');
    // explicit assertion    // recommended    expect(screen.getByText('Search:')).toBeInTheDocument();  });
});

getByText函数接受一个字符串作为输入，就像我们现在正在使用的那样，它也可以接受一个正则表达式。字符串参数用于完全匹配，而正则表达式可用于部分匹配，这通常更方便：

import React from 'react';
import { render, screen } from '@testing-library/react';

import App from './App';

describe('App', () => {
  test('renders App component', () => {
    render(<App />);

    // fails    expect(screen.getByText('Search')).toBeInTheDocument();
    // succeeds    expect(screen.getByText('Search:')).toBeInTheDocument();
    // succeeds    expect(screen.getByText(/Search/)).toBeInTheDocument();  });
});

React Testing Library: 搜索类型

您已经了解了getByText其中的Text是几个搜索类型之一。尽管Text通常是React Testing Library中选择元素的常用方法，但另一个强项是Role与getByRole。

getByRole函数通常用于通过aria-label属性检索元素。但是，HTML元素上也存在隐式角色 -例如按钮元素的按钮。因此，您不仅可以通过可见文本来选择元素，还可以通过React Testing库中的元素可访问性角色来选择元素。getByText和getByRole是RTL使用最广泛的搜索功能。

import React from 'react';
import { render, screen } from '@testing-library/react';

import App from './App';

describe('App', () => {
  test('renders App component', () => {
    render(<App />);

    screen.getByRole('');
  });
});

这意味着先前的测试在运行后将以下内容输出到命令行：

Unable to find an accessible element with the role ""

Here are the accessible roles:

document:

Name "":
<body />

--------------------------------------------------
textbox:

Name "Search:":
<input
  id="search"
  type="text"
  value=""
/>

--------------------------------------------------

由于HTML元素的隐式作用，我们至少有一个文本框（<input />）元素，可以使用以下搜索类型进行检索：

import React from 'react';
import { render, screen } from '@testing-library/react';

import App from './App';

describe('App', () => {
  test('renders App component', () => {
    render(<App />);

    expect(screen.getByRole('textbox')).toBeInTheDocument();
  });
});

为了进行测试，通常不必为HTML元素显式分配aria角色，因为DOM已经具有附加到HTML元素的隐式角色。

还有其他更特定于元素的搜索类型：

LabelText: getByLabelText: <label for="search" />
PlaceholderText: getByPlaceholderText: <input placeholder="Search" />
AltText: getByAltText: <img alt="profile" />
DisplayValue: getByDisplayValue: <input value="JavaScript" />

最后一种搜索类型为TestId，getByTestId需要data-testid在源ID的HTML中分配属性。

getByText
getByRole
getByLabelText
getByPlaceholderText
getByAltText
getByDisplayValue

同样，这些都是RTL中可用的所有不同搜索类型。

React Testing Library: 搜索变体(Search Variants)

与搜索类型相反，还存在搜索变体。React Testing库中的搜索变体之一是getBy，它用于getByText或getByRole。这也是在测试React组件时默认使用的搜索变量。

其他两个搜索变体是queryBy和findBy；两者都可以通过getBy可以访问的相同搜索类型进行扩展。例如，queryBy及其所有搜索类型：

queryByText
queryByRole
queryByLabelText
queryByPlaceholderText
queryByAltText
queryByDisplayValue

而findBy及其所有搜索类型：

findByText
findByRole
findByLabelText
findByPlaceholderText
findByAltText
findByDisplayValue

getBy和queryBy有什么区别？

何时使用getBy以及何时使用其他两个变体queryBy和findBy。您已经知道getBy返回一个元素或错误。getBy返回错误是一个方便的副作用，因为它可以确保作为开发人员的我们尽早注意到测试中存在错误。但是，这使得很难检查不应该存在的元素：

import React from 'react';
import { render, screen } from '@testing-library/react';

import App from './App';

describe('App', () => {
  test('renders App component', () => {
    render(<App />);

    screen.debug();

    // fails
    expect(screen.getByText(/Searches for JavaScript/)).toBeNull();
  });
});

这是行不通的，因为即使调试输出显示不存在带有“ Searches for JavaScript”文本的元素，getBy也会在我们进行断言之前引发错误，因为它无法找到带有该文本的元素。为了声明不存在的元素，我们可以将getBy与queryBy交换：

import React from 'react';
import { render, screen } from '@testing-library/react';

import App from './App';

describe('App', () => {
  test('renders App component', () => {
    render(<App />);

    expect(screen.queryByText(/Searches for JavaScript/)).toBeNull();
  });
});

因此，每当您断言某个元素不存在时，请使用queryBy。否则默认为getBy。那么findBy呢？

何时使用findBy？

findBy搜索变体用于最终将会出现的异步元素：

function getUser() {  return Promise.resolve({ id: '1', name: 'Robin' });}
function App() {
  const [search, setSearch] = React.useState('');
  const [user, setUser] = React.useState(null);
  React.useEffect(() => {    const loadUser = async () => {      const user = await getUser();      setUser(user);    };    loadUser();  }, []);
  function handleChange(event) {
    setSearch(event.target.value);
  }

  return (
    <div>
      {user ? <p>Signed in as {user.name}</p> : null}
      <Search value={search} onChange={handleChange}>
        Search:
      </Search>

      <p>Searches for {search ? search : '...'}</p>
    </div>
  );
}

因为我们必须等待promise异步解析，这里必须编写异步测试。换句话说，在提取组件之后，我们必须等待用户在渲染一次之后进行渲染：

import React from 'react';
import { render, screen } from '@testing-library/react';

import App from './App';

describe('App', () => {
  test('renders App component', async () => {    render(<App />);

    expect(screen.queryByText(/Signed in as/)).toBeNull();
    expect(await screen.findByText(/Signed in as/)).toBeInTheDocument();  });
});

在其初始渲染之后，我们断言通过使用queryBy而不是getBy搜索变量，“Signed in as”文本不存在。然后，我们等待新的元素被发现，并且当异步返回并且组件再次重新渲染后，它将最终被发现。

import React from 'react';
import { render, screen } from '@testing-library/react';

import App from './App';

describe('App', () => {
  test('renders App component', async () => {
    render(<App />);

    expect(screen.queryByText(/Signed in as/)).toBeNull();

    screen.debug();
    expect(await screen.findByText(/Signed in as/)).toBeInTheDocument();

    screen.debug();  });
});

对于尚不存在但最终将存在的任何元素，请使用findBy。如果断言缺少元素，请使用queryBy。否则默认为getBy。

多个元素呢？

您已经了解了三种搜索变体getBy，queryBy和findBy；所有这些都可以与搜索类型相关联（例如，文本，角色，PlaceholderText，DisplayValue）。如果所有这些搜索功能仅返回一个元素，那么如何断言是否存在多个元素（例如React组件中的列表）。所有搜索变体都可以使用All单词扩展：

getAllBy
queryAllBy
findAllBy

它们都都返回一个元素数组，并且可以再次与搜索类型相关联。

断言函数

在先前的测试中，您使用了两个断言函数：toBeNull和toBeInTheDocument。两者都主要在React Testing Library中用于检查元素是否存在。

通常，所有这些断言函数都来自Jest。但是，React Testing库使用自己的断言函数（如toBeInTheDocument）扩展了此API。所有这些断言函数都包含在一个额外的程序包中，在使用create-react-app时已为您设置了这些程序包。

toBeDisabled
toBeEnabled
toBeEmpty
toBeEmptyDOMElement
toBeInTheDocument
toBeInvalid
toBeRequired
toBeValid
toBeVisible
toContainElement
toContainHTML
toHaveAttribute
toHaveClass
toHaveFocus
toHaveFormValues
toHaveStyle
toHaveTextContent
toHaveValue
toHaveDisplayValue
toBeChecked
toBePartiallyChecked
toHaveDescription

React Testing Library: 触发事件

到目前为止，我们仅测试了是否使用getBy（和queryBy）在React组件中渲染（或不渲染）元素，以及重新渲染的React组件是否具有所需元素（findBy）。实际的用户交互如何？如果用户在输入字段中键入内容，则组件可能会重新呈现（例如在我们的示例中），并且应该显示（或在某处使用）新值。

我们可以使用RTL的fireEvent函数来模拟最终用户的交互。让我们看看这对我们的输入字段如何起作用：

import React from 'react';
import { render, screen, fireEvent } from '@testing-library/react';
import App from './App';

describe('App', () => {
  test('renders App component', () => {
    render(<App />);

    screen.debug();
    fireEvent.change(screen.getByRole('textbox'), {      target: { value: 'JavaScript' },    });
    screen.debug();  });
});

fireEvent函数采用一个元素（此处为按文本框角色的输入字段）和一个事件（此处为值为“ JavaScript”的事件）。调试函数的输出应显示事件前后的HTML结构；并且您应该看到输入字段的新值已正确呈现。

另外，如果您的组件涉及异步任务（例如我们的App组件，因为它获取用户），您可能会看到以下警告：Warning: An update to App inside a test was not wrapped in act(...).。对我们来说，这意味着正在发生一些异步任务，我们需要确保我们的组件能够处理它。通常这可以使用RTL的act函数来完成，但是这次我们只需要等待用户解决：

describe('App', () => {
  test('renders App component', async () => {    render(<App />);

    // wait for the user to resolve    // needs only be used in our special case    await screen.findByText(/Signed in as/);
    screen.debug();

    fireEvent.change(screen.getByRole('textbox'), {
      target: { value: 'JavaScript' },
    });

    screen.debug();
  });
});

之后，我们可以在事件发生之前和之后进行断言：

describe('App', () => {
  test('renders App component', async () => {
    render(<App />);

    // wait for the user to resolve
    // needs only be used in our special case
    await screen.findByText(/Signed in as/);

    expect(screen.queryByText(/Searches for JavaScript/)).toBeNull();
    fireEvent.change(screen.getByRole('textbox'), {
      target: { value: 'JavaScript' },
    });

    expect(screen.getByText(/Searches for JavaScript/)).toBeInTheDocument();  });
});

React Testing Library: 用户事件

React Testing Library带有扩展的用户事件库，该库建立在fireEvent API之上。以前，我们使用fireEvent触发用户交互。这次我们将使用userEvent作为替代，因为userEvent API比fireEvent API更接近于实际的浏览器行为。例如，fireEvent.change()仅触发了change事件而userEvent.type触发一个change事件，而且keyDown，keyPress和keyUp事件。

import React from 'react';
import { render, screen } from '@testing-library/react';import userEvent from '@testing-library/user-event';
import App from './App';

describe('App', () => {
  test('renders App component', async () => {
    render(<App />);

    // wait for the user to resolve
    await screen.findByText(/Signed in as/);

    expect(screen.queryByText(/Searches for JavaScript/)).toBeNull();

    await userEvent.type(screen.getByRole('textbox'), 'JavaScript');
    expect(
      screen.getByText(/Searches for JavaScript/)
    ).toBeInTheDocument();
  });
});

在使用React测试库时，请尽可能在fireEvent上使用userEvent。

React Testing Library: Callback Handlers

Sometimes you will test React components in isolation as unit tests. Often these components will not have any side-effects or state, but only input (props) and output (JSX, callback handlers). We have already seen how we can test the rendered JSX given a component and props. Now we will test callback handlers for this Search component:

function Search({ value, onChange, children }) {
  return (
    <div>
      <label htmlFor="search">{children}</label>
      <input
        id="search"
        type="text"
        value={value}
        onChange={onChange}
      />
    </div>
  );
}

All the rendering and asserting happens as before. However, this time we are using a utility from Jest to mock the onChange function which is passed to the component. Then, after triggering the user interaction on the input field, we can assert that the onChange callback function has been called:

describe('Search', () => {
  test('calls the onChange callback handler', () => {
    const onChange = jest.fn();

    render(
      <Search value="" onChange={onChange}>
        Search:
      </Search>
    );

    fireEvent.change(screen.getByRole('textbox'), {
      target: { value: 'JavaScript' },
    });

    expect(onChange).toHaveBeenCalledTimes(1);
  });
});

Here again, we can see how userEvent matches the user behavior in the browser more closely as fireEvent. While fireEvent executes the change event by only calling the callback function once, userEvent triggers it for every key stroke:

describe('Search', () => {
  test('calls the onChange callback handler', async () => {    const onChange = jest.fn();

    render(
      <Search value="" onChange={onChange}>
        Search:
      </Search>
    );

    await userEvent.type(screen.getByRole('textbox'), 'JavaScript');
    expect(onChange).toHaveBeenCalledTimes(10);  });
});

Anyway, React Testing Library encourages you to test your React components not too much in isolation, but in integration (integration test) with other components. Only this way you can actually test whether state changes were applied in the DOM and whether side-effects took effect.

React Testing Library: Asynchronous / Async

We have seen before how we can use async await when testing with React Testing Library in order to wait for certain elements to appear with the findBy search variant. Now we will go through a small example for testing data fetching in React. Let’s take the following React component which uses axios for fetching data from a remote API:

import React from 'react';
import axios from 'axios';

const URL = 'http://hn.algolia.com/api/v1/search';

function App() {
  const [stories, setStories] = React.useState([]);
  const [error, setError] = React.useState(null);

  async function handleFetch(event) {
    let result;

    try {
      result = await axios.get(`${URL}?query=React`);

      setStories(result.data.hits);
    } catch (error) {
      setError(error);
    }
  }

  return (
    <div>
      <button type="button" onClick={handleFetch}>
        Fetch Stories
      </button>

      {error && <span>Something went wrong ...</span>}

      <ul>
        {stories.map((story) => (
          <li key={story.objectID}>
            <a href={story.url}>{story.title}</a>
          </li>
        ))}
      </ul>
    </div>
  );
}

export default App;

On button click, we are fetching a list of stories from the Hacker News API. If everything goes right, we will see the list of stories rendered as list in React. If something goes wrong, we will see an error. The test for the App component would look like the following:

import React from 'react';
import axios from 'axios';
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';

import App from './App';

jest.mock('axios');

describe('App', () => {
  test('fetches stories from an API and displays them', async () => {
    const stories = [
      { objectID: '1', title: 'Hello' },
      { objectID: '2', title: 'React' },
    ];

    axios.get.mockImplementationOnce(() =>
      Promise.resolve({ data: { hits: stories } })
    );

    render(<App />);

    await userEvent.click(screen.getByRole('button'));

    const items = await screen.findAllByRole('listitem');

    expect(items).toHaveLength(2);
  });
});

Before we render the App component, we make sure that the API gets mocked. In our case, axios’ return value from its get method gets mocked. However, if you are using another library or the browser’s native fetch API for data fetching, you would have to mock these.

After mocking the API and rendering the component, we use the userEvent API to click to the button which leads us to the API request. Since the request is asynchronous, we have to wait for the component to update. As before, we are using RTL’s findBy search variant to wait for element(s) which appear eventually.

import React from 'react';
import axios from 'axios';
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';

import App from './App';

jest.mock('axios');

describe('App', () => {
  test('fetches stories from an API and displays them', async () => {
    ...
  });

  test('fetches stories from an API and fails', async () => {    axios.get.mockImplementationOnce(() =>      Promise.reject(new Error())    );    render(<App />);    await userEvent.click(screen.getByRole('button'));    const message = await screen.findByText(/Something went wrong/);    expect(message).toBeInTheDocument();  });});

This last test shows you how to test an API request from your React component that fails. Instead of mocking the API with a promise that resolves successfully, we reject the promise with an error. After rendering the component and clicking the button, we wait for the error message to show up.

import React from 'react';
import axios from 'axios';
import { render, screen, act } from '@testing-library/react';import userEvent from '@testing-library/user-event';

import App from './App';

jest.mock('axios');

describe('App', () => {
  test('fetches stories from an API and displays them', async () => {
    const stories = [
      { objectID: '1', title: 'Hello' },
      { objectID: '2', title: 'React' },
    ];

    const promise = Promise.resolve({ data: { hits: stories } });
    axios.get.mockImplementationOnce(() => promise);
    render(<App />);

    await userEvent.click(screen.getByRole('button'));

    await act(() => promise);
    expect(screen.getAllByRole('listitem')).toHaveLength(2);  });

  test('fetches stories from an API and fails', async () => {
    ...
  });
});

For the sake of completeness, this last test shows you how to await a promise in a more explicit way which also works if you don’t want to wait for a HTML to show up.

After all, it’s not too difficult to test async behavior in React with React Testing Library. You have to use Jest for mocking external modules (here remote API), and then just await data or re-renders of your React components in your tests.

React Testing Library is my go-to test library for React components. I have used Enzyme by Airbnb all the way before, but I like how React Testing Library moves you towards testing user behavior and not implementation details. You are testing whether your user can use your application by writing tests that resemble true user scenarios.

(This is an article posted to my blog at overreacted.io. You can read it online by clicking here.)

2020年编写React组件(hooks)的五个常见错误

原文链接: Five common mistakes writing react components (with hooks) in 2020

`本文是关于我发现的编写React组件时最常见的错误，为什么它们是错误以及如何避免或修复它们。`

作为框架的React

React出现在在Web开发领域已经有一段时间了，近年来它作为敏捷Web开发工具的地位稳步增强。特别是在宣布并发布了新的hook API/概念之后，编写组件从未如此简单。

尽管React背后的团队和庞大的社区力量试图以令人印象深刻的方式培训和解释框架的概念，但我仍然看到使用该框架时遇到的一些陷阱和常见错误。我记录了过去几年中我看到的所有与React相关的错误，尤其是React Hooks相关的。在本文中，我想向您展示最常见的错误，并且还将尝试详细解释为什么我认为它们是错误，并提出了以更简洁的方式进行编码的建议。

免责声明

在我们开始之前，我必须说明下面列出的大多数事情都不是根本性的错误或者乍一看甚至看不出错误，而且大多数也不大可能影响应用的性能或外观。除了从事该产品的开发人员外，也许没人会注意到这里有些问题，但是我仍然相信，高质量的代码可以带来更好的开发体验，从而带来更好的产品。

与任何软件框架或库一样，对一个问题总有数百万种不同的意见。您在此处看到的所有内容都是基于我的个人观点，不应视为一般规则。如果您对此有不同的看法，我洗耳恭听。🌟

1. 在不需要重新渲染的地方使用useState

React的核心概念之一是处理状态。您可以通过状态控制整个数据流和渲染。每次重新渲染树时，它很可能与状态变化有关。

通过useState hook，现在可以在函数组件中定义状态，这是一种在React中处理状态的非常整洁而简便的方法。但正如我们在以下示例中看到的那样，它也可能被错误使用。

对于下一个示例，我们需要一些说明，假设我们有两个按钮，一个按钮是计数器，另一个按钮使用当前计数发送API请求或触发操作。不过，当前计数永远不会在组件内展示。仅当单击第二个按钮时才需要该计数来发送API请求。

这很危险 ❌

function ClickButton(props) {
  const [count, setCount] = useState(0);

  const onClickCount = () => {
    setCount((c) => c + 1);
  };

  const onClickRequest = () => {
    apiCall(count);
  };

  return (
    <div>
      <button onClick={onClickCount}>Counter</button>
      <button onClick={onClickRequest}>Submit</button>
    </div>
  );
}

问题所在 ⚡

乍一看，您可能会问这到底有什么问题？不正是这样维护状态吗？是的您是对的，上面的代码可以正常地运行并且可能永远不会有问题，但是在React中，每次状态更改都会对该组件及其子组件进行重新渲染。但是在上面的示例中我们从未在组件渲染中使用该状态，所以每次设置计数器时都会导致不必要的渲染，这可能会影响性能或产生意外的副作用。

解决办法 ✅

如果要在组件内部使用一个变量，并且在不同的渲染中保持该变量的值，同时变量值的改变又不会强制组件重新渲染，则可以使用useRef hook。它可以保持变量值，但不会强制重新渲染组件。

function ClickButton(props) {
  const count = useRef(0);

  const onClickCount = () => {
    count.current++;
  };

  const onClickRequest = () => {
    apiCall(count.current);
  };

  return (
    <div>
      <button onClick={onClickCount}>Counter</button>
      <button onClick={onClickRequest}>Submit</button>
    </div>
  );
}

2. 使用router.push代替Link

这可能是一个简单以及非常容易发现的问题并且和React本身并没有真正的联系，但是当人们编写React组件时，我仍然常常发现这种写法。

假设创建一个按钮，单击该按钮用户将被重定向到另一个页面。由于应用是SPA，所以该操作将是客户端路由机制。因此我们将需要某种库来执行客户端路由操作。在React生态中，最受欢迎的是路由库是react-router，下面的示例将使用该库。

所以只要添加点击事件回调就会将用户重定向到所需的页面，对吗？

这很危险 ❌

function ClickButton(props) {
  const history = useHistory();

  const onClick = () => {
    history.push('/next-page');
  };

  return <button onClick={onClick}>Go to next page</button>;
}

问题所在 ⚡

即使上面的代码对于大多数用户来说都可以正常工作，但这里的可访问性(accessibility)仍然存在巨大的问题。该按钮根本不会被标记为到另一个页面的链接，这使得屏幕阅读器几乎无法识别该按钮。另外试试在新标签页或窗口中打开这个链接？很可能不会成功。

解决办法 ✅

与用户交互的跳转到其他页面的任何链接应尽可能由<Link>组件或常规的<a>标签处理。

function ClickButton(props) {
  return (
    <Link to="/next-page">
      <span>Go to next page</span>
    </Link>
  );
}

额外收获: 代码更简洁，更具可读性。

3. 使用useEffect处理Actions

React引入的最好，思虑最周到的hook之一是”useEffect” hook。它可以处理与prop或state变更相关的actions。 useEffect非常有用，但也经常在可能不需要它的地方被使用。

想象有一个组件，该组件会请求商品列表并将其渲染到dom。另外，如果请求成功，将调用”onSuccess”函数。该函数作为prop传递给了该组件。

这很危险 ❌

function DataList({ onSuccess }) {
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState(null);
  const [data, setData] = useState(null);

  const fetchData = useCallback(() => {
    setLoading(true);
    callApi()
      .then((res) => setData(res))
      .catch((err) => setError(err))
      .finally(() => setLoading(false));
  }, []);

  useEffect(() => {
    fetchData();
  }, [fetchData]);

  useEffect(() => {
    if (!loading && !error && data) {
      onSuccess();
    }
  }, [loading, error, data, onSuccess]);

  return <div>Data: {data}</div>;
}

问题所在 ⚡

组件一共有两个useEffect hook，第一个在初次渲染时处理api调用，第二个在loading结束，没有错误并且状态中有数据的情况下调用onSuccess函数。这一定是一次成功的调用。看起来很有道理吧？

可以肯定的是对于第一次调用这是没有问题的，并且可能永远不会失败。但是，我们也失去了action和需要被调用的函数之间的直接联系。另外我们不能100%保证在fetch操作成功后这种情况才会发生，而这正是我们开发人员所讨厌的。

解决办法 ✅

一个直接的解决方案是将”onSuccess”函数的调用设在fetch成功后的位置：

function DataList({ onSuccess }) {
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState(null);
  const [data, setData] = useState(null);

  const fetchData = useCallback(() => {
    setLoading(true);
    callApi()
      .then((fetchedData) => {
        setData(fetchedData);
        onSuccess();
      })
      .catch((err) => setError(err))
      .finally(() => setLoading(false));
  }, [onSuccess]);

  useEffect(() => {
    fetchData();
  }, [fetchData]);

  return <div>{data}</div>;
}

现在何时调用了onSuccess一目了然，确切地说是在api调用成功的情况下。

4. 单一职责的组件

构造组件有时候是困难的。在什么时候应该将一个组件拆分为几个较小的组件呢？应该如何构造组件树呢？当我们使用基于组件的框架时，每天都会出现上述问题。但是，设计组件时常见的错误是将两个用例组合到一个组件中。让我们以标题为例，该标题在移动设备上显示汉堡按钮或在桌面web端显示标签。（切换条件将由神奇的isMobile函数处理，这不是本示例的一部分🧙‍）

这很危险 ❌

function Header(props) {
  return (
    <header>
      <HeaderInner menuItems={menuItems} />
    </header>
  );
}

function HeaderInner({ menuItems }) {
  return isMobile() ? <BurgerButton menuItems={menuItems} /> : <Tabs tabData={menuItems} />;
}

问题所在 ⚡

通过这种分支条件，HeaderInner组件试图同时处理两种不同的业务逻辑，我们都从Jekyll先生那里获悉，一心二用是不好的事情。而且，这使得测试或在其他地方复用该组件变得更加困难。

解决办法 ✅

将分支条件往上提升一级，使得可以更轻松地展示组件的用途，并且它们仅负责一件事情，即Header只能是Tab或者BurgerButton，而不是尝试同时做两件事。

function Header(props) {
  return (
    <header>{isMobile() ? <BurgerButton menuItems={menuItems} /> : <Tabs tabData={menuItems} />}</header>
  );
}

4. 单一职责的useEffects

还记得在hooks发布之前，我们只有通过componentWillReceiveProps或componentDidUpdate方法衔接到React组件的渲染过程中吗？对我来说这是黑暗的记忆同时也让我意识到使用useEffect hook的美妙之处，尤其是可以随意使用它们。

但是有时的粗心大意并让一个”useEffect”同时做几件事会带回那些黑暗的回忆。例如，假设您有一个组件以某种方式从后端获取一些数据，并且还根据当前位置显示面包屑。（再次使用react-router来获取当前位置。）

这很危险 ❌

function Example(props) {
  const location = useLocation();

  const fetchData = useCallback(() => {
    /*  Calling the api */
  }, []);

  const updateBreadcrumbs = useCallback(() => {
    /* Updating the breadcrumbs*/
  }, []);

  useEffect(() => {
    fetchData();
    updateBreadcrumbs();
  }, [location.pathname, fetchData, updateBreadcrumbs]);

  return (
    <div>
      <BreadCrumbs />
    </div>
  );
}

问题所在 ⚡

这里有两个业务逻辑，即“数据获取”和“显示面包屑”。两者都通过useEffect来进行更新。当fetchData和updateBreadcrumbs函数或location更改时，将重新运行这个useEffect hooks。现在的主要问题是，当location更改时，我们会重新调用fetchData函数。这可能是我们没有想到的副作用。

解决办法 ✅

拆分useEffect可确保每个effect仅作用于单一的副作用，这可以使没有预料到的副作用不再出现。

function Example(props) {
  const location = useLocation();

  const updateBreadcrumbs = useCallback(() => {
    /* Updating the breadcrumbs*/
  }, []);

  useEffect(() => {
    updateBreadcrumbs();
  }, [location.pathname, updateBreadcrumbs]);

  const fetchData = useCallback(() => {
    /*  Calling the api */
  }, []);

  useEffect(() => {
    fetchData();
  }, [fetchData]);

  return (
    <div>
      <BreadCrumbs />
    </div>
  );
}

额外收获: 现在业务逻辑也在组件内被有序的分类排列了。

总结

在React中编写组件时有很多陷阱。我们不可能百分百地了解整个运行机制并避免每一个小的甚至大的错误。但是在学习框架或编程语言时犯错误也很重要，可能没有人会100％摆脱这些错误。

我认为与他人分享您的经验可能对其他人非常有帮助，或许可以帮助他们减少错误的发生。

如果您有任何疑问或认为这不是一个错误，请写信给我，我很想听听您的意见。

(This is an article posted to my blog at overreacted.io. You can read it online by clicking here.)

let还是const

原文链接On let vs const

我的上一篇文章包括下面这段话:

let vs const vs var: 通常你会选择 let。如果要禁止给变量重新赋值, 则可以使用 const. (有些代码库和程序员比较教条主义，当变量只赋值一次时，会强迫使用 const。)

事实证明这是非常有争议的，引发了Twitter和Reddit上的激烈讨论。似乎大多数人的观点（或至少是最明确表达的观点）是，应尽可能使用 const，只有在需要时才使用 let，并且可以使用 prefer-const ESLint规则来强制执行。

在本文中，我将简要总结我遇到的一些支持论点和反驳论点，以及我对该话题的个人结论。

为什么 `prefer-const`

一种论点是: 每次都要在let和const之间进行选择是一种心智负担。“始终在可行的地方使用 const”之类的规则使你不必再考虑它，并且可以由linter强制执行。
重新赋值可能引起bug: 在较长的函数中，重新分配变量很容易导致遗漏，这可能会导致bug。特别是在闭包中，const使你更有信心，你将始终“看到”相同的值。
关于可变的学习: 刚接触JavaScript的人经常会感到困惑，认为const意味着不可变性。但是，有人可能会指出，学习变量变动(mutation)和赋值之间的区别很重要，并且使用const会迫使你尽早应对这种区别。
无用的赋值: 有时候赋值是根本没有意义的。例如，使用React Hooks时，从诸如useState之类的Hook中获取的值更像参数。它们沿一个方向流动。在赋值中发现错误有助于你更早地了解React数据流。
性能优化: 偶尔有人声称，由于事先知道不会重新分配变量，因此JavaScript引擎可以使使用const的代码运行得更快。

为什么不 `prefer-const`

意图的丢失: 如果我们在所有可以使用的地方强制使用const，那么对于判断某些变量应不应该被重新赋值是否重要，我们将失去表达这种信息的能力。
不可变性的困扰: 在每次关于为什么你应该首选const的讨论中，总会有人对不变性感到困惑。这并不奇怪，因为赋值和变量变动都使用相同的=运算符。作为回应，人们通常被告知他们应该“只是学习该门语言”。但是，相反的论点是，如果可以防止大多数初学者犯错误的功能同时使初学者感到困惑，那么它其实并不是很有用。不幸的是，它无助于防止跨越模块并影响每个人的变量变动错误。
避免重新申明的压力: const优先的代码库给在某种条件下会重新分配变量的情况制造了不能使用let的压力。例如，你可能编写const a = cond ? b : c而不是if条件分支，即使b分支和c分支很复杂并且给它们指定明确的名称很奇怪。
重新赋值可能不会引起bug: 在三种常见的情况下重新赋值会导致错误：当scope很大（例如模块scope或庞大的函数）时，当值是参数时（因此它等于传递的值之外的值是不可预料的），以及在嵌套函数中使用变量时。但是，在许多代码库中，大多数变量都不满足以上任何一种情况，并且根本无法将参数标记为常量。
无法性能优化: 据我了解，即使你使用var或let，javascript引擎也已经知道哪些变量仅被赋值一次。如果我们坚持推断，那么我们也可以推断额外的检查会“创造”性能成本，而不是降低性能成本。实际上，javascript引擎非常聪明。

我的结论

我根本不在乎。

我将使用代码库中已经存在的任何约定。

如果你在乎的话，请使用可自动检查和修复此问题的linter，以免将let更改为const造成代码评审的延误。

最后请记住，linters的存在是为你服务的。如果一个linter规则使你和你的团队感到不快，请将其删除。这可能不值得。请从自己的错误中学习。

(This is an article posted to my blog at overreacted.io. You can read it online by clicking here.)

React 项目在IE11下刷新页面出现404错误

最近React项目遇到一个问题，当用户在IE11上刷新页面的时候会返回404错误页面。在其他浏览器上能够正常使用。错误页面如下:

项目背景：
1，利用 create react app 构建
2，部署在tomcat上
3，采用 H5 History 路由

服务端tomcat重定向的配置:

<error-page>
<error-code>404</error-code>
<location>/index.html</location>
</error-page>

解决问题的思路很清晰，由于这个错误页面只在IE下面出现，只需要了解该页面出现的机制就行。经过简单的搜索，我发现这个页面是IE 的 Friendly HTTP Error Pages。

自从IE5及以后的所有版本，如果服务端返回特定的错误码同时带的错误信息很短的话，IE会对用户显示上面那个更友好的错误页面。而对于触发这个友好错误页面的条件有两个, 并且两个条件必须同时满足:

服务端返回的 HTTP 状态码必须是 [400, 403, 404, 405, 406, 408, 409, 410, 500, 501, 505]
HTTP 的消息体 (Response body) 的字节长度必须小于一个阙值

对于状态码 [403,405,410]，默认阈值是256字节，对于响状态码 [400,404,406,408,409,500,501,505]，默认阈值是512字节。

经过检查，我们项目的index.html的大小果然是小于512字节，当tomcat把404重定向到index.html的时候触发了IE的友好错误页面显示。

(This is an article posted to my blog at overreacted.io. You can read it online by clicking here.)

Gandalf The Blue

怎样使用React Testing Library

Jest vs React Testing Library

React Testing Library: 渲染一个组件

React Testing Library: 选择元素

React Testing Library: 搜索类型

React Testing Library: 搜索变体(Search Variants)

getBy和queryBy有什么区别？

何时使用findBy？

多个元素呢？

断言函数

React Testing Library: 触发事件

React Testing Library: 用户事件

React Testing Library: Callback Handlers

React Testing Library: Asynchronous / Async

2020年编写React组件(hooks)的五个常见错误

本文是关于我发现的编写React组件时最常见的错误，为什么它们是错误以及如何避免或修复它们。

作为框架的React

免责声明

1. 在不需要重新渲染的地方使用useState

这很危险 ❌

问题所在 ⚡

解决办法 ✅

2. 使用router.push代替Link

这很危险 ❌

问题所在 ⚡

解决办法 ✅

3. 使用useEffect处理Actions

这很危险 ❌

问题所在 ⚡

解决办法 ✅

4. 单一职责的组件

这很危险 ❌

问题所在 ⚡

解决办法 ✅

4. 单一职责的useEffects

这很危险 ❌

问题所在 ⚡

解决办法 ✅

总结

let还是const

为什么 prefer-const

为什么不 prefer-const

我的结论

React 项目在IE11下刷新页面出现404错误

`本文是关于我发现的编写React组件时最常见的错误，为什么它们是错误以及如何避免或修复它们。`

为什么 `prefer-const`

为什么不 `prefer-const`