Открываем все секреты React Context API

Если вы пропустили видео на канале о Context API, доклад на конференции HolyJS 2022 (Санкт-Петербург) будет отличной заменой. В рамках доклада учтены комментарии от подписчиков и даже один Pull Request, в котором с вами поделились реальным фидбеком о замене Redux на Context API.

Поддержать Айти Синяка можно здесь:

00:00 Подводка
06:39 Вступление в доклад
09:34 Глава 1. Исходники
18:53 Глава 2. Redux vs Context API
22:31 Демо
29:41 Реальный фидбек
35:14 Глава 3. Эффективный контекст
42:30 Итоги доклада
44:30 Вопросы и ответы

________________

Канал о Фронтенде, который хочется порекомендовать (telegram):

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

Данный канал создан для инициирования бесед на различные темы IT сферы (социальные / технические), а также для тех кому короткая видео выжимка статьи, выступления на конференции или же просто личных мыслей, являются более удобным форматом

[Napolionik]

Очень интересный доклад, зразу же лайк!И личная просьба выпускай больше видео о React, уж очень качественно

[vlads]

Вот на такие доклады - ходил и ходил бы!!! Лайк, Спасибо !

[ДаниилНосов-хб]

Спасибо большое! Очень интересно слушать, а самое главное все понятно!

[Nuts_Cracker]

Спасибо за доклад, очень интересно! Keep doing what you doing!

[TheTexPro]

Спасибо большое, очень помогает освежить знания)

[vsevolod_zorin]

Очень круто! Классно! Теперь я знаю больше! Спасибо!) Попутного тебе ветра, добрый человек) и организаторам спасибо)

[theoty-js]

Респект парням, АЙ Синяк разрывной персонаж, очень крутой! Таких больше нет!!! настолько доходчиво объясняет. <3

[sergei_sergeevu]

Спасибо за интересный доклад! Проблему с rerender многие библиотеки решают при помощи Proxy. Не могли бы вы в одном из следующих видео затронуть архитектуру построения и общения mobx store через контекст, так как у них ссылка одинаковая проблем не будет, но раз у вас есть подобный опыт было очень интересно его послушать.

[xD-hugw]

Как всегда Отлично) ждем примеров про мобыху🙆

[temoncher]

Субъективное непопулярное мнение: сам факт наличия лекций, которые сравнивают Context API (который не предназначен для управления реактивным состоянием) cо state manager'ами только путает людей еще больше.

Context API и библиотеки управления состоянием решают две совершенно разные задачи. Context API решает задачу представления доступа к "X", игнорируя глубину вложенности элемента(aka внедрение зависимостей, поскольку мы вместо того, чтобы прокидывать этот "аргумент" явно, берем его из некоего контейнера, который спрятан внутри React). Библиотеки управления состоянием же помогают хранить состояние и реагировать на его изменение.

Перекладывая на термины Angular(может кому-то будет понятнее): Context'ы - это InjectionToken'ы, которые помогают внедрять сервисы в конструкторы.

Поэтому у Context API и нет конфликта с Redux'ом, react-redux пользуется механизмом внедрения зависимостей react'а, чтобы получить доступ к хранилищу из любой точки приложения, а как ты далее будешь реагировать на изменения этого хранилища - это совершенно другой вопрос. Поэтому ответ на вопрос "Почему из коробки нет `useSelector`'а?" должен быть следующим: Context API не решает задачу хранения реактивных данных, и, соответственно, не решает задачу оптимизации ре-рендеров компонентов тоже.

В общем и целом правило "Если ты складываешь результат работы `useState` (или его производные с помощью `useMemo`) как `value` в контекст, то, скорее всего, ты что-то делаешь не так" работает великолепно. Храните реактивное состояние в state manager'ах, а Context API используйте для внедрения зависимостей и будет вам счастье.

[ivanvaneck]

38:38 - правильно ли я понял что здесь точнее будет не undefined а defaultValue которое мы указали в createContext()?

[vazgenaleksanyan]

В случае с toolkit-ом не вижу смысла useReducer-а. Создаём ещё один slice и все.

[azad]

Писали писали без redux с контекстом и в итоге получился Redux..

[CJIueHb]

Столкнулся также с неким неудобством в typescript, когда надо типизировать контекст при его создании (при установке дефолтного значения). С самими сущностями можно определиться, а вот сеттеры к ним, которые используют сеттеры useState в компоненте провайдера, можно определить только после вызова useState в этом компоненте. И приходится эти сеттеры делать опциональными при описании типа контеста. И потом, при вызове в дереве компонентов либо делать проверку на undefined, либо использовать "!". В принципе, наверное, создание контекста можно затащить в компонент провайдера и заюзать для этого ref, но тогда его нельзя экспортировать, и надо объявлять наверху переменную для него неинициализированную, в общем, выглядит это не очень.

[Илья-слэ]

не нужно решать проблемы context API никакими пакетами. Просто не используете его не по назначению. Context отлично подходит для передачи не изменяемых(или редко изменяемых) даных. Для всего остального он не подходит

А кейс когда мы импортировали переменную userActions вместо засыввания их в контекст мы вообще скрестили ежа с ужом. Попробуйте теперь заиметь два провайдера такого "контекста" в дереве и вас ждут интересные открытия.

Так же распространное заблудение "redux прокидывается данные через контектс". Это не правда. Редакс(а точнее react-redux) не прокидывает данные через контектс. Он прокидывает стор, не данные. Это принципиальная разница. Стор у нас не изменяемый на протежении всей сессии работы с приложением, в то время как данные - изменыемы.

А почему противопставили единый источник истины и мультисторовые решения вообще не понятно. Они никак друг другу не противоречат

[woodDacha]

кратко заменит ли контекст Редакс - НЕТ, где использовать контекст - NPM пакеты без обид но возможно профи уловили тонкости мне лично немного пользы

[ilikecola]

Меня интересует насколько удобно работать с файлами 3000+ строк, или разработчики React их конкатенируют перед тем как положить на github?

[kai.hexenzorn]

Полезное видео для того, чтобы понять, как отказ от контроллеров, ViewModel и DomainEntity в конечном итоге приводит ко множеству проблем и костылей, когда пытаешься управлять состоянием и рендерингом. По сути использование нескольких контекст-провайдеров или сторов – это использование слабовыраженных сущностей предметной области, которые и должны хранить и состояние, и функционал, и быть цельными и изолированными от окружающего мира. Вместо этого мы наблюдаем расчленёнку, где в сторах оказывается состояние DomainEntity, а функционал DomainEntity где-то разбросан по ui-компонентам или экшенам, делая код запутанным и перегружая ui-слой, куда начинает протекать бизнес-логика. Если и делать кастомное управление состоянием, то не на основе контекста, а на базе mobX. MobX – не идеален, но задаёт правильный вектор.

[windus]

Сначала стоит лайкнуть, потом посмотреть. А то некст ролика ждать дольше придется

[Spirtikyss]

Спасибо за доклад, освежил память по context. Ты сказал, что в последнее время не использовал context, а что насчет steppers ( форма с шагами или подобные карусели ), когда нету целесообразности выносить это в store ( нет разницы, mobx или redux ), но в тоже время нужно шарить данные между шагами? Что ты используешь в той структуре?