Как сделать уникальный ключ реакт

Обновлено: 07.07.2024

Я пытаюсь изучить React-Native. Я смотрю пример, адаптивная сетка изображения Джошуа Сирлес. (Спасибо, Джошуа!). В этом примере, Джошуа использует React для тщательного размещения элементов изображения под контролем мобильного дисплея. Примечание: он использует ТОЛЬКО три изображения и повторяет их несколько раз в документе. К сожалению, как написано, в примере генерируется предупреждение:

Я полностью понимаю, что каждый элемент внутри строки и каждой строки, сгенерированный React должен иметь уникальное свойство ключа. Я не понимаю, как это сделать. Вот мой хак/работа вокруг. ключ =

Этот хак прекрасно работает, но это просто кажется . неправильным. Вопрос в том, как правильно идентифицировать идентификаторы отдельных изображений, а также идентифицировать отдельные идентификаторы строк?

Я пробовал каждую комбинацию key = uri.id, imagesForRow.id, images.id и т. Д. , о которых я могу думать. Ничего не работает так же хорошо, как функция Random Number. Другие идеи? Каков правильный способ сделать это?

Обновление для ответа Криса Гейрмана ниже: Я хотел показать свой последний код.

Я думаю, что ключ действительно релевантен, если вы собираетесь перемещать компоненты вокруг (например, изменять порядок) или добавлять элементы. Если это не проблема для вас, и вы просто хотите отключить предупреждение, вы можете использовать индекс массива (второй аргумент для map () )).

Краткое официальное объяснение алгоритма согласования реактивов находится в React Docs - Листинг Мутации .

Я собираюсь расширить это, потому что я считаю, что другой ответ, который вы приняли, вводит в заблуждение: это не законное решение, как оно представлено.

Я понимаю, что React интерпретирует дочерний элемент, который является массивом как особый случай, когда длина или относительная позиция элементов могут изменяться, пока экземпляры компонентов должны быть сохранены. В React docs они описывают это следующим образом:

, когда дети перетасовываются (как в результатах поиска) или добавляются новые компоненты в начале списка (как в потоках).

Но часто массив используется только для удобства генерации сценариев для детей, которые в противном случае могли бы быть выражены буквально/статически. И это так, я думаю, у вас здесь. Если это не так, вам понадобится и, скорее всего, уже имеют законные уникальные идентификаторы. Например, если я правильно понял ваш пример использования, вы могли бы просто сделать что-то подобное, и в этом случае от React не было бы никакого предупреждения:

Очевидно, что это был бы ужасный способ сделать это, поэтому отсюда и использование массивов. Но React не различает это использование массива (чтобы сценарий эквивалент этого) из другого случая (где длина и порядок элементов являются динамическими) и жалуется на ключ. Вы могли просто игнорировать предупреждение, но его легко отключить, просто назначив значение индекса для элемента.

Simplified example. These variations produce equivalent output, but differ by being literally declared or scripted and emitting a key warning or not.

Что говорит уточка, когда узнала, что ты не используешь key

Чтобы представить работу ключей полностью и с различными кейсами, рассмотрим план:

Reconciliation
Реиспользование ключей и нормализация
Использование key при рендере одного элемента
Работа с ключами при передаче компоненту children

Так как материала немало, в конце каждой части будут выводы. В конце статьи также приведен общий вывод и кратко описаны тезисы. Код можно будет смотреть как на примерах в codesandbox, так и под спойлерами.

Reconciliation

Главная задача ключей в реакте — помогать механизму reconciliation. Давайте создадим небольшой компонент, который будет рендерить список имен:

Теперь усложним задачу и создадим инпут с кнопкой добавления нового имени в начало и в конец. Кроме этого, в componentDidUpdate и DidMount для Name компонента добавим логирование изменений, с указанием children:

Демонстрация работы подобного списка:

При добавлении элемента сверху получаем ситуацию, когда компоненты Name будут перерисованы и создан новый компонент с children === Василий :

Updated from Миша to Павел
Updated from Даниил to Миша
Updated from Марина to Даниил
Updated from Василий to Марина
Mounted with Василий

Почему так происходит? Давайте посмотрим на механизм reconciliation.

Полная сверка и приведение одного дерева к другому — дорогая задача с алгоритмической сложностью O (n³). Это значит — при больших количествах элементов реакт был бы медленным.
По этой причине механизм сверки VDOM работает с использованием следующих упрощений (правил):

1) Два элемента разных типов продьюсят разные поддеревья — значит, при смене типа элемента с

и разными. Реакт удаляет элементы, которые были внутри div , и маунтит все элементы внутри section. Даже если поменялся только сам тег. Аналогичная ситуация удаления-инициализации дерева происходит при смене одного реакт-компонента на другой, хотя само содержимое, казалось бы, остается прежним (но это только заблуждение).

Аналогично работает и с React-компонентами:

2) Массивы элементов сравниваются поэлементно, т. е. реакт одновременно итерируется по двум массивам и сравнивает элементы попарно. Поэтому мы и получили перерисовку всех элементов в списке в примере с именами выше. Разберем на примере:

В случае же, когда добавляем элемент вверх:

Для решения проблемы в реакте используют атрибуты key. При добавлении key реакт будет сравнивать элементы не друг за другом, а будет искать по значению ключа. Пример с рендерингом имен станет более производительным:

Перепишем наш пример, добавив ключи. Обратите внимание, что теперь при добавлении элементов вверх списка происходит создание только одного компонента:

Замечу, что мы добавили id к нашим именам и управляем keys напрямую, не используя индекс элемента в массиве как key. Это обусловлено тем, что при добавлении имени в верх списка индексы поедут.

Подведем итог первой части:

Ключи оптимизируют работу с элементами массивов, уменьшают количество ненужных удалений и созданий элементов.

Реиспользование ключей и нормализация

Заметим неприятную особенность: если выбрать человека и затем переключить команду, произойдет анимирование снятия выделения, хотя человек в другой команде никогда мог и не быть выделен. Вот яркий пример на видео:

При реиспользовании ключей, где не надо, мы можем получить сайд-эффекты, так как реакт будет обновлять, а не удалять и создавать новые компоненты.

Так происходит, потому что мы использовали идентичные ключи для разных людей. И поэтому реакт реиспользует элементы, хотя в примере это не нужно. Кроме того, добавление новых людей порождает сложный код.

В приведенном коде есть пара проблем:

Данные не нормализованы, работа с ними усложняется.
Происходит дублирование ключей у сущности developer, из-за чего реакт не пересоздает компонент, а обновляет его. Это и ведет к сайд-эффектам.

Решить проблему можно двумя путями. Простым решением будет создать составной ключ для разработчиков в формате: $.$ , это позволит не пересекаться ключам и избавиться от сайд-эффектов.

Но проблему можно решить комплексно, нормализовав данные и объединив сущности. Значит, в state компонента будет 2 поля: teams , developers . developers будут содержать мапу id + name , teams будут иметь список разработчиков, которые находятся в команде. Реализуем это решение:

Теперь элементы обрабатываются корректно:

Нормализация данных упрощает взаимодействие с дата-слоем приложения, упрощает структуру и уменьшает сложность. Например, сравните функцию toggle с нормализованными и ненормализованными данными.

Подведем итог второй части:

При использовании ключей важно понимать, что при смене данных ключи должны меняться. Яркий пример ошибок, которые я встречал во время ревью, использование индекса элемента в массиве как key . Это приводит к сайд-эффектам типа того, что мы рассматривали на примере отображения списка людей с выделением.

Нормализация данных и/или составные key позволяют добиться нужного эффекта:

Обновляем данные, когда изменяется сущность (например, помечается выделенной или мутирует).
Удаляем старые инстансы, если элемента с заданным key больше не существует.
Создаем новые элементы, когда это нужно.

Использование key при рендере одного элемента

Как мы обсуждали, реакт при отсутствии key сравнивает элементы старого и нового дерева попарно. При наличии ключей — ищет в списке children нужный элемент с заданным ключом. Случай, когда children состоит только из одного элемента, не исключение из правила.

Разберем другой пример — нотификации. Положим, что нотификация может быть только одна в конкретный период времени, отображается в течение нескольких секунд и исчезает. Такую нотификацию реализовать просто: компонент, который по componentDidMount ставит счетчик, по окончании счетчика анимирует скрытие нотификации, например:

Да, в этом компоненте нет обратной связи, он не вызывает никаких onClose , но для этой задачи не важно.

Мы получили простой компонент.

Представим ситуацию — при клике на кнопку отображается подобная нотификация. Пользователь кликает на кнопку не переставая, но уже через три секунды нотификации добавится класс notification_hide , и она станет невидимой пользователю (если мы не использовали key ).

Здесь мы получили намного больше кода, который перезапускает таймаут, если контент нотификации изменился, и убирает класс notification_hide при обновлении данных.

Но решить задачу можно, и используя наш первый компонент Notification1 и атрибут key . У каждой нотификации есть свой уникальный id , которым мы воспользуемся как key . Eсли при изменении нотификации изменяется key , то Notification1 будет пересоздаваться. Компонент будет соответствовать нужной бизнес-логике:

Таким образом

Работа с ключами при передаче компоненту children

Интересная особенность key — он недоступен в самом компоненте. Это происходит потому, что key — special prop . В React существует 2 специальных props : key и ref :

Кроме того, в консоли будет warning:

Но, если компоненту передали children , у которых есть key , вы сможете с ними взаимодействовать, но поле key будет не внутри объекта props , а на уровне самого компонента:

Подытожим:

key и ref — special props в реакте. Они не включаются в объект props и недоступны внутри самого компонента.

Получить доступ к child.key или child.ref можно из родительского компонента, которому передали children , но делать этого не нужно. Практически нет ситуаций, когда это нужно. Всегда можно решить задачу проще и лучше. В случае если нужен key для обработки в компоненте — задублируйте его, например в prop id .

Мы рассмотрели области применения key, как он передается в компонент, каким образом изменяется механизм reconciliation с заданием key и без него. А также посмотрели на использование key для элементов, которые являются единственным child. Сгруппируем в конце основные тезисы:

Без key механизм reconciliation сверяет компоненты попарно между текущим и новым VDOM. Из-за этого может происходить большое количество лишних перерисовок интерфейса, что замедляет работу приложения.

Добавляя key , вы помогаете механизму reconciliation тем, что с key он сверяет не попарно, а ищет компоненты с тем же key (тег / имя компонента при этом учитывается) — это уменьшает количество перерисовок интерфейса. Обновлены/добавлены будут только те элементы, которые были изменены/не встречались в предыдущем дереве.

Следите, чтобы не появлялись дублирующие key , при переключении отображения у новых данных не совпадали ключи. Это может привести к нежелательным сайд-эффектам, таким как анимации, или некорректной логике поведения элемента.

В редких случаях key используют и для одного элемента. Это сокращает размер кода и упрощает понимание. Но область применения этого подхода ограничена.

Задачей этого руководства было не идти проторенным путем “волшебных” готовых шаблонов (например create-react-app и react-boilerplate), а самостоятельно разобраться во множестве динамических компонентов, формирующих приложение React .

До этого подобную тему освещал Jedai Saboteur в своей статье Creating a React App… From Scratch (англ.), на которую ввиду ее грамотности даже сделали ссылку в официальной документации React.

Как бы то ни было, но время идет, и я р ешил создать современное приложение React с нуля в 2021 году. В итоге было решено добавить в цепочку инструментов ряд “важных элементов” и задействовать последние версии основных библиотек. В некотором смысле у меня получилась последняя версия вышеприведенного руководства.

Наша цель проста: создать приложение React с нуля. “С нуля” подразумевает не то, что я буду разрабатывать вспомогательные инструменты, а то, что вместо использования, например, create-react-app , я сконфигурирую их самостоятельно.

Тем не менее помимо настройки простого рабочего приложения я также определил пару дополнительных, “важных” по меркам современного стека, требований:

Поддержка TypeScript.
Возможность внешнего управления состоянием.

Озадачившись списком необходимых инструментов, я решил обратиться к документации React.

После прочтения раздела Creating Toolchain from Scratch я прикинул следующий список:

Пакетный менеджер, например Yarn или npm. Позволяет воспользоваться возможностями огромной экосистемы сторонних пакетов, облегчая их установку и обновление.
Бандлер, например webpack или Parcel. Позволяет писать модульный код и связывать его воедино в небольшие пакеты, оптимизируя время загрузки.
Компилятор, например Babel. Дает возможность писать современный JS-код, который будет успешно работать в старых браузерах.

Этот краткий отрывок достаточно подробно раскрывает суть необходимых компонентов. В итоге на их роли я выбрал:

Пакетный менеджер: Yarn
Бандлер: webpack
Компилятор: Babel

Это вполне типичные варианты. Даже если вам не приходилось заниматься самостоятельной настройкой этих инструментов, то вы наверняка с ними либо работали, либо просто о них слышали.

Однако, согласно моим требованиям, все еще недостает одного элемента: библиотеки управления состоянием.

Redux могла стать очевидным выбором, но я предпочел Kea. Дело в том, что разработана Kea на базе Redux, но при этом существенно упрощает управление состоянием.

По правде говоря, здесь я определенно предвзят, так как выбрал Kea больше из-за того, что использую эту библиотеку на работе, а разработал ее мой коллега.

Сперва создайте каталог и выполните в нем yarn init .

Когда система попросит задать entry point , укажите src/index.tsx . Далее станет понятно, почему именно так.

Далее внутри этого каталога создайте еще два: src и public .

В src будет храниться весь исходный код проекта, а в public мы разместим статические ресурсы.

Наше руководство будет не универсальным, а обучающим, и работа с возникающими сложностями станет его неотъемлемой частью.

В связи с этим, при установке инструментов я не буду указывать номера их версий. Если же вы захотите использовать мой вариант в качестве шаблона, то можете посмотреть их в package.json .

В качестве примера я решил взять для этого руководства webpack v5, который вызвал ряд проблем совместимости с конфигурациями, используемыми мной ранее в проектах с webpack v4. Как обычно разобраться с этой проблемой и попутно запастись дополнительными знаниями мне помогла документация, различные статьи и посты на Stack Overflow.

Babel

Для работы Babel требуется еще несколько пакетов, которые устанавливаются так:

babel-core — это компилятор, то есть сам основной компонент.

babel-cli позволит использовать компилятор из командной строки.

Последние три пакета — это “шаблоны” (настройки) Babel для работы с различными сценариями использования. present-env избавляет нас лишних проблем, позволяя писать современный JS-код и обеспечивая его работоспособность на различных клиентах. preset-typescript и preset-react говорят сами за себя: так как используем мы и TypeScript, и React, то нам понадобятся они оба.

В завершении нужно сконфигурировать файл babel/config.js , указав компилятору используемые настройки:

TypeScript

В этом проекте мы будем использовать TypeScript, поэтому у него будут свои дополнительные настройки.

Сначала установим пакет typescript :

Забегая чуть вперед, я предлагаю вам также установить следующие пакеты, если вы собираетесь следовать руководству до конца:

В них содержатся объявления типов для модулей, которые мы задействуем в проекте.

Помимо этого, нам также нужен файл tsconfig.json . Я использую конфигурацию с PostHog, с которой мы работаем в продакшене:

Можете смело менять приведенную конфигурацию под свои нужды. Тем не менее важно сохранить эти опции:

"jsx": "react" говорит сама за себя. Что же касается noEmit , то для нее мы устанавливаем true , так как Babel компилирует TS автоматически, и typescript нам нужен только для проверки ошибок (например, при написании кода).

Webpack

Для работоспособности этому инструменту также требуется ряд настроек. По сути, для каждого типа файла, который мы будем собирать, понадобится отдельный загрузчик.

webpack и webpack-cli следуют тому же принципу, что и Babel. Первый является основным пакетом, а второй позволяет обращаться к нему через командную строку.

webpack-dev-server требуется нам для локальной разработки. Вы заметите, что package.json никогда не ссылается на него из скрипта, но он необходим для запуска webpack serve :

Последними идут загрузчики, нужные для разных файлов, которые мы будем обрабатывать. ts-loader также присутствует, но поскольку мы используем для компиляции JS-файлов Babel, фактичекски, он нам не понадобится.

В завершении, как и для Babel, нужно настроить файл конфигурации webpack.config.js :

React

Учитывая, что создаем мы приложение React, нам также нужны и соответствующие пакеты.

Этого будет достаточно:

react говорит за себя. react-dom будет использоваться для рендеринга приложения в index.tsx , а react-hot-loader для разработки. Он будет автоматически обновлять файл при внесении изменений.

В завершении настроим библиотеку управления состоянием.

Согласно документации нам нужно следующее:

Здесь мы подумаем наперед и добавим отдельный пакет, который используется при написании логики Kea в TypeScript:

package.json

После всей этой настройки нужно добавить в package.json пару скриптов:

start будет запускать сервер, а typegen генерировать типы для файлов логики Kea.

Нехило так настроечек? Думаю, что шаблоны определенно заслуживают благодарности, особенно, когда они берут на себя все управление зависимостями и версионирование (react-scripts).

Как бы то ни было, но с настройкой мы закончили, и пора заняться кодом.

Но сначала немного чистого HTML

Первым делом нам нужен файл index.html , который React будет использовать для отрисовки приложения. Это будет наш единственный файл .html . Он также будет единственным в каталоге public/ .

Вот мой index.html :

Здесь происходит несколько действий:

Точка входа

Помните упоминание о точке входа? Что ж, вот мы до нее и добрались. Перейдите в подкаталог src/ и создайте файл index.tsx .

Вот содержимое моего:

Здесь происходит три основных действия:

Мы настраиваем Kea, которая, подобно Redux, использует Provider , делая хранилище доступным для всех вложенных компонентов (в нашем случае для всего приложения).

Вызов resetContext здесь, по сути, не нужен, так как в него ничего не передается. Тем не менее я его оставил, чтобы вы знали, куда добавлять, к примеру, плагины Kea, так как они вам наверняка понадобятся.

2. Мы импортируем и отрисовываем компонент App (который еще не собран).

3. Мы сообщаем React отрисовать приложение, используя div root из index.html в качестве "точки привязки".

Приложение!

Далее также внутри src/ создайте файл App.tsx со следующим содержимым:

Если в этот момент вы просто хотите увидеть приложение в действии, то можете удалить импорты и ссылки на MyJsComponent и Counter , после чего выполнить yarn start . Это запустит сервер, и вы сможете перейти к приложению по адресу localhost:3000 , где оно поприветствует вас фразой “Hello world!”.

Эти два дополнительных компонента я включил, чтобы убедиться в следующем:

Возможности написания JavaScript параллельно с TypeScript.
Возможности управления состоянием.
В том, что бандлер без проблем обрабатывает файлы .css ( Counter содержит минимальную стилизацию).

Так что при желании вы можете на этом остановиться. Если же вы тоже хотите увидеть, как работают перечисленные возможности, то продолжим.

Написание JS и TS

Как вы видели в App.tsx , у нас есть TS-файл, спокойно импортирующий JS-файл.

Проблем не возникает, так как в webpack.config.js установлено это правило:

Если удалить j из test , то использовать JS-файлы с помощью TS-файлов мы не сможем.

Чтобы убедиться в работоспособности этой схемы, я просто создал мелкий JS-компонент и импортировал его в приложение.

Создал я его в новом каталоге components/ , заполнив следующим содержимым:

Counter

Последним я добавил в этот мини-проект традиционный React-компонент Counter.

Задачей было убедиться в работоспособности настроек Kea и в том, что при этом также работает импорт CSS-файлов.

Сначала я создал в components/ подкаталог Counter . В него я добавил три файла:

1. index.tsx — содержит сам компонент:

Все довольно просто. Кликаем + , и отсчет идет вверх, кликаем - , и он устремляется вниз. Установите любое число, используя ввод, и отсчет также обновится.

Обратите внимание на импорт stype.css .

2. counterLogic.ts — размещает в себе логику управления состоянием, используемым компонентом Counter . Я не стану объяснять, как работает Kea, но тут все должно быть понятно само собой:

3. style.css — здесь я использовал минимальную стилизацию просто, чтобы убедиться в правильной работоспособности CSS:

Если вы добрались до этой части, то, надеюсь, на выходе вы получили свежеиспеченное приложение React, современный шаблон, а также некоторый багаж дополнительных знаний. Честно говоря, здесь я просто задокументировал часть своего процесса обучения, но и вы наверняка из этого что-нибудь да почерпнули!

Если вы только начинаете свое знакомство с React, это руководство поможет вам начать работу.

Предварительные требования

Несколько основных терминов и понятий

React — это библиотека JavaScript для создания пользовательских интерфейсов.

Это решение с открытым кодом — вы можете участвовать в этом проекте, публикуя проблемы и запросы на вытягивание. (См. эту документацию!)

Это декларативная библиотека — вы пишете нужный код, с которым затем React выполняет все действия JavaScript и DOM, чтобы получить нужный результат.

Она также основана на компонентах — приложения создаются с помощью готовых и многократно используемых независимых модулей кода, которые управляют собственным состоянием и которые можно объединить с помощью платформы React. Это позволяет передавать данные через приложение, сохраняя состояние из модели DOM.

Основной принцип работы с React: "Выучи один раз, используй везде". Целью является повторное использование кода. Вам не нужно делать предположения о том, как вы будете использовать пользовательский интерфейс React с другими технологиями. Вместо этого нужно сделать компоненты многократно используемыми без необходимости перезаписывать существующий код.

JSX — это расширение синтаксиса для JavaScript, написанное для использования с React. Оно выглядит как HTML, но фактически является файлом JavaScript, который необходимо скомпилировать или преобразовать в обычный код JavaScript.

Виртуальная модель DOM — модель DOM представляет пользовательский интерфейс приложения. При каждом изменении состояния пользовательского интерфейса приложения модель DOM обновляется для представления изменений. Если модель DOM обновляется часто, производительность снижается. Виртуальная модель DOM — это визуальное представление модели DOM, поэтому при изменении состояния приложения обновляется виртуальная модель DOM, а не сама модель DOM, что позволяет оптимизировать производительность. Это репрезентация объекта DOM, упрощенная копия.

Представления — это то, что видит пользователь в браузере. В React представление связано с понятием элементов отрисовки, которые пользователь должен видеть на экране.

Состояние — это данные, хранимые в разных представлениях. Состояние обычно зависит от прав и действий пользователя. Например, при входе на веб-сайт может отображаться ваш профиль пользователя (представление) с вашим именем (состояние). Данные состояния зависят от пользователя, но представление не меняется.

Использование React в Visual Studio Code

Создать приложение с помощью React можно разными способами (примеры см. в статье Общие сведения о React). В этом учебнике описано, как использовать create-react-app для ускорения настройки работающего приложения React, чтобы вы могли сосредоточиться на экспериментах с кодом, а не отвлекаться на средства сборки.

Используйте create-react-app в Windows или WSL (см. предварительные требования выше), чтобы создать новый проект: npx create-react-app hello-world .

Измените каталоги, чтобы перейти в папку для нового приложения ( cd hello-world ), и запустите приложение ( npm start ).

Новое приложение React Hello World будет скомпилировано. Затем оно откроется в веб-браузере по умолчанию по адресу localhost:3000.

Закройте приложение React (CTRL+С) и откройте его файлы кода в VS Code, введя code . .

Найдите файл src/App.js и перейдите в следующий раздел заголовка:

Измените его следующим образом:

Использование React с API

Используя то же приложение Hello World, созданное с помощью React и обновленное в Visual Studio Code, мы добавим вызов API для отображения некоторых данных.

Во-первых, мы удалим все содержимое из этого файла app.js и сделаем из него компонент класса. Сначала мы импортируем компонент из React для создания компонента класса. (Типов компонентов два: класс и функция.) В оператор return() также будет добавлен пользовательский код JSX. Чтобы увидеть результат, нужно перезагрузить страницу.

Теперь файл app.js будет выглядеть так:

Затем мы настроим локальное состояние, в котором можно хранить данные из API. Объект состояния позволяет хранить данные, которые будут использоваться в представлении. Представление визуализируется на странице в render() .

Нам также нужно инициализировать локальное состояние и назначить объект this.state . Мы будем использовать posts в качестве пустого массива, который можно заполнить отправленными данными из API.

Теперь файл app.js будет выглядеть так:

Чтобы вызвать API с данными для использования в нашем приложении React , мы будем использовать метод JavaScript .fetch. API, который мы вызовем, — это JSONPlaceholder, бесплатный API для тестирования и создания прототипов, который обслуживает фиктивные данные заполнителя в формате JSON. Метод componentDidMount используется для подключения fetch к нашему компоненту React. Данные из API сохраняются в нашем состоянии (с помощью запроса setState).

Давайте посмотрим, какие данные сохранены API в нашем состоянии posts . Ниже приведено содержимое фиктивного файла API JSON. Формат перечисления данных можно просмотреть, используя следующие категории: albumId, id, title, url и thumbnailUrl.

Чтобы отобразить данные API, нам нужно добавить некоторые стили страниц. Мы сделаем это с помощью Bootstrap. Мы можем скопировать и вставить ссылку на таблицу стилей Bootstrap CDN в файле ./public/index.html нашего приложения React.

Снова запустите приложение React ( npm start ) и перейдите в локальном веб-браузере по адресу localhost:3000 , чтобы увидеть отображаемые данные API.

Читайте также: