От автора: некоторые ошибки стали довольно распространенными среди разработчиков, работающих над приложениями React. Эти ошибки могут быть результатом недосмотра, давления с целью уложиться в сроки или отсутствия опыта работы с React / JavaScript.
В этой статье я опишу 10 ошибок, которые часто допускают разработчики при создании приложений React. Хотя в этом руководстве мы используем React, большинство методов, о которых говорится здесь, могут быть применены к другим средам.
1. Не создают достаточно компонентов
Разработчики React часто допускают одну ошибку: они не создают достаточно компонентов. Как правило, есть два способа написания приложений: собрать все в одном месте (монолит) или разбить все на более мелкие части (микросервисы).
По замыслу приложения React должны быть составными. Рассмотрим следующий макет:
Чтобы правильно построить эту панель с помощью React, мы должны рассматривать ее как набор компонентов, которые формируют страницу, а не саму страницу целиком.
Таким образом, мы можем создавать различные наборы компонентов, которые — вместе взятые — составляют всю страницу.
Этот метод не только экономит ваше время, но и избавляет от стресса при отладке, поскольку вы сразу определяете, какой компонент связан с каждой ошибкой.
2. Написание логики в компонентах
При поиске правильного способа создания компонентов для повторного использования шаблон создания компонентов представления и контейнера часто является одним из первых.
Компоненты представления связаны с тем, как все выглядит, в то время как компоненты контейнера связаны с тем, как все работает.
Распространенная ошибка в приложениях React заключается в том, что разметка презентации и логика приложения объединены в один компонент.
Недостатком этого подхода является то, что вы не можете легко повторно использовать любые компоненты или логику без копирования и вставки.
Если вы используете шаблон представления и создания, вы сможете легче использовать повторно разметку и логику. Вы также можете вносить изменения в пользовательский интерфейс, не портя поведение.
Рассмотрим компоненты ниже. Это компонент книги, который предназначен только для получения данных из свойства и их отображения. Это компонент представления.
const Books = props => ( <ul> {props.books.map(book => ( <li>{book}</li> ))} </ul> )
Этот компонент books управляет и хранит собственные данные, а для отображения использует book компонентов представления, приведенные выше.
class BooksContainer extends React.Component { constructor() { this.state = { books: [] } } componentDidMount() { axios.get('/books').then(books => this.setState({ books: books })) ) } render() { return <Books books={this.state.books} /> } }
3. Мутирующие переменные состояния
Мутация — это способность что-то изменить. Рассмотрим следующее состояние:
const person = { name : "John", sex : "Male", }
Если в какой-то момент вы создадите в приложении новую переменную и назначите ей объект person с намерением изменить ее, вы можете быть удивлены результатом:
const newPerson = person newPerson.name = "Jane" newPerson.sex = "Female"
Если вы попытаетесь зарегистрировать оба объекта person и newPerson, вы заметите, что оба теперь отражают последнее установленное значение.
Это часто объясняет необычное поведение компонентов. Чтобы решить эту проблему, вы можете использовать метод или оператор ES6 .slice().
Однако лучшим подходом является неизменность. Вы можете реализовать это самостоятельно или использовать Immutable.js и immutability-helper, что рекомендуется командой React.
4. Не используют абсолютные пути
Если вы когда-либо работали над приложением React, содержащим много компонентов, изображений, CSS-файлов и других файлов, вы согласитесь, что импорт файлов из разных каталогов может быть утомительным. Много раз мы будем импортировать файлы следующим образом:
../../../importone.js ../../../importtwo.js
Мы уже можем видеть, что это не аккуратно, и изменение каталога файла приведет к сбою импорта. С выходом Create React App 3 теперь мы можем использовать абсолютные пути импорта. Для этого создайте в корневом каталоге файл jsconfig.json со следующим содержимым:
// jsconfig.json { "compilerOptions": { "baseUrl": "src" }, "include": ["src"] }
Теперь вы можете импортировать файлы следующим образом:
import React from 'react'; import { LINKS } from 'helpers/constants'; import Button from 'components/Button/Button'; function App() { return ( <> <Button> This is my button </Button> <a href={LINKS.ABOUT}>About Us</a> </> ); } export default App;
Это не только чище, но также означает, что вам не нужно обновлять путь в коде после изменения расположения файла. Вы можете узнать больше о CRA V3 здесь.
5. Не используют key в списке
Мы часто сталкиваемся с ситуациями, когда нам нужно визуализировать список элементов. Код выглядит примерно так:
const lists = ['one', 'two', 'three']; render() { return ( <ul> {lists.map(listNo => <li>{listNo}</li>)} </ul> ); }
Для небольших приложений это может работать. Но при работе с большими списками вы столкнетесь с проблемами рендеринга при попытке изменить или удалить элемент из списка.
React отслеживает каждый из элементов списка в DOM. Без этого он не знал бы, что изменилось в элементе списка. Чтобы это исправить, вам нужно добавить ключ ко всем элементам списка, например:
<ul> {lists.map(listNo => <li key={listNo}>{listNo}</li>)} </ul>
Примечание. Рекомендуется сопоставлять массив объектов с идентификаторами или любым уникальным свойством и использовать идентификатор в качестве ключа. Ключи в React должны быть уникальными. Хотя наш пример работает, это только потому, что элементы в нашем массиве примеров уникальны.
6. Не пишут модульные тесты
Это одна из самых распространенных ошибок. Это часто упускается из виду, потому что приложения технически все еще могут работать без модульных тестов. Модульный тест позволяет проверить части приложения независимо друг от друга , чтобы обеспечить работу определенных функций, как ожидалось.
Например, вы можете написать модульный тест, чтобы проверить, отображается ли в браузере свойство, переданное компоненту.
Вы можете удивиться, почему мы написали такой маленький тест. Иногда вы ожидаете, что свойство будет отображаться правильно после написания компонентов, но иногда конфликтующий стиль CSS может заблокировать его отображение.
Написание модульного теста экономит время, которое вы бы потратили на отслеживание этой ошибки, сразу же указав на нее. Они помогут вам быстро отладить приложение.
7. Не используют prop-types
Я часто вижу неправильные типы данных, передаваемые в приложениях. Например, вы хотите передать число 2 через свойство другому компоненту. Часто вы увидите, что это сделано так:
<MyComponent value="2" />
Это отправляет значение 2 в MyComponent в виде строки вместо числа. Чтобы отправить его как число, напишите это так:
<MyComponent value={2}/>
Определение типов с помощью пакета prop-types — самый надежный способ убедиться, что вы отправляете правильные свойства.
Prop-types используются для документирования предполагаемых типов свойств, передаваемых компонентам. React проверяет свойства, переданные компонентам по этим определениям, и предупреждает в процессе разработки, если они не совпадают.
8. Не используют вспомогательные классы или функции
Это распространенная ошибка, которую я видел во многих приложениях React. В дополнение к повторно используемым компонентам, у нас также есть функции многократного использования.
Этот функционал часто жестко запрограммирована на основе компонент-компонент, что приводит к неэффективному и противоречивому поведению между аналогичными компонентами.
Все компоненты контейнера содержат логику для захвата ресурса, сохранения его в состояние и управления ошибками.
В большинстве случаев это поведение одинаково для разных компонентов контейнера, но оно может быть непоследовательным, если не записано должным образом.
Рассмотрим приведенный выше пример, в котором мы выполняем вызов API для захвата ресурса, установки состояния, а также обработки ошибок.
Если мы извлечем это поведение во вспомогательный класс или функцию, мы сможем повторно использовать ту же логику для вызовов API, состояния установки и обработки ошибок.
9. Использование Redux или Flux для управления всеми состояниями приложения
В более крупных приложениях React многие разработчики используют Redux или Flux для управления глобальным состоянием. Это очень полезно. Однако нецелесообразно использовать Redux или Flux для управления каждым состоянием в приложении.
Взять, к примеру, компонент формы. Если мы хотим, чтобы состояние кнопки выбора всегда было checked, даже если мы посещаем ссылку, лучше всего управлять ею, используя метод локального состояния или useState (для хуков), а не Redux или Flux.
10. Не используют инструменты разработчика React и Redux
Приложения всегда глючат через некоторое время. Отладка часто является трудоемкой задачей, поскольку в большинстве случаев задействованы многие компоненты.
С помощью инструментов разработчика React вы можете просматривать визуализированное дерево элементов React, что невероятно полезно для наблюдения за тем, как различные компоненты создают страницу.
Инструменты разработчика Redux также включают множество функций, которые позволяют видеть каждое произошедшее действие, просматривать изменения состояния, вызванные этими действиями, и переходить к ним до того, как произошли определенные действия.
Вы можете добавить инструменты разработчика React, как зависимость dev или как расширение браузера. Их использование сэкономит вам много времени.
Заключение
В этом руководстве мы говорили о некоторых распространенных ошибках, которые допускают разработчики React при создании приложений. Мы также рассмотрели подходы и инструменты, которые могут сделать процесс более эффективным и менее болезненным.
Есть ли у вас какие-либо советы для распространенных ошибок, допускаемых во время разработки React? Обязательно оставьте комментарий.
Автор: Ogundipe Samuel
Источник: https://blog.logrocket.com
Редакция: Команда webformyself.