Локальное состояние и хуки
Вот мы построили приложение на React с глобальным состоянием в хранилище Redux. Но пока есть неудобства. Загрузка лотов производится даже когда мы не выводим их на странице, вхолостую занимая ресурсы браузера. И ещё использование внешнего хранилища порой может быть лишним.
Сегодня рассмотрим варианты хранения локального состояния внутри компонента. Код побочных эффектов сделаем выполняемым только при необходимости. И рассмотрим внутреннюю работу хуков React для использования побочных эффектов в функциональных компонентах:
- 00:00:48 - Постановка задачи
- 00:02:19 - Глобальное и локальное состояния
- 00:05:30 - Ручное использование полей
- 00:09:08 - Локальное состояние в Component
- 00:11:13 - Создание таймера
- 00:13:32 - Вынесение контейнерного компонента
- 00:16:07 - Плюсы и минусы
- 00:17:47 - Мотивация введения хуков
- 00:19:43 - Состояние через хук useState
- 00:21:52 - Устройство и работа хуков
- 00:26:41 - Компонент React.Fragment
- 00:29:59 - Побочные эффекты в useEffect
- 00:37:05 - Перенос загрузки лотов
- 00:39:25 - Уточнение зависимости
- 00:40:31 - Добавление флага загрузки
- 00:42:46 - Вынесение подписки на цены
- 00:48:30 - Вынесение контейнеров
- 00:49:54 - Многошаговый процесс подгрузки
- 00:56:32 - Локальное хранение лотов
- 01:04:21 - Замена Redux на useReducer
- 01:06:26 - Обзор результата
- 01:07:41 - Комбинация подходов
А в следующем эпизоде рассмотрим маршрутизацию через History API браузера.
Скрытый контент
Чтобы не пропускать новые эпизоды подпишитесь на наш канал @deworkerpro в Telegram

Супер
Спасибо.
Спасибо! Вообще получается что классы или функциональные компоненты это разные парадигмы разработки на Реакте, и мне кажется идет уход от классов да и от Редакса. Многие вещи решаются с помощью кастомных хуков, например та же авторизация. Вот тут много примеров есть https://usehooks.com, кому интересно. Т.е глобальные данные упаковываются либо в оборачивающий компонент, ну или в компонент высшего порядка. Но конечно, это вопрос личных предпочтений, как писать. Но вообще это чем то напомнило мидлвары в бэкенде.
Да, изначально были классы с методами жизненного цикла, но сейчас рекомендуют переходить на более простые функции с хуками.
А по хранению данных часто используют локальное состояние и контексты. Но многие крупные проекты всё равно делают со внешними хранилищами если им требуется выделенная централизованная модель данных.
В этом эпизоде заметно, что простой виджет Clock спокойно перешёл на локальное состояние. Но как только мы всё состояние с лотами и экшены со stream и api перенесли внутрь Lots этот компонент сразу стал монструозным и почти нетестируемым. Так что не всегда очевидно что будет удобнее.
Как по ощущениям, функциональные компоненты выглядят громоздко и не понятно в отличии от классов. Зачем это нужно было делать, какие насущные вопросы решал фейсбук....
То есть этот компонент:
Выглядит более громоздким, чем этот?
В классах кода больше, но и ясности больше что происходит
Но если знать, как работают хуки, то и в функциональном компоненте все предельно ясно
Дмитрий, спасибо за уроки, подскажите что за шрифт в самой программе idea?
Интерфейс шрифтом Tahoma
В редакторе DejaVu Sans Mono
Благодарю
Или войти через: