Главный миф о Дэне Абрамове что он создал React. Но хотя это и не так, сейчас он имеет самое прямое отношение к фреймворку, так что поговорить с ним про React очень интересно. Обычно Дэна не увидеть на российских конференциях, но нам помог онлайн-формат, и на HolyJS его подробно расспросили Наталия Теплухина (член core team Vue.js) и Наталия Короткова (занимается веб-проектами с 2010 года).

Тут получился не поверхностный разговор о погоде, а обсуждение технической конкретики для тех, кто вдается в детали. Но под конец были и более общие вопросы: когда появится новая документация React, переписанная с нуля? Что не так с Redux? Как Дэн воспринимает холивары о фреймворках? Что он может рассказать о релокации?

Так что, если не осилите все технические детали в первой половине интервью, переходите ко второй, там попроще. Под катом и видеозапись разговора, и текстовая расшифровка.

Оглавление

• О Suspense
• О Concurrent mode
• О state managers
• О нормализации данных на клиенте
• О Redux
• О прошлом React
• О хуках
• О холиварах
• О личном

О Suspense

Первый вопрос немного философский. Начну его с вводной. Чем стабильность отличается от стагнации? В 17-м апдейте React у нас не было никаких классных фич и заметных обновлений, хотя ожидались какие-то глобальные апдейты. Почему React вообще сменил версию с 16 на 17, ради чего это было?

Изначально не планировали такой 17-й версии, которая получилась. Действительно, планировали апдейты, связанные с конкурентным режимом, Suspense. Но так сложилось, что было несколько проблем, которые мы хотели пофиксить довольно давно, с 2014 или 2015 года. Они связаны с ивентами. И мы снова столкнулись с ними внутри.

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

Если у тебя File Explorer на React 13, а Project View на 14-м, конкретная вещь, которая ломается
event.stopPropagation(). Эти реакты не знают друг о друге, не могут координировать события.

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

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

Мы решили пофиксить события, работал в основном Доминик (Dominic Gannaway прим. ред.). Большое изменение события перенеслись. Раньше они подписывались на документе, а теперь делегируются к корню дерева React. Даже если вы используете две версии React, что в целом не очень хорошо, в большом приложении есть разумный компромисс: какие-то старые трехуровневые диалоги можно держать на старой версии, а основное приложение перевести на новую. Благодаря этому изменению они могут сосуществовать, код можно переводить с одной версии на другую, и это не должно сломать приложение в целом. Может, придется немного подтянуть его.

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

Таким образом в 18-й версии это позволит нам убрать какие-то вещи, которые мы не могли убрать раньше, так как от них, к сожалению, до сих пор зависит много кода.

Поэтому мы характеризуем 17 версию словами stepping stone (нечто вроде ступень на пути, позволяющая перейти к большему прим. ред.).

Почему вы так долго пилите Suspense, что мешает его релизнуть?

Давайте я сначала расскажу, как мы в принципе работаем, а потом отвечу на вопрос.

Мы не просто команда разработки, мы команда Research & Development. В продуктовой команде бывает, что кто-то просто просит какую-то штуку, и её делают. У нас немного другой подход, потому что продукт другой.

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

Если начать думать, как встроить само понятие асинхронности в UI-программирование, то это довольно обширная область. И одна из основных идей в Suspense мы хотим утащить понятие того, что какой-то компонент не готов зарендериться, что он ждет каких-то данных или чего-то ещё, в декларативную модель, как React делает с другими вещами. Вместо того, чтобы приходилось делать что-то вручную, это становится элементом дерева.

Мы начали с этой идеи, потому что изначально хотели сделать серверный рендерер, который будет опираться на нее для стриминга. Но в итоге получилось, как в книжке про Алису, которая пошла в нору, а там оказался целый мир. И оказалось, что есть глубокие последствия, целая теория всего.

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

И в целом у нас это уже хорошо работает c Relay. То есть у нас есть опенсорсная библиотека для GraphQL, которая использует Suspense. Но мы знаем, что в опенсорсе никто не использует Relay, мы хотим общее решение.

Suspense в React уже работает, это можно делать. Но мы уже столько узнали о том, как правильно фетчить данные по опыту работы с Relay и выстраивания огромного сложного приложения на React, что нам не хочется выпускать что-то неоптимальное. Хотя даже сейчас имеющиеся решения работают для многих, но не так хорошо, как нам хотелось бы.

Мы по-прежнему развиваем эту идею. Есть конкретные вещи, которые, я надеюсь, мы сможем показать в ближайшие месяцы. Они дополняют картинку и делают её целостной. (прим. ред.: в конце декабря были представлены React Server Components)

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

О Concurrent mode

Как вы конкретно исследуете эту проблематику? Насколько я знаю, вы тестируете Concurrent mode и Suspense data fetching на Next.js-проекте. Можешь рассказать об итогах тестирования? Помогает ли это вам в развитии React?

Да, если кто-то не знает, у нас есть активная коллаборация с Next.js, это React-фреймворк. Это коллаборация между нами, Next.js и кусочком команды Google Chrome. У нас нет какого-то направления вроде помогать только Next.js, просто в разное время работаем с разными командами над разными проектами.

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

И в этом смысле Next.js неидеальная, но хорошая база, на которой можно строить. И для нас, если мы хотим ввести какие-то best practices это хорошее место, и другие все равно скопируют. И у Google такой же интерес, они до этого пытались делать по-своему, что-то у них получалось.

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

Мы внутри Facebook используем Concurrent mode больше года, новый сайт работает полностью на нём. Понятно, что новый сайт неидеальный (одна кодовая база и сотни людей), там тоже свои сложности: иногда люди заходят, кликают, видят баг и говорят о, Concurrent mode. Но нет, это не совсем так работает.

Во главе Concurrent mode, потому что очень сложно сделать сайт такого объёма на классическом React. Это не то же самое, что перевести существующее приложение мы и с Next.js работаем, у них есть какие-то клиенты. И через них можно попробовать перевести один проект на Next.js и посмотреть, что будет на Concurrent mode.

У них есть своя data fetching-история с getInitialProps, которая в чем-то нас вдохновила. Это один из ингредиентов, который мы получили от Relay, нашего собственного ресёрча, а теперь мы хотим посмотреть можем ли мы дополнить то, что Next.js сделал с getInitialProps, внести свои идеи туда и посмотреть более общее решение, которое имеет смысл попробовать.

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

По экспериментам насколько знаю, Concurrent mode уже пробовали в каких-то проектах. На Next.js Conf недавно был доклад от команды Chrome, в котором они показали слайд с изменениями в хорошую сторону.

^{Вот этот момент в докладе.}

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

Будет ли Concurrent mode работать с React Native, и правда ли Facebook использует React Native, который отличается от того, что лежит в общем доступе на GitHub?

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

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

Сам билд можно сделать, если заклонить репозиторий React на GitHub. Можно сделать yarn build --type=FB и получить те же бандлы, что мы используем. Только там будут внутренние референсы.

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

В вебе у этого режима преимущество, но тут тоже масштабные вопросы с нативной стороны. Потому что это часть взаимосвязанного проекта Fabric, переписывание движка React. Он про то, чтобы React Native мог на любом треде работать как синхронно, так и асинхронно на любом треде.

Мы столкнулись с тем, что на React Native легко делать экраны приложения, но трудно создать что-то встраиваемое. Например, ленту новостей Facebook никто не будет никогда переписывать на React Native, там уже семь лет коду. И, например, хочется встроить какой-нибудь feed item на React Native, но поскольку он всегда был асинхронным, его нельзя отрендерить, измерить, чтобы он синхронно встал в ленту новостей, пока ты скроллишь.

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

Мы не сделали шажок для веба и потом портируем на React Native. Всё задумывалось как единое целое, просто для веба это быстрее сделать.

О state managers

Почему unstable_observedBits анстейбл, почему аналогичную функциональность не реализуют в паблик? Это сильно упростило бы state management для маленьких и средних приложений.

Почему анстейбл? Потому что это очень странный API, которым сложно пользоваться. Я думаю, мы это точно уберем.

Почему люди думают, что им это нужно? Тут смотря как структурировать приложение. Если весь тип state вынести наверх, и потом где-то глубоко использовать, то может быть неэффективно, что у тебя слишком много перерендеривается и так далее. Часто это решается тем, что state нужно выносить туда, где он используется, а не пихать наверх.

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

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

И в таком случае я думаю, будет спорный вопрос, что нужен такой API для state management. Если проблему закрыть именно с тем, что слишком агрессивно всё ререндерится автоматической мемоизацией, то результат будет похож на тот, что у Svelte или Vue.

Только они это делают мутацией и реактивностью, а мы это делаем мемоизацией. Но для этого нужен компилятор, и это тоже большой проект. Может быть, мы начнем его в 2021-м, может, нет трудно сказать.

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

Почему React всегда позиционировался как библиотека для View-слоя с возможностью хранить и обрабатывать данные, но никогда не предоставлял API для интеграции с внешними источниками данных, например, state managers?

И похожий вопрос: так как GraphQL тоже технология Facebook, и, к примеру, в Redux можно увидеть, что какая-то его часть встроена в React посредством hooks, планируется ли внедрять похожую историю с GraphQL, к примеру, как Relay для стандартизации? Будут ли предусмотрены какие-то API, чтобы сделать state manager в React более стандартизированным?

У меня первая реакция на такие вопросы я не знаю, что такое state management, не понимаю, что люди имеют в виду, когда говорят об этом. Может, у меня профдеформация, потому что в React-команде мы просто думаем об этом иначе.

В React уже есть понятие State, это UI-состояние, его менеджишь тем, что просто используешь State, если нужно передать глубоко, используешь контекст и все дела.

Есть вещи, которые туда класть неудобно. В основном то, что не является UI-состоянием. Я не имею в виду бизнес-логику, это ещё одно слово, значения которого я не знаю, а я имею в виду кэши. Например, если ты фетчишь данные, у тебя есть, скажем, страница Twitter Feed, и эти твиты не State.

Понятно, что обычно мы используем State, если пользуемся чистым React, или используем Redux, кладём всё туда, но так или иначе оно в конечном итоге становится реактовым State где-то внутри или копируется туда.

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

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

Получается, что у людей возникают проблемы вроде zombie children или нестабильного батчинга, я так понимаю, в интеграции со State-менеджерами. Также неясно, как интегрироваться с конкурентным режимом. То есть для большинства state management это не совсем тривиально.

Тут вопрос подразумевает, что вместо того чтобы пользоваться React для UI-состояния, мы пихаем его куда-то ещё и потом синхронизируем. Разложу вопрос по частям.

Первая часть была про то, что в React есть API unstable batched updates и если внутри вызова сделаешь много substates, React всё равно пройдет по дереву один раз, и не будет каких-то странных несоответствий, то, что назвали Zombie children. Это проблема, когда компонент где-то внизу и у него состояние не соответствует чему-то, что он получил по props, потому что другой компонент над ним ещё не обновился.

Эта проблема уходит, если ты делаешь батчинг. Конкурентный режим включает батчинг для всего. Unstable batched updates можно спокойно использовать в любой библиотеке, мы его используем. Это плохой пример, его не нужно было называть unstable, но сейчас уже глупо его переименовывать, потому что в конкурентном режиме это просто default.

В конкурентном режиме он вообще ничего не делает, потому что там всё всегда батчится и даже агрессивнее, чем обычно. Поэтому этой проблемы там нет.

Проблема с синхронизацией, если ты настаиваешь на том, чтобы держать UI State не в React, а где-то ещё, и при этом это не кэш (потому что с кэшами у нас будет своя история).

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

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

Поэтому одно из них если ты выносишь именно UI State, не кэш, из React в какой-то store, то у нас будет несколько стадий, как с этим интегрироваться. Первый вопрос мутабельный ли store или нет, потому что если иммутабельный, то всё прекрасно интегрируется.

Если store мутабельный, то у нас есть API, над которым мы работаем оно будет частью конкурентного релиза, который позволяет интегрироваться. Но некоторые фичи мы хотим сделать поверх конкурентного режима, например, поддержку крутых анимаций.

Они необязательно будут работать с мутабельными сторами. Но у нас есть план добавить другой API если всё равно нужна мутация UI-стора вне React вместо того, чтобы просто использовать React state, мы добавим другое API, которое позволит это делать, если ты реализуешь несколько дополнительных хуков в своей библиотеке.

Но это, скорее всего, будет вторая стадия. В первой мы фокусируемся на иммутабельности, по крайней мере, в конкурентном режиме. Либо мутабельная интеграция, которая немного не идеальна и будет работать не со всеми следующими новыми фичами.

О нормализации данных на клиенте

Продолжая тему внешних источников данных, что ты думаешь о нормализации данных на клиенте, насколько это нужно? Популярные библиотеки для фетчинга, ReactQuerry, UseSWR, не нормализуют данные, в отличие от того же Apollo-клиента.

Интересный вопрос, мне кажется, в нём зарыт какой-то более глубокий вопрос. Какая цель нормализации или денормализации? Их несколько.

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

Но нормализованный кэш как в Apollo или Relay, c GraphQL, если его вручную не менеджерить, это ещё как-то терпимо. Но это накладывает ограничения на структуру данных, и вносит сложные вопросы в духе как работает инвалидация вещей, связанных в этом кэше?, сколько они живут?.

В Redux issue tracker меня года четыре назад спросили: а как часто вещи будут пропадать, если я их держу в Redux. Ну, как перезагрузишь вкладку. Тогда как-то более наивно про всё думал.

В этом смысле нормализованный кэш это то, что люди ассоциируют со state management, особенно если ты его делаешь вручную. Тогда понятно, почему используешь Redux или что-то подобное, какую-то сложную библиотеку, которой доверяешь это делать, как в Apollo.

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

Но если это данные сервера, то окей. Например, мы в команде React пришли к мнению, что оптимистичные апдейты, например, если делаешь пост и он тут же показывается это на самом деле плохо, потому что это дурачит юзера: он может подумать, что всё запостилось и уйти со страницы.

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

Мы рисерчим, и нам ближе всего денормализация, мы движемся в сторону упрощения клиента и больше работы переносим обратно на сервер. В большинстве случаев нормализованный кэш не нужен. Но это зависит от приложения: в Facebook он всё равно будет нужен, но для многих случаев, например, интернет-магазин, это необязательные вещи.

О Redux

В твоих постах периодически видно пассивно-агрессивное отношение к Redux. Почему он тебе так не нравится, учитывая, насколько удобные обёртки написали мейнтейнеры, Redux toolkit и насколько улучшилась документация?

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

Он как тест Роршаха, каждый видит там то, что видит.

Поскольку Redux ничего не предписывает, это просто присваивание переменной. И что? Он не отвечает на вопросы, не решает никаких сложных проблем. Он вносит проблемы что я там держу, как оно там хранится, как это описывать и так далее, но не дает решения, а просто даёт ощущение, что есть какая-то коробка, куда можно что-то класть. А что зависит от каждого проекта.

Обычно получается, по крайней мере, в React-приложениях, что выстраивается параллельная иерархия есть React-дерево, есть Redux-дерево. И люди, которые придумали React, довольно мудро его придумали, что в любой момент можешь скопировать кусочек, вставить, и они не будут зависимыми друг от друга.

А если есть дерево, которое общается с Redux, и тут нужно сделать два независимых дерева удачи.

Люди используют его, чтобы реализовать кэш, потому что в React нет first class-концепции кэша, но каждый реализует это по-своему. Решать проблемы сложно, поэтому они обычно нерешенные. Получается мешанина из boilerplate-кода.

Я не против boilerplate-кода, который имеет какой-то смысл количество строк меня не пугает. Но это концептуальный boilerplate, когда разведены вещи, которые на самом деле тесно связаны. Короче, не нравится мне это всё!

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

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

Что-то как-то решается, но я думаю, что мы постепенно будем закрывать потребности какими-то действительно продуманными решениями. Дело не в том, что тебе не надо использовать Redux. Дело в том, что хочется верить, что для каждой потребности у нас будет что-то лучшее, что тебе не надо будет сваливать всё в один объект куда-то наверх.

Redux это как место, куда ты кладёшь то, что ты не знаешь, куда положить. Хочется, чтобы для всего нашлось место, и тогда туда будет нечего класть.

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

В Facebook разрабатывается state manager Recoil. Это просто ещё один независимый проект внутри компании или решение, на котором вы тестируете и которое когда-нибудь хотите внедрить взамен Redux?

Нет, это совершенно независимый проект. Он разрабатывался для конкретного продукта, потом некоторые другие продукты начали его использовать. Мы общаемся с автором, и есть возможность, что какие-то идеи из Recoil найдут место в React. Не то, что Recoil станет официальным Опять-таки, я не знаю, что такое state management.

Есть технические вопросы, которые Recoil решает лучше, чем то, что у нас есть. Вопрос в том, какая часть фундаментальная, что должно быть в самом React. Мы про это общаемся с автором. Возможно, он поработает над каким-то proof of concept, чтобы посмотреть, на что это похоже, если бы это было в React. Но никаких гарантий. Мы активно следим за всеми state managers, что появлялись за последние пять лет.

О прошлом React

У нас было про перспективу, про state managers, давай в ретроспективе. Была ли какая-то работа над React, куда компания вкладывала кучу сил, над чем-то работала, но оно не взлетело? Какая-то тупиковая ветка?

Мне трудно оценить количественно, но тоже вопрос, что такое тупик. Тупиков было довольно много, и они информируют Приведу дурацкую аналогию: это как Бильбо не прибил Голлума, а потом тот сожрал кольцо, и кольцо в итоге всё же упало, и он свою роль выполнил.

У нас обычно выполняют такую роль проекты, которые не срослись. Например, был прототип React, который работает как в Worker, на другом потоке, и в 2014 году все думали про многопоточность. По нашему опыту, это не особо интересно.

Потому что UI должен отвечать сразу, для многих событий должен быть preventDefault(), который должен быть синхронно. Похожая проблема в React Native: он всегда асинхронный, многие вещи трудно сделать.

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

Это была тупиковая ветка, но она отчасти информировала редизайн React Native. И некоторые вещи, связанные с дата-фетчингом, которые делаем сейчас, отчасти истоки берут из некоторых идей того прототипа.

Ещё пара людей из React-команды существенное время вложили в Prepack экспериментальный компилятор JavaScript в JavaScript, который исполняет JavaScript во время билда. Что достаточно странная идея (как и многие идеи Себастиана). Проект не выгорел слишком сложно, как вскипятить океан.

Но пока мы его делали, узнали, что очень трудно делать какие-то серьезные оптимизации компилятора с классами. Например, трудно два компонента смёрджить в один. С функциями это легко или хотя бы понятно, как делать. С классами никогда не знаешь. Инстанс куда-то убежит, всё ты не знаешь, кто какими полями на нём пользуется, какие методы на нём. Небезопасно что-то переименовывать, и много таких примеров.

Отчасти это было одним из векторов вдохновления для хуков: если делать какой-то очень умный компилятор, это гораздо более разумная для него платформа. И с тем же Suspense, что мы сейчас делаем это тоже отчасти вдохновлено тем, что мы пытались делать с Prepack, но тогда поняли, что у него плохие характеристики и трейд-офф неправильный.

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

О хуках

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

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

Нам тоже было интересно, что люди думают и как у них ощущения. Проводили опрос, собрали где-то 15 тысяч ответов. Там было два вопроса. Один вопрос предпочитаете ли вы хуки, классы, когда как или не знаю, и 70% выбрали, что предпочитают хуки, 10% когда как, 7% классы и остальные не определились.

Другой вопрос был нужно ли использовать в продакшене хуки или классы, и у хуков около 70% было, у классов 50%. И это всего спустя два года после выхода. Уже другая парадигма

Понятно, что когда мы выпускали хуки, говорили, что всё нормально, ничего не меняется. Но по сути это уже другой API, который более правдиво выражает, что такое React, и у него есть лёгкие стороны, есть сложные. Это факт, мы не пытаемся это скрыть. И сейчас переписываем документацию, думаю, будет очень прямолинейны.

Всякие вещи типа useEffect это hard mode у React. И у этого есть причина не потому что мы не можем придумать лучший API или из-за идеологии, а потому что сделать хороший мостик между декларативным и императивным миром сложно.

Приходится думать про комбинации вещей, которые могут произойти, но сходу не придут в голову о race condition, о том, что какие-то вещи могут открыться или закрыться, данные могут поменяться на середине того, как что-то делаешь. И с классами было проще писать код, который как бы работает, но ломается в edge case.

А хуки заставляют тебя обрабатывать такие случаи. И там парадигма, что мы сразу ломаем код. Это бесит, особенно если используешь низкоуровневое типа useEffect ощущение, словно решаешь уравнение. Нужно понять, как так скомпоновать, чтобы всё работало. Но когда получается, понимаешь, что реально работает и для редких случаев, и для типичных.

Ты просто пакуешь в свой хук и всё. Все, кто его использует дальше, могут об этом не думать, потому что ты запаковал сложную императивную хрень в декларативную обёртку. Ей можно просто говорить, что ты хочешь, а она сама это выполнит. И в этом трейд-офф.

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

С тем же конкурентным режимом не так интересно. Но то, что мы можем построить на тех ограничениях, которые он вводит фичи, связанные с анимацией, с дата-фетчингом, это уже интересно.

И хуки гарантия того, что всё будет работать. Потому что они так математически построены. В целом они чем-то бесят, когда перед тобой ставят задачу. Но то, что их можно использовать много раз для нас важнее.

О холиварах

Уведу от хуков немного в холивар, потому что то, что ты говоришь о хуках и сложном варианте React очень близко и Vue.js тоже, потому что у Vue есть новый composition API hard mode Vue. Его очень часто сравнивают с хуками. Даже сейчас в чатике выступления вижу зрительский вопрос о том, что есть вещи, которые Vue утаскивает у React, есть то, что React утаскивает у Vue. Есть куча вопросов, какой фреймворк лучше использовать, кто у кого что утащил, чего нет, а что у кого есть. Тебя не утомила тема о войнах фреймворков и конкуренции?

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

Например, Svelte считает, что генерировать больше кода это окей, зато там очень таргетированные апдейты. Vue считает, что это окей оборачивать данные в какие-то обёртки, и это того стоит, хотя мы тратим больше времени на тот же mount, потому что там будут какие-то апдейты.

Нам же очень важно, чтобы быстро появлялись новые экраны, чтобы был минимальный overhead. В приложениях, которые мы пишем, и в целом в пользовательских приложениях, огромное количество взаимодействий что-то убрать, что-то поставить, а не то, что вот дерево и там что-то глубоко очень быстро обновляется.

Это разные трейд-оффы.

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

Это в целом. Всегда есть парадигма у каждого у Svelte, у Vue, они на самом деле похожи, у Angular и React какая-то парадигма. И всегда будет один фреймворк каждой парадигмы, потому что у каждой парадигмы есть свои сильные и слабые стороны, на которых можно что-то интересное строить.

Поэтому конкуренция будет, есть разные идеи, и у каждой есть свои сильные стороны. Холиварные статьи меня никак не колышут, мне всё равно если можем сделать React лучше, меня это устраивает.

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

Насколько я знаю, Vue уже переписали на TypeScript. Когда, может быть, React перепишут с Flow на TypeScript?

Зачем? Я не то, чтобы какой-то адский фанат Flow, мне и то и другое по большей части по барабану, но это звучит как проект, в котором я не вижу смысла. На definitions, которые публичные, это никак не влияет. Наши внутренние типы всё равно будут другие, потому что то, как ты используешь React, отличается от того, как он реализован. Поэтому это звучит как большой проект, который не даёт для нас никакого выхлопа, и главное для наших юзеров.

Для нас это может дать лучшую IDE-интеграцию, но я не пользуюсь IDE, так что мне всё равно. Контрибьюторов у нас не так много, контрибьютить в core довольно сложно, потому что нужно много контекста для понимания, почему определенные вещи сделаны таким путём. Поэтому смысла, наверное, нет. Если и будем переписывать, то как-то более фундаментально, на тот же Rust или что-то такое. Конкретных планов пока нет.

О личном

Может быть, поговорим о чем-то более личном? Я знаю, что Наташа недавно переехала в Амстердам, я недавно уехала из Лондона. Хотелось бы спросить у Дэна может, ты что-то посоветуешь людям, которые хотят переехать и работать за границей? Может, есть какие-то моменты, на которые, как ты считаешь, нужно обратить внимание?

У меня всё случилось очень быстро, я сам не особо понял, что произошло. Мне было гораздо проще, потому что это большая компания, с агентством по релокации. Есть люди, которые тебя пилят: пришли тот документ, другой. В этом плане проще, чем если бы я сам всё делал.

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

А по коммуникации с командой, с людьми другой культуры возникали сложности?

Нужно быть готовым, что это адский стресс (по крайней мере, так было для меня). Я не у всех понимал акцент. Первые месяцы в голове просто смешались в расплывчатую картинку. Забыл сделать некоторые документы, а через месяц выяснилось, что нужно было сделать их в первые 10 дней, получить какие-то номера.

Надо быть готовым к бюрократии, ничего не будет понятно, будешь уставать. Потом привыкаешь, и становится классно. И ещё стоит сразу найти кого-то, кто тоже переехал и в курсе, как и что делается. Такой человек подскажет, какие бумаги получать.

У тебя в сентябре был твит, что тебе сейчас не нравится работать над каким-то проектами ничего не увлекает особо. Это изменилось, тебе нравится работать над чем-то сейчас, ждешь чего-то увлеченно?

Отчасти да, есть какие-то вещи, над которыми мы работаем. Они набирают обороты, мне интересно за ними следить и немного тоже помогать. Плюс мы с Рейчел (Rachel Nabors прим. ред.) переписываем с нуля документацию React.

Но у меня всё равно чувство вверх-вниз, вверх-вниз, когда в один день кажется классным, что написали, а в другой кажется стрёмным. Чистый лист, вот это всё. Думаю, что сейчас время сложное: я привык, что можно как-то развеяться, куда-то пойти, съездить. А сейчас всё одинаковое, и это немного задолбало.

А в Лондоне сейчас локдаун продолжается?

Да, сейчас собираются снимать, но вместо него вводят другой, с какими-то уровнями. Как-то всё ужасно некомпетентно, мне кажется.

Ты упомянул документацию. Как человек, который работает над документацией в Vue, не могу не спросить ты сказал, что вы всё переписываете с Рейчел, вы только вдвоем работаете над докой? Как вообще организована работа над докой? Кто что пишет?

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

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

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

Потом Рейчел её переписывает, потому что я пишу суховато, или выдвигает предположения, что человек что-то уже знает. А потом я ещё раз делаю техническую правку и вот у нас такой пинг-понг, пока обоим не понравится.

Это очень похоже на то, как мы писали доку Vue 3. Мы тоже держали её в закрытом репозитории, так что я полностью разделяю эту идею. Хотя в какой-то момент люди начали комплейнить, но это была новая версия. А тут версия та же.

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

Это долгосрочный проект, но есть ли очень приблизительная оценка, когда планируете закончить?

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

Этот разговор состоялся на ноябрьской HolyJS а мы сейчас вовсю готовим следующую HolyJS, которая пройдёт 20-23 апреля. Как в случае с этим интервью некоторые вопросы были от зрителей, так и на новой конференции важной частью будут чаты и видеосессии, где зрители могут пообщаться со спикерами и друг с другом. Часть программы уже известна увидеть описания докладов и узнать всё остальное можно на сайте.

Реакт это все что вам нужно для управления состоянием вашего приложения.

Управление состоянием это одна из сложнейших задач при разработки приложения. Вот почему каждый день появляются все новые и новые библиотеки для управления состоянием, их становиться все больше и больше, причем многие из них разрабатываются поверх уже существующих решений. В npm вы можете найти сотни "упрощенных Redux" библиотек. Однако, несмотря на то что управлять состоянием сложно, одной из причин того почему так получилось стало именно то что мы слишком переусложняем решение проблемы.

Существует метод управления состоянием который лично я пытаюсь применять еще с тех пор как я начал использовать Реакт. И теперь, после релиза хуков (hooks) и улучшения контекстов (context), этот метод управления состояниями стало очень просто использовать.

О компонентах Реакта часто говорят как о детальках Лего конструктора, из которых мы собираем наши приложения. Но эту аналогию можно применить не только к компонентам, но и к состоянию приложения. "Секрет" моего подхода к управлению состоянием в том что состояние приложения должно соответствовать структуре самого приложения.

Причиной популярности Редакса (redux), помимо прочего, стало то что react-redux решал проблему проп дриллинга (prop drilling). Редакс позволил обмениваться данными между различными частями дерева компонентов, просто передавая компонент в магическую функцию connect. Другие возможности Редакса редюсеры, экшены и прочее, конечно хороши, но я уверен что повсеместное использование Редакса связано именно с тем, что он позволил избавиться от проп дриллинга.

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

Но применение Редакса может привести к различным проблемам. Я часто вижу как разработчики переносят все состояния приложения в Редакс. Не только глобальное состояние, но и локальные. Это приводит к тому что когда вы создаете любое взаимодействие с состоянием, оно запускает взаимодействие с редюсерами, генераторами/типами экшенов и вызовами dispatch (dispatch calls). Из-за этого, просто чтобы понять как и какие стейты оказывают влияние на приложение, вам нужно открывать кучу файлов и отслеживать весь написанный там код.

Не поймите меня неправильно, это хороший подход для состояний которые действительно должны быть глобальными, но для простых состояний (таких как, например, открыто ли модальное окно или состояние строки ввода у формы) это большая проблема. Что делает ситуацию еще хуже, так это то что такой подход плохо масштабируется. Чем больше становиться ваше приложение, тем хуже становиться эта проблема. Конечно, вы можете подключать различные редюсеры для управления теми или иными частями приложения, но косвенная обработка всех этих генераторов экшенов и редюсеров не является оптимальной.

Держать все состояние вашего приложения в одном объекте не лучшая идея и может привести к другим проблемам (в том числе если вы не используете для этого Редакс). Когда Реакт <Context.Provider> получает новое значение, все компоненты, которые используют это значение, обновляются и запускают рендер, даже если это функциональный компонент который отвечает только за какую-то часть данных. Это может привести к проблемам с производительностью. Что я хочу сказать у вас не будет подобных проблем если ваше состояние разделено и находится в дереве компонентов Реакта таким образом чтобы быть как можно ближе к тем местам к которым это состояние и относиться.

Тут вот какое дело если вы создаете приложение при помощи React, у вас уже установлен пакет для управления состоянием. Чтобы использовать его, вам не нужно применять npm install или yarn add. Этот пакет не добавляет лишних байтов в ваше приложение, он уже интегрирован со всеми библиотеками для Реакта, и он уже хорошо документирован командой Реакта. Это сам Реакт.

Реакт это библиотека для управления состоянием

Когда вы создаете приложение при помощи Реакта, вы собираете множество компонентов, чтобы создать дерево компонентов. Вы начинаете с вашего <App /> и заканчиваете низкоуровневыми <input />, <div /> и <button />. Вы не управляете всеми низкоуровневыми составными компонентами, которые ваше приложение рендерит, из какого-то централизованного места. Вместо этого вы позволяете каждому отдельному компоненту управлять им. Как оказалось, это действительно простой и эффективный способ создания UI.

Такой же подход можно применить и к состоянию:

function Counter() {  const [count, setCount] = React.useState(0)  const increment = () => setCount(c => c + 1)  return <button onClick={increment}>{count}</button>}function App() {  return <Counter />}

Имейте в виду что все, о чем здесь идет речь, работает и с классами. Хуки просто упрощают работу (особенно работу с контекстом, вскоре мы рассмотрим и такой вариант).

class Counter extends React.Component {  state = {count: 0}  increment = () => this.setState(({count}) => ({count: count + 1}))  render() {    return <button onClick={this.increment}>{this.state.count}</button>  }}

"Окей, это конечно легко управлять одним элементом состояния в одном компоненте, но что если мне нужно разделить это состояние между компонентами? Например, что, если я хочу сделать это:

function CountDisplay() {  // откуда нам брать значение для `count`?  return <div>The current counter count is {count}</div>}function App() {  return (    <div>      <CountDisplay />      <Counter />    </div>  )}

"Управление состоянием для подсчета значения происходит внутри <Counter />, выходи, теперь мне нужна библиотека управления состоянием, чтобы получить доступ к значению count для <CountDisplay /> и для его обновлений в <Counter />!"

Ответ этот вопрос настолько же стар, настолько стар и сам Реакт (или старше?), и был в документации столько, сколько я себя помню: Подъём состояния

Подъём состояния (Lifting State Up) это надежный и рекомендуемый способ управления состоянием в Реакте. Вот каким образом можно применять его:

function Counter({count, onIncrementClick}) {  return <button onClick={onIncrementClick}>{count}</button>}function CountDisplay({count}) {  return <div>The current counter count is {count}</div>}function App() {  const [count, setCount] = React.useState(0)  const increment = () => setCount(c => c + 1)  return (    <div>      <CountDisplay count={count} />      <Counter count={count} onIncrementClick={increment} />    </div>  )}

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

"Да, конечно, но что на счет проблемы проп дриллинга (prop drilling)?"

На самом деле это проблема у которой уже довольно давно есть решение контексты (context). На протяжении долгого времени люди применяли react-redux из-за предупреждений в документации Реакта об использовании контекстов. Но сейчас контексты это официально поддерживаемая часть React API, и мы можем использовать их напрямую:

// src/count/count-context.jsimport React from 'react'const CountContext = React.createContext()function useCount() {  const context = React.useContext(CountContext)  if (!context) {    throw new Error(`useCount must be used within a CountProvider`)  }  return context}function CountProvider(props) {  const [count, setCount] = React.useState(0)  const value = React.useMemo(() => [count, setCount], [count])  return <CountContext.Provider value={value} {...props} />}export {CountProvider, useCount}// src/count/page.jsimport React from 'react'import {CountProvider, useCount} from './count-context'function Counter() {  const [count, setCount] = useCount()  const increment = () => setCount(c => c + 1)  return <button onClick={increment}>{count}</button>}function CountDisplay() {  const [count] = useCount()  return <div>The current counter count is {count}</div>}function CountPage() {  return (    <div>      <CountProvider>        <CountDisplay />        <Counter />      </CountProvider>    </div>  )}

ПРИМЕЧАНИЕ. Этот код является просто примером, и я НЕ рекомендую использовать контекст для решения конкретно этой проблемы. В данном случае более простым решением стало бы просто передача состояний через пропсы (подробнее здесь: Prop Drilling). Не нужно применять контексты там где можно обойтись более простыми методами.

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

function useCount() {  const context = React.useContext(CountContext)  if (!context) {    throw new Error(`useCount must be used within a CountProvider`)  }  const [count, setCount] = context  const increment = () => setCount(c => c + 1)  return {    count,    setCount,    increment,  }}

При желании можно поменять useState на useReducer:

function countReducer(state, action) {  switch (action.type) {    case 'INCREMENT': {      return {count: state.count + 1}    }    default: {      throw new Error(`Unsupported action type: ${action.type}`)    }  }}function CountProvider(props) {  const [state, dispatch] = React.useReducer(countReducer, {count: 0})  const value = React.useMemo(() => [state, dispatch], [state])  return <CountContext.Provider value={value} {...props} />}function useCount() {  const context = React.useContext(CountContext)  if (!context) {    throw new Error(`useCount must be used within a CountProvider`)  }  const [state, dispatch] = context  const increment = () => dispatch({type: 'INCREMENT'})  return {    state,    dispatch,    increment,  }}

Это дает нам гибкость и уменьшает сложность кода. Вот о чем следует помнить когда вы так делаете:

1. Не нужно держать все в одном объекте состояния. Разделяйте логику состояния, используйте разные контексты для разных ситуаций, например, пользовательские настройки не обязательно должны находиться в контексте в котором уже находятся уведомления.

   
   

2. Не нужно делать все контексты глобальными! Держите состояние как можно ближе к месту к которому оно относиться.

   
   

Подробнее о втором пункте. Структура вашего приложения может выглядеть примерно так:

function App() {  return (    <ThemeProvider>      <AuthenticationProvider>        <Router>          <Home path="/" />          <About path="/about" />          <UserPage path="/:userId" />          <UserSettings path="/settings" />          <Notifications path="/notifications" />        </Router>      </AuthenticationProvider>    </ThemeProvider>  )}function Notifications() {  return (    <NotificationsProvider>      <NotificationsTab />      <NotificationsTypeList />      <NotificationsList />    </NotificationsProvider>  )}function UserPage({username}) {  return (    <UserProvider username={username}>      <UserInfo />      <UserNav />      <UserActivity />    </UserProvider>  )}function UserSettings() {  // это специальный кастомный хук для AuthenticationProvider  const {user} = useAuthenticatedUser()}

Обратите внимание что у каждой страницы может быть свой собственный провайдер (provider) контекста, который передает данные необходимые компоненту находящемуся под ним. При таком подходе разделение кода (Code-Splitting) работает само по себе. То, как вы передаете данные в каждый провайдер, зависит от того как эти провайдеры используют хуки, и от того каким образом вы извлекаете данные в своем приложении. В любом случае чтобы понять как работает ваш контекст, в первую очередь вам нужно посмотреть в код компонента-провайдера.

Если хотите узнать больше о том что такое "совместное размещение", читайте статью State Colocation will make your React app faster (на русском как сделать React приложение быстрее при помощи совместного размещения состояний
) и Colocation. А если интересно почитать больше о работе с контекстами, читайте статью How to use React Context effectively

Кэш Сервера против Состояние Интерфейса

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

1. Кэш Сервера (Server Cache) состояние которое размещено на сервере для быстрого доступа к нему на клиенте (к примеру данные пользователя).

   
   

2. Состояние Интерфейса (UI State) состояние в котором есть смысл только в интерфейсе пользователя, оно нужно для управления интерактивными частями приложения (к примеру, открытие модального окна modal isOpen)

   
   

Мы совершаем ошибку когда относимся к этим двум одинаково. Кэш сервера сильно отличается от состояния UI, и к нему нужен иной подход. Если вы поняли что ваше состояние это вовсе не состояние, а кэш состояния, то вы начинаете лучше понимать ваше состояние и то как нужно им управлять.

Вы определенно можете управлять им при помощи ваших собственных useState или useReducer, с правильными useContext там и тут. Но, имейте в виду, кэширование это очень сложная проблема (некоторые говорят что это одна из сложнейших проблем в информатике), так что, касательно этого вопроса, будет разумно "встать на плечи гигантов".

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

Заключение

Как я уже говорил, все это вы можете реализовать применяя классовые компоненты (вам не обязательно использовать хуки). Хуки просто делают все намного проще, но вы можете реализовать эту философию и в React 15. Опускайте состояние как можно ниже по иерархии компонентов, и используйте контекст только тогда когда проп дриллинг реально станет проблемой. Все эти действия помогут вам упростить работу с состоянием вашего приложения.

1. Продолжительность жизни данных
2. Частота использования
3. Возможность отслеживания изменений в state

Продолжительность жизни данных

• Часто изменяющиеся данные.
• Редко изменяющиеся данные. Такие данные редко изменяются во время непосредственной работы пользователя с приложением или между сеансами работы с приложением.

Часто изменяющиеся данные

import React from 'react';import { connect } from 'react-redux';import { toggleModal } from './actions/simpleAction'import logo from './logo.svg';import './App.css';import Modal from './elements/modal';const  App = ({                  openModal,                  toggleModal,              }) => {    return (        <div className="App">            <header className="App-header">                <img src={logo} className="App-logo" alt="logo" />            </header>            <main className="Main">                <button onClick={() => toggleModal(true)}>{'Open  Modal'}</button>            </main>            <Modal isOpen={openModal} onClose={() => toggleModal(false)} />        </div>    );}const mapStateToProps = (state) => {    return {        openModal: state.simple.openModal,    }}const mapDispatchToProps = { toggleModal }export default connect(    mapStateToProps,    mapDispatchToProps)(App)// src/constants/simpleConstants.jsexport const simpleConstants = {    TOGGLE_MODAL: 'SIMPLE_TOGGLE_MODAL',};// src/actions/simpleAction.jsimport { simpleConstants} from "../constants/simpleConstants";export const toggleModal = (open) => (    {        type: simpleConstants.TOGGLE_MODAL,        payload: open,    });// src/reducers/simple/simpleReducer.jsimport { simpleConstants } from "../../constants/simpleConstants";const initialState = {    openModal: false,};export function simpleReducer(state = initialState, action) {    switch (action.type) {        case simpleConstants.TOGGLE_MODAL:            return {                ...state,                openModal: action.payload,            };        default:            return state;    }}

import React, {useState} from 'react';import logo from './logo.svg';import './App.css';import Modal from './elements/modal';const  App = () => {  const [openModal, setOpenModal] = useState(false);  return (    <div className="App">      <header className="App-header">        <img src={logo} className="App-logo" alt="logo" />      </header>      <main className="Main">          <button onClick={() => setOpenModal(true)}>{'Open  Modal'}</button>      </main>      <Modal isOpen={openModal} onClose={() => setOpenModal(false)} />    </div>  );}export default App;

Редко изменяющиеся данные

// App.jsimport React from 'react';import './App.css';import Header from './elements/header';import ProfileEditForm from './elements/profileeditform';const  App = () => {  return (    <div className="App">      <Header />      <main className="Main">          <ProfileEditForm />      </main>    </div>  );}export default App;// src/elements/header.jsimport React from "react";import logo from "../logo.svg";import Menu from "./menu";export default () => (    <header className="App-header">        <img src={logo} className="App-logo" alt="logo" />        <Menu />    </header>)// src/elements/menu.jsimport React, {useEffect, useState} from "react";import { getUserInfo } from '../api';const Menu = () => {    const [userInfo, setUserInfo] = useState({});    useEffect(() => {        getUserInfo().then(data => {            setUserInfo(data);        });    }, []);    return (        <>            <span>{userInfo.userName}</span>            <nav>                <ul>                    <li>Item 1</li>                    <li>Item 2</li>                    <li>Item 3</li>                    <li>Item 4</li>                </ul>            </nav>        </>    )}export default Menu;// src/elements/profileeditform.jsimport React, {useEffect, useState} from "react";import {getUserInfo} from "../api";const ProfileEditForm = () => {    const [state, setState] = useState({        isLoading: true,        userName: null,    })    const setName = (e) => {        const userName = e.target.value;        setState(state => ({            ...state,            userName,        }));    }    useEffect(() => {        getUserInfo().then(data => {            setState(state => ({                ...state,                isLoading: false,                userName: data.userName,            }));        });    }, []);    if (state.isLoading) {        return null;    }    return (        <form>            <input type="text" value={state.userName} onChange={setName} />            <button>{'Save'}</button>        </form>    )}export default ProfileEditForm;

// App.jsimport React, {useEffect} from 'react';import {connect} from "react-redux";import './App.css';import Header from './elements/header';import ProfileEditForm from './elements/profileeditform';import {loadUserInfo} from "./actions/userAction";const  App = ({ loadUserInfo }) => {  useEffect(() => {      loadUserInfo()  }, [])  return (    <div className="App">      <Header />      <main className="Main">          <ProfileEditForm />      </main>    </div>  );}export default connect(    null,    { loadUserInfo },)(App);// src/elements/header.jsimport React from "react";import logo from "../logo.svg";import Menu from "./menu";export default () => (    <header className="App-header">        <img src={logo} className="App-logo" alt="logo" />        <Menu />    </header>)// src/elements/menu.jsimport React from "react";import { connect } from "react-redux";const Menu = ({userName}) => (    <>        <span>{userName}</span>        <nav>            <ul>                <li>Item 1</li>                <li>Item 2</li>                <li>Item 3</li>                <li>Item 4</li>            </ul>        </nav>    </>)const mapStateToProps = (state) => {    return {        userName: state.userInfo.userName,    }}export default connect(    mapStateToProps,)(Menu);// src/elements/profileeditform.jsimport React from "react";import { changeUserName } from '../actions/userAction'import {connect} from "react-redux";const ProfileEditForm = ({userName, changeUserName}) => {    const handleChange = (e) => {        changeUserName(e.target.value);    };    return (        <form>            <input type="text" value={userName} onChange={handleChange} />            <button>{'Save'}</button>        </form>    )}const mapStateToProps = (state) => {    return {        userName: state.userInfo.userName,    }}const mapDispatchToProps = { changeUserName }export default connect(    mapStateToProps,    mapDispatchToProps,)(ProfileEditForm);// src/constants/userConstants.jsexport const userConstants = {    SET_USER_INFO: 'USER_SET_USER_INFO',    SET_USER_NAME: 'USER_SET_USER_NAME',    UNDO: 'USER_UNDO',    REDO: 'USER_REDO',};// src/actions/userAction.jsimport { userConstants } from "../constants/userConstants";import { getUserInfo } from "../api/index";export const changeUserName = (userName) => (    {        type: userConstants.SET_USER_NAME,        payload: userName,    });export const setUserInfo = (data) => (    {        type: userConstants.SET_USER_INFO,        payload: data,    })export const loadUserInfo = () => async (dispatch) => {    const result = await getUserInfo();    dispatch(setUserInfo(result));}// src/reducers/user/userReducer.jsimport { userConstants } from "../../constants/userConstants";const initialState = {    userName: null,};export function userReducer(state = initialState, action) {    switch (action.type) {        case userConstants.SET_USER_INFO:            return {                ...state,                ...action.payload,            };        case userConstants.SET_USER_NAME:            return {                ...state,                userName: action.payload,            };        default:            return state;    }}

Частота использования

Глубина передачи state

//App.jsimport React from 'react';import './App.css';import Header from './elements/header';import MainContent from './elements/maincontent';const  App = ({userName}) => {  return (    <div className="App">      <Header userName={userName} />      <main className="Main">          <MainContent />      </main>    </div>  );}export default App;// ./elements/header.jsimport React from "react";import logo from "../logo.svg";import Menu from "./menu";export default ({ userName }) => (    <header className="App-header">        <img src={logo} className="App-logo" alt="logo" />        <Menu userName={userName} />    </header>)// ./elements/menu.jsimport React from "react";export default ({userName}) => (    <>        <span>{userName}</span>        <nav>            <ul>                <li>Item 1</li>                <li>Item 2</li>                <li>Item 3</li>                <li>Item 4</li>            </ul>        </nav>    </>)

// App.jsimport React from 'react';import './App.css';import Header from './elements/header';import MainContent from './elements/maincontent';const  App = () => {  return (    <div className="App">      <Header />      <main className="Main">          <MainContent />      </main>    </div>  );}export default App;//./elements/header.jsimport React from "react";import logo from "../logo.svg";import Menu from "./menu";export default () => (    <header className="App-header">        <img src={logo} className="App-logo" alt="logo" />        <Menu />    </header>)//./elements/menu.jsimport React from "react";import { connect } from "react-redux";const Menu = ({userName}) => (    <>        <span>{userName}</span>        <nav>            <ul>                <li>Item 1</li>                <li>Item 2</li>                <li>Item 3</li>                <li>Item 4</li>            </ul>        </nav>    </>)const mapStateToProps = (state) => {    return {        userName: state.userInfo.userName,    }}export default connect(    mapStateToProps,)(Menu)

Несвязанные компоненты, оперирующие одинаковыми данными в state

// App.jsimport React, {useState} from 'react';import './App.css';import Header from './elements/header';import ProfileEditForm from './elements/profileeditform';const  App = ({user}) => {  const [userName, setUserName] = useState(user.user_name);  return (    <div className="App">      <Header userName={userName} />      <main className="Main">          <ProfileEditForm onChangeName={setUserName} userName={userName} />      </main>    </div>  );}export default App;// ./elements/header.jsimport React from "react";import logo from "../logo.svg";import Menu from "./menu";export default ({ userName }) => (    <header className="App-header">        <img src={logo} className="App-logo" alt="logo" />        <Menu userName={userName} />    </header>)// ./elements/menu.jsimport React from "react";const Menu = ({userName}) => (    <>        <span>{userName}</span>        <nav>            <ul>                <li>Item 1</li>                <li>Item 2</li>                <li>Item 3</li>                <li>Item 4</li>            </ul>        </nav>    </>)export default Menu;// ./elements/profileeditform.jsimport React from "react";export default ({userName, onChangeName}) => {    const handleChange = (e) => {        onChangeName(e.target.value);    };    return (        <form>            <input type="text" value={userName} onChange={handleChange} />            <button>{'Save'}</button>        </form>    )}

// App.jsimport React from 'react';import './App.css';import Header from './elements/header';import ProfileEditForm from './elements/profileeditform';const  App = () => {  return (    <div className="App">      <Header />      <main className="Main">          <ProfileEditForm />      </main>    </div>  );}export default App;//./elements/header.jsimport React from "react";import logo from "../logo.svg";import Menu from "./menu";export default () => (    <header className="App-header">        <img src={logo} className="App-logo" alt="logo" />        <Menu />    </header>)//./elements/menu.jsimport React from "react";import { connect } from "react-redux";const Menu = ({userName}) => (    <>        <span>{userName}</span>        <nav>            <ul>                <li>Item 1</li>                <li>Item 2</li>                <li>Item 3</li>                <li>Item 4</li>            </ul>        </nav>    </>)const mapStateToProps = (state) => {    return {        userName: state.userInfo.userName,    }}export default connect(    mapStateToProps,)(Menu)//./elements/profileeditformimport React from "react";import { changeUserName } from '../actions/userAction'import {connect} from "react-redux";const ProfileEditForm = ({userName, changeUserName}) => {    const handleChange = (e) => {        changeUserName(e.target.value);    };    return (        <form>            <input type="text" value={userName} onChange={handleChange} />            <button>{'Save'}</button>        </form>    )}const mapStateToProps = (state) => {    return {        userName: state.userInfo.userName,    }}const mapDispatchToProps = { changeUserName }export default connect(    mapStateToProps,    mapDispatchToProps,)(ProfileEditForm)

Возможность отслеживания изменений в state

// App.jsimport React from 'react';import './App.css';import Header from './elements/header';import ProfileEditForm from './elements/profileeditform';const  App = () => {  return (    <div className="App">      <Header />      <main className="Main">          <ProfileEditForm />      </main>    </div>  );}export default App;// './elements/profileeditform.js'import React from "react";import { changeUserName, undo, redo } from '../actions/userAction'import {connect} from "react-redux";const ProfileEditForm = ({ userName, changeUserName, undo, redo, hasPast, hasFuture }) => {    const handleChange = (e) => {        changeUserName(e.target.value);    };    return (        <>            <form>                <input type="text" value={userName} onChange={handleChange} />                <button>{'Save'}</button>            </form>            <div>                <button onClick={undo} disabled={!hasPast}>{'Undo'}</button>                <button onClick={redo} disabled={!hasFuture}>{'Redo'}</button>            </div>        </>    )}const mapStateToProps = (state) => {    return {        hasPast: !!state.userInfo.past.length,        hasFuture: !!state.userInfo.future.length,        userName: state.userInfo.present.userName,    }}const mapDispatchToProps = { changeUserName, undo, redo }export default connect(    mapStateToProps,    mapDispatchToProps,)(ProfileEditForm)// src/constants/userConstants.jsexport const userConstants = {    SET_USER_NAME: 'USER_SET_USER_NAME',    UNDO: 'USER_UNDO',    REDO: 'USER_REDO',};// src/actions/userAction.jsimport { userConstants } from "../constants/userConstants";export const changeUserName = (userName) => (    {        type: userConstants.SET_USER_NAME,        payload: userName,    });export const undo = () => (    {        type: userConstants.UNDO,    });export const redo = () => (    {        type: userConstants.REDO,    });// src/reducers/user/undoableUserReducer.jsimport {userConstants} from "../../constants/userConstants";export function undoable(reducer) {    const initialState = {        past: [],        present: reducer(undefined, {}),        future: [],    };    return function userReducer(state = initialState, action) {        const {past, present, future} = state;        switch (action.type) {            case userConstants.UNDO:                const previous = past[past.length - 1]                const newPast = past.slice(0, past.length - 1)                return {                    past: newPast,                    present: previous,                    future: [present, ...future]                }            case userConstants.REDO:                const next = future[0]                const newFuture = future.slice(1)                return {                    past: [...past, present],                    present: next,                    future: newFuture                }            default:                const newPresent = reducer(present, action)                if (present === newPresent) {                    return state                }                return {                    past: [...past, present],                    present: newPresent,                    future: []                }        }    }}// src/reducers/user/userReducer.jsimport { undoable } from "./undoableUserReducer";import { userConstants } from "../../constants/userConstants";const initialState = {    userName: 'username',};function reducer(state = initialState, action) {    switch (action.type) {        case userConstants.SET_USER_NAME:            return {                ...state,                userName: action.payload,            };        default:            return state;    }}export const userReducer = undoable(reducer);

Резюмируя

1. Если эти данные редко изменяются;
2. Если одни и те же данные используются в нескольких (больше 2-3) связанных компонентах или в несвязанных компонентах;
3. Если требуется отслеживать изменения данных.

В этой статье я хочу познакомить с новой библиотекой Urban Bot, которая адаптирует React для написания чат-ботов. Ниже я расскажу, зачем эта библиотека появилась на свет, какие дает преимущества и как написать вашего первого чат-бота.

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

В отличии от большинства чат-бот библиотек, которые чаще всего просто оборачивают http запросы в функции с готовыми аргументами и предоставляют подписки вида bot.on('message', callback), иногда позволяя передавать контекст между вызовами, Urban Bot предлагает совершенно иной подход к разработке чат-ботов через декларативное программирование и компонентный подход. Живой пример, написанный на Urban Bot, вы можете попробовать в Telegram, cсылка на чат-бот, и посмотреть код на GitHub.

Как мы заметили выше, чат-боты это полноценные UI приложения. А какой язык в 2020 и какая библиотека наиболее подходит для разработки UI приложений? Правильно, JavaScript и React. Такая интеграция позволяет легко и непринужденно строить чат-боты любой сложности без единого знания об API мессенджеров. Далее я расскажу, как создавать простые компоненты и на их основе строить сложных чат-ботов, работать с навигацией, создавать диалоги любой вложенности, писать одно приложение и запускать в любых мессенджерах, и многое другое.

Отправка сообщений

Так выглядит самый простой пример на Urban Bot. Для отправки текстового сообщения нам нужно создать функцию и вернуть из него готовый компонент Text с текстом внутри, который мы хотим отправить. Когда компонент отрендериться, все пользователи чат-бота получат сообщение "Hello, world!".

import React from 'react';import { Text } from '@urban-bot/core';function App() {    return (        <Text>           Hello, world!        </Text>    );}

Изображение можно отправить так:

import React from 'react';import { Image } from '@urban-bot/core';function App() {    const imageByURL =  'https://some-link.com/image.jpg';    return <Image file={imageByURL} />;}

Urban Bot имеет готовый набор компонентов, для каждого вида сообщений, для файлов File, для кнопок ButtonGroup и много других, подробнее можно взглянуть здесь. В каждый из них можно передать определенный набор пропсов, например, имитировать будто бот печатает сообщение 1 секунду <Text simulateTyping={1000}>.

Получение сообщений

Мы рассмотрели как посылать сообщения, давайте разберемся как подписываться на сообщения от пользователей. За подписки в Urban Bot отвечают React Hooks.

Чтобы подписаться на текстовые сообщения, мы можем использовать хук useText.

import React from 'react';import { Text, useText } from '@urban-bot/core';function App() {    useText(({ text }) => {        console.log(`Пользователь отправил сообщение ${text}`);    });    return (        <Text>            Hello, world!        </Text>    );}

Urban Bot предоставляет готовы набор хуков для разных типов сообщений. Например, useImage, если пользователь отправил изображение, useFile и т.д. Полный список здесь. В каждый хук также приходит мета информация, кто отправил сообщение и т.д.

Эхо бот

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

В этом компоненте мы впервые добавим работу с переменными через React хук useState. Этот хук возвращает переменную и функцию, чтобы ее изменять. React.useState нужен, чтобы изменение переменной приводило к ререндеру и, соответсвенно, отправке нового сообщения. Мы определим начальное значение переменной text как "Привет" и передадим в компонент Text. Также мы подпишемся на сообщения от пользователей с помощью хука useText, и будем изменять text через функцию setText. После вызова setText React перерендерит компонент Echo с новым значением, и пользователь получит новое сообщение с тем что он сам отправил боту.

import React from 'react';import { Text, useText } from '@urban-bot/core';function Echo() {    const [text, setText] = React.useState('Привет!');    useText(({ text }) => {        setText(text);    });    return (        <Text>            {text}        </Text>    );}

Кнопки

Давайте также напишем пример с кнопками, сделаем простейший счетчик. Для этого нам понадобятся компоненты ButtonGroup и Button. Каждой кнопке мы определим свой обработчик, который будет менять count на +1 или -1 и будем передавать результат в ButtonGroup в проп title. Мы установим проп isNewMessageEveryRender как false, чтобы при последующих ререндерах отправлялось не новое сообщение с новыми кнопками, а просто изменялось начальное сообщение.

import React from 'react';import { ButtonGroup, Button } from '@urban-bot/core';function Counter() {    const [count, setCount] = React.useState(0);    const increment = () => setCount(count + 1);    const decrement = () => setCount(count - 1);    return (        <ButtonGroup title={count} isNewMessageEveryRender={false}>            <Button onClick={increment}>+1</Button>            <Button onClick={decrement}>-1</Button>        </ButtonGroup>    );}

Навигация

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

Теперь, когда пользователь напишет "/echo" отрендериться компонент Echo, когда "/counter" управление перейдет в Counter. Роуты также могут принимать path как regexp.

import React from 'react';import { Router, Route } from '@urban-bot/core';import { Echo } from './Echo';import { Counter } from './Counter';function App() {    return (        <Router>            <Route path="/echo">                <Echo />            </Route>            <Route path="/counter">                <Counter />            </Route>        </Router>    );}

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

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

Форматирование текста

Urban Bot позволяет стилизовать сообщения через привычные HTML теги. Писать жирным <b>, курсивом <i>, зачеркнутым <s>, переносить строки <br /> и так далее, полный список здесь.

const someCode = `function sum2() {    return 2 + 2;}if (sum2() !== 4) {    console.log('WTF');}`;<Text>    Usual text    <br />    <b>Bold text</b>    <br />    <i>Italic text</i>    <br />    <u>Underscore text</u>    <br />    <s>Strikethrough text</s>    <br />    <q>quote</q>    <br />    <b>        Bold and <s>Strikethrough text</s>    </b>    <br />    <code >Code 2 + 2</code >    <br />    <pre>{someCode}</pre>    <br />    <a href="http://personeltest.ru/aways/github.com/urban-bot/urban-bot">External link</a></Text>

Диалоги

Чат-боты могут вести диалоги с пользователем, что-то спрашивать, реагировать на сообщения в зависимости от ответа пользователя. В Urban Bot встроен компонент Dialog, который позволяет легко создавать диалоги любой сложности.

Пример плоского диалога. Бот задаст первый вопрос, после ответа задаст второй, потом третий, потом запустит callback onFinish с готовыми ответами. На каждом шаге можно обрабатывать ответ пользователя через callback onNext.

import React from 'react';import { Dialog, DialogStep, Text } from '@urban-bot/core';function FlatDialogExample() {    return (        <Dialog onFinish={(answers) => console.log(answers)}>            <DialogStep                content={<Text>Привет, как тебя зовут?</Text>}                 id="name"                onNext={(name) => console.log(name)}            >                <DialogStep                    content={<Text>Cколько тебе лет?</Text>}                    id="age"                >                    <DialogStep                         content={<Text>Из какого ты города?</Text>}                        id="city"                    />                </DialogStep>            </DialogStep>        </Dialog>    );}

Можно получать на следующем шаге прошлый ответ через паттерн render-props .

function FlatDialogExample() {    return (        <Dialog>            <DialogStep content={<Text>Привет, как тебя зовут?</Text>}>                {(name) => (                    <DialogStep                         content={<Text>{`${name}, cколько тебе лет?`}</Text>}                    />                )}            </DialogStep>        </Dialog>    );}

Можно добавить валидацию на каждый шаг.

function FlatDialogExample() {    return (        <Dialog onFinish={(answers) => console.log(answers)}>            <DialogStep                content={<Text>Привет, как тебя зовут?</Text>}                id="name"                validation={{                     isValid: (answer) => answer !== 'Самуэль',                     errorText: 'Самуэль заблокирован.'                 }}            >                // ...            </DialogStep>        </Dialog>    );}

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

import React from 'react';import { Dialog, DialogStep, Text, ButtonGroup, Button } from '@urban-bot/core';function TreeDialogExample() {    return (        <Dialog>            <DialogStep                content={                    <ButtonGroup title="Привет, что вы хотите купить?">                        <Button id="hat">Футболка</Button>                        <Button id="glasses">Очки</Button>                    </ButtonGroup>                }            >                <DialogStep                    match="hat"                    content={                        <ButtonGroup title="Футболка какого размера?">                            <Button id="m">S</Button>                            <Button id="s">M</Button>                            <Button id="l">L</Button>                        </ButtonGroup>                    }                />                <DialogStep                    match="glasses"                    content={                        <ButtonGroup title="Очки какого цвета?">                            <Button id="black">Черный</Button>                            <Button id="white">Белый</Button>                        </ButtonGroup>                    }                />            </DialogStep>        </Dialog>    );}

Состояние

Что вы можете использовать для управления состоянием? Все то же что и в любом React приложении. Можете использовать React useState и передавать состояние ниже по дереву компонентов через пропсы или React Context. Можно использовать библиотеки для управления состоянием: Redux (пример), MobX (пример), Apollo и любые другие, которые обычно используют вместе с React, вы можете даже переиспользовать готовые части из готовых React Web или React Native приложений, так как Urban Bot использует тот же чистый React, который работает в миллионах приложений.

Сессия

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

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

function Counter() {    const [count, setCount] = React.useState(0);    const increment = () => setCount(count + 1);    const decrement = () => setCount(count - 1);    return (        <ButtonGroup title={count} isNewMessageEveryRender={false}>            <Button onClick={increment}>+1</Button>            <Button onClick={decrement}>-1</Button>        </ButtonGroup>    );}

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

function Counter() {    const [count, setCount] = useGlobalCount();   // ...}

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

import React from 'react';import { Text, useText, useBotContext } from '@urban-bot/core';function UserId() {    const { chat } = useBotContext();    useText(({ from }) => console.log(`Пришло сообщение от ${from.username}`));   return <Text>Чат id {chat.id}</Text>;}

Типизация

Urban Bot написан на TypeScript, соответсвенно проект полностью типизирован, и если вы пишете на TypeScript, вам будет очень удобно.

Запуск в мессенджерах

Большой плюс Urban Bot, что он не привязан ни к одному мессенджеру. Есть основной пакет @urban-bot/core, который позволяет создавать абстрактных чат-ботов, а уже их подключать к определенным мессенджерам. В данный момент есть поддержка Telegram, Slack, Facebook. В дальнейшем, мы планируем добавлять любые мессенджеры, где есть чат-боты и открытое API. Если вам интересно, и вы хотите писать Urban Bot приложения для других мессенджеров, скажем Viber, Discord или у вас есть свой мессенджер то пишите к нам в группу https://t.me/urbanbotjs, одной просьбы будет достаточно, чтобы появилось большая мотивация реализовать ваш функционал.

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

Скажем, у нас есть готовое приложение App и мы хотим его запустить его в Telegram. Для этого нам понадобится класс UrbanBotTelegram из пакет @urban-bot/telegram. Функция render из @urban-bot/core подобная ReactDOM.render и компонент Root. Мы создаем экземпляр UrbanBotTelegram и передаем туда бот токен из Telegram, также можно передать isPolling, чтобы не настраивать вебхук, и бот работал локально. Готовый экземпляр мы передаем в компонент Root, и оборачиваем наше готовое приложение и, соответсвенно, передаем все в функцию render, которая запустит все процессы.

Более подробная инструкция с видео как разрабатывать локально и деплоить Telegram бота можно прочитать в инструкции.

import React from 'react';import { render, Root } from '@urban-bot/core';import { UrbanBotTelegram } from '@urban-bot/telegram';import { App } from './App';const urbanBotTelegram = new UrbanBotTelegram({    token: 'telegramToken',    isPolling: true,});render(    <Root bot={urbanBotTelegram}>        <App />    </Root>);

Если нам нужно запустить два и более мессенджера, просто используем пакеты других мессенджеров, передаем туда нужные данные и делаем по аналогии с Telegram.

// ...import { UrbanBotSlack } from '@urban-bot/slack';// ...render(    <Root bot={urbanBotTelegram}>        <App />    </Root>);const urbanBotSlack = new UrbanBotSlack({    signingSecret: 'slackSigningSecret',    token: 'slackToken',});render(    <Root bot={urbanBotSlack}>        <App />    </Root>);

Прямой вызов API

С помощью Urban Bot вы можете создавать чат-ботов просто описывая их через компоненты. А что если вам будет нужно вручную вызвать API? Каждый экземпляр UrbanBot* содержит в себе API клиент для активного мессенджера. Рассмотрим пример для Telegram.

Мы можем получить bot с помощью хука useBotContext. bot содержит client и type c типом мессенджера. client будет представлять собой экземпляр библиотеки node-telegram-bot-api . В любом месте приложения можно получить client и вызвать любой метод на ваше усмотрение, скажем блокировать пользователя, если он написал нецензурное сообщение.

import React from 'react';import { useText, useBotContext } from '@urban-bot/core';function SomeComponent() {    const { bot } = useBotContext();    useText(({ text, chat, from }) => {        if (text.includes('бл***')) {            bot.client.kickChatMember(chat.id, from.id);        }    });    // ...}

В каждом мессенджере уникальный API. Если вы разрабатываете несколько мессенджеров одновременно, можно отделять функционал сравнивая bot.type.

import { useBotContext } from '@urban-bot/core';import { UrbanBotTelegram } from '@urban-bot/telegram';import { UrbanBotSlack } from '@urban-bot/slack';function SomeComponent() {    const { bot } = useBotContext();    if (bot.type === UrbanBotTelegram.type) {        // telegram api        bot.client.kickChatMember(/* ... */);    }    if (bot.type === UrbanBotSlack.type) {        // slack api        bot.client.conversations.kick(/* ... */);    }    // ...}

Как попробовать?

У Urban Bot есть стартер, который позволит вам начать разрабатывать чат-ботов за минуту, сделан по аналогии с create-rect-app. Все что вам нужно, чтобы попробовать Urban Bot это выполнить команду в терминале для

TypeScript

npx create-urban-bot my-app

JavaScript

npx create-urban-bot my-app --template js

Команда склонирует шаблон приложения с нужными зависимостями и скриптами на ваш компьютер, и вам останется только открыть проект, передать ваши токены в .env файл и расскоментировать мессенджеры, которые вы хотите разрабатывать. Видео инструкция.

Итого

Несмотря на то что Urban Bot запустился только недавно, на мой взгляд это библиотека с огромным потенциалом. Только представьте, если у вас есть базовые знания React, вы можете написать чат-бот любой сложности на все возможные платформы, создавать и использовать библиотеки с готовым набором компонентов на манер ui-kit, переиспользовать код между вашими другими UI приложеними на React, будь то web или mobile.

Если вы уже разрабатывали чат-ботов, попробуйте Urban Bot, вы почувствуете как библиотека делает за вас кучу работы. Если никогда не разрабатывали, но имеете представление о React, то напишете вашего первого чат-бота за 5 минут. Если вам понравилась идея и хотите, чтобы проект развивался дальше, вступайте в нашу группу в Telegram, ставьте звезду на гитхабе, будем рады любому фидбеку.

Полезные ссылки

Сайт
Github
Группа в Telegram
Наглядный чат-бот в Telegram, с открытым кодом.
Как создать Todo List чат-бот в Telegram с помощью React.js

• Разработка библиотеки компонентов на React + Storybook
• Разработка через тестирование в JS или как начать любить программирование
• Миграция реального проекта с Javascript на Typescript боли и особенности

Стандартный подход: используем пропсы для передачи значений

Чудовище по имени Redux

Новый взгляд на общие значения в React

// components.jslet components = {};export default components;

// content.area.jsimport components from './components';import MainContentArea from './main.content.area';import React from 'react';export default class ContentArea extends React.Component {   constructor(props) {      super(props);      components.ContentArea = this;   }   consoleLog(value) {      console.log(value);   }   render() {      return <MainContentArea/>;   }}

// ticket.detail.jsimport components from './components';import React from 'react';export default class TicketDetail extends React.Component {   render() {      components.ContentArea.consoleLog('it works');      return <div>Here are the ticket details.</div>;   }}

1. Компонент ContentArea при загрузке добавил в общий объект components ссылку на себя.
2. Компонент TicketDetail при загрузке импортировал общий объект components, то есть у него был прямой доступ к компоненту ContentArea, несмотря на то что свойства ContentArea не передавались компоненту TicketDetail через пропсы.

// content.area.jsimport components from './components';import MainContentArea from './main.content.area';import React from 'react';export default class ContentArea extends React.Component {   constructor(props) {      super(props);      this.state = { reduxSucks:true };      components.ContentArea = this;   }   render() {      return <MainContentArea/>;   }}

// ticket.detail.jsimport components from './components';import React from 'react';export default class TicketDetail extends React.Component {   render() {      if (components.ContentArea.state.reduxSucks === true) {         console.log('Yep, Redux is da sux');      }      return <div>Here are the ticket details.</div>;   }}

// content.area.jsimport components from './components';import MainContentArea from './main.content.area';import React from 'react';export default class ContentArea extends React.Component {   constructor(props) {      super(props);      this.state = { reduxSucks:true };      components.ContentArea = this;   }   toggleReduxSucks() {      this.setState((previousState, props) => {         return { reduxSucks: !previousState.reduxSucks };      });   }   render() {      return <MainContentArea/>;   }}

// ticket.detail.jsimport components from './components';import React from 'react';export default class TicketDetail extends React.Component {   render() {      if (components.ContentArea.state.reduxSucks === true) {         console.log('Yep, Redux is da sux');      }      return (         <>            <div>Here are the ticket details.</div>            <button onClick={() => components.ContentArea.toggleReduxSucks()}>Toggle reduxSucks</button>         </>      );   }}

// content.area.jsimport components from './components';import MainContentArea from './main.content.area';import React from 'react';export default class ContentArea extends React.Component {   constructor(props) {      super(props);      this.state = { reduxSucks:true };      components.ContentArea = this;   }   toggleReduxSucks() {      this.setState((previousState, props) => {         return { reduxSucks: !previousState.reduxSucks };      });      components.TicketTable.incrementReduxSucksHasBeenToggledXTimes();   }   render() {      return <MainContentArea/>;   }}

// ticket.table.jsimport components from './components';import React from 'react';import TicketRow from './ticket.row';export default class TicketTable extends React.Component {   constructor(props) {      super(props);      this.state = { reduxSucksHasBeenToggledXTimes: 0 };      components.TicketTable = this;   }   incrementReduxSucksHasBeenToggledXTimes() {      this.setState((previousState, props) => {         return { reduxSucksHasBeenToggledXTimes: previousState.reduxSucksHasBeenToggledXTimes + 1};      });         }   render() {      const {reduxSucksHasBeenToggledXTimes} = this.state;      return (         <>            <div>The `reduxSucks` value has been toggled {reduxSucksHasBeenToggledXTimes} times</div>            <TicketRow data={dataForTicket1}/>            <TicketRow data={dataForTicket2}/>            <TicketRow data={dataForTicket3}/>         </>      );   }}

// ticket.detail.jsimport components from './components';import React from 'react';export default class TicketDetail extends React.Component {   render() {      if (components.ContentArea.state.reduxSucks === true) {         console.log('Yep, Redux is da sux');      }      return (         <>            <div>Here are the ticket details.</div>            <button onClick={() => components.ContentArea.toggleReduxSucks()}>Toggle reduxSucks</button>         </>      );   }}

1. Монтируем и рендерим ContentArea.
2. В ходе этого процесса в объект components загружается ссылка на ContentArea.
3. В результате монтируется и рендерится TicketTable.
4. В ходе этого процесса в объект components загружается ссылка на TicketTable.
5. В результате монтируется и рендерится TicketDetail.
6. У пользователя появляется кнопка Изменить значение reduxSucks (Toggle reduxSucks).
7. Пользователь нажимает кнопку Изменить значение reduxSucks.
8. Нажатие кнопки вызывает функцию toggleReduxSucks(), которая записана в компоненте ContentArea.
9. Это в свою очередь вызывает функцию incrementReduxSucksHasBeenToggledXTimes() из компонента TicketTable .
10. Все работает, потому что к тому моменту, когда пользователь сможет нажать кнопку Изменить значение reduxSucks, ссылка на компонент TicketTable будет загружена в объект components. А функция toggleReduxSucks() при вызове из ContentArea сможет найти ссылку на функцию incrementReduxSucksHasBeenToggledXTimes(), записанную в TicketTable, в объекте components.

Инструменты управления состоянием на свалку

Известные проблемы этого подхода

• Лучше всего он работает с одиночками.
  Например, в нашей иерархии в компоненте находятся компоненты со связью ноль-ко-многим. Если вы захотите кешировать ссылку на каждый потенциальный компонент внутри компонентов (и их дочерних компонентов ) в кеш components, вам придется сохранить их в массив, и тут могут возникнуть сложности. Я всегда избегал этого.
  При кешировании объекта components предполагается, что мы не можем использовать переменные/функции из других компонентов, если они не были загружены в объект components. Это очевидно.
  Если архитектура вашего приложения делает такой подход нецелесообразным, то не надо его использовать. Он идеально подходит для одностраничных приложений, когда мы уверены в том, что родительский компонент всегда монтируется раньше потомка. Если вы решили сослаться на переменные/функции потомка непосредственно из родительского компонента, создавайте такую структуру, которая будет выполнять эту последовательность только после загрузки потомка в кеш components.
  Можно считывать переменные состояния из других компонентов, ссылки на которые хранятся в кеше components, но если вы захотите обновить такие переменные (через setState()), вам придется вызвать функцию setState(), которая записана в соответствующем компоненте.
  
  
  

  Ограничение ответственности

  
  Теперь, когда я рассказал о своем подходе и некоторых его ограничениях, я обязан предупредить вас. С тех пор как я открыл этот подход, я то и дело рассказываю о нем людям, которые считают себя профессиональными React-разработчиками. Каждый раз они отвечают одно и то же:
  
  Хм Не делай этого
  Они морщатся и ведут себя так, будто я только что испортил воздух. Что-то в моем подходе кажется им неправильным. И при этом еще никто не объяснил мне, исходя из своего богатого практического опыта, что именно не так. Просто все считают мой подход кощунством.
  
  Поэтому даже если вам нравится этот подход или если он кажется вам удобным в некоторых ситуациях, я не рекомендую говорить о нем на собеседовании, если вы хотите получить должность React-разработчика. Думаю, что, даже просто разговаривая с другими React-разработчиками, нужно миллион раз подумать, прежде чем сказать об этом способе, а может, лучше вообще ничего не говорить.
  
  Я обнаружил, что JS-разработчики и, в частности, React-разработчики бывают слишком категоричны. Иногда они действительно объясняют, почему подход А неправильный, а подход Б правильный. Но в большинстве случаев они просто смотрят на фрагмент кода и объявляют, что он плохой, даже если сами не могут объяснить, почему.
  
  

  Так почему же этот подход так раздражает React-разработчиков?

  
  Как я уже говорил, ни один из моих коллег не смог обоснованно ответить, чем плох мой способ. А если кто-нибудь и готов удостоить меня ответом, то обычно это одна из следующих отговорок (их мало).
  
  
  • С таким подходом о чистых функциях можно забыть, он захламляет приложение жесткими зависимостями.
    Окей...Понял. Но те самые люди, которые с ходу отвергли этот подход, с удовольствием будут использовать Redux (или MobX, или любое другое средство управления состоянием) почти со всеми классами/функциями в своих React-приложениях. Я не отрицаю, что иногда без инструментов управления состоянием действительно сложно обойтись. Но любой такой инструмент по своему характеру это гигантский генератор зависимостей. Каждый раз, когда вы используете инструменты управления состоянием с функциями/классами, вы захламляете приложение зависимостями. Обратите внимание: я не говорил, что нужно отправлять каждую функцию или класс в кеш объекта components. Вы самостоятельно решаете, какие именно функции/классы будут кешироваться в components, а какие функции/классы будут обращаться к тому, что вы поместили в кеш components. Если вы пишете чистую вспомогательную функцию/класс, то наверняка моя идея с кешем components вам не подходит, потому что для кеширования в components компоненты должны знать о других компонентах приложения.Если вы пишете компонент, который будет использоваться в разных фрагментах кода вашего приложения или даже в разных приложениях, не применяйте этот подход. Но опять же, если вы создаете такой глобальный компонент, в нем не нужно использовать ни Redux, ни MobX, ни какое-либо еще средство управления состоянием.
  • Просто в React так не делается. Или Это не соответствует отраслевым стандартам.
    Ага Это мне говорили не раз. И знаете что? Когда я это слышу, я даже немножко перестаю уважать своего собеседника. Если единственная причина это какое-то размытое так не делается или отраслевой стандарт, который сегодня один, а завтра другой, то разработчик просто чертов лентяй. Когда появилась React, у нас не было вообще никаких инструментов управления состоянием. Но люди начали изучать эту библиотеку и решили, что они нужны. И их создали.Если вы действительно хотите соответствовать отраслевым стандартам, просто передавайте все переменные состояния и все обратные вызовы функций через пропсы.Но если вам кажется, что базовая реализация React не удовлетворяет ваши потребности на 100 %, откройте глаза (и разум) и взгляните повнимательней на нестандартные решения, которые не были одобрены лично господином Дэном Абрамовым.
  
  
  

  Итак, что скажете В?

  
  Я написал этот пост, потому что уже годами использую этот подход (в личных проектах). И он работает превосходно. Но каждый раз, когда я вылезаю из своего личного пузыря и пытаюсь вести интеллектуальную беседу об этом подходе с другими, сторонними React-разработчиками, я сталкиваюсь только с категоричными заявлениями и бестолковыми суждениями об отраслевых стандартах.
  
  Этот подход действительно плох? Ну правда. Я хочу знать. Если это действительно антипаттерн, я буду безмерно благодарен тем, кто обоснует его неправильность. Ответ я к такому не привык меня не устроит. Нет, я не зациклился на этом методе. Я не утверждаю, что это панацея для React-разработчиков. И я признаю, что он подходит не для всех ситуаций. Но может хоть кто-нибудь объяснить мне, что в нем не так?
  
  Мне очень хочется узнать ваше мнение по этому поводу даже если вы разнесете меня в пух и прах.
  
  

  Бесплатные уроки:

  
  
  • Разработка библиотеки компонентов на React + Storybook
  • Разработка через тестирование в JS или как начать любить программирование
  • Миграция реального проекта с Javascript на Typescript боли и особенности

Мне с друзьями довелось поучаствовать в хакатоне
SberCloud.Advanced Hacking и пощупать облачные сервисы Сбера. На моем текущем месте работы я каждый день работаю с Serverless стеком от AWS (CloudFront + Lambda Edge + S3 + Lambda + Step Functions + Aurora PostgreSQL Serverless + DynamoDB + Cognito). Так что мне есть с чем сравнить. Если заинтересовались, то добро пожаловать под кат.

Недавно Сбер выкатил в публичный доступ свою облачную платформу SberCloud. К сожалению, сейчас, чтобы ей воспользоваться, нужно быть юридическим лицом. Представители Сбера говорят, что, возможно, доступ для физических лиц появится в следующем году. Но тем не менее, в рамках хакатона, я смог посмотреть, что там внутри, как обычный смертный. Что я там увидел? Огромное количество сервисов прям, как у AWS, на любой вкус https://sbercloud.ru/ru/products.

Меня прежде всего интересовал Serverless стек. Вообще, мало кто может похвастаться настоящими Serverless сервисами, у которых стоимость использования зависит только от реальной нагрузки. Сервером с платой за месяц уже ни кого не удивишь.

Я хотел собрать приложение аналогичное такому в AWS.

Вот что получилось на стеке SberCloud.

Я быстренько создал лямбду FunctionGraph.

Прикрутил к ней API Gateway. Настроил HTTP/HTTPS trigger.

Кстати, читать логи лямбды оказалось намного удобнее чем в AWS. Всё в одном месте. Ненужно прыгать по вкладкам и искать нужный Log Stream.

К сожалению, настоящей Serverless базы данных у SberCloud не нашлось. Пришлось взять сервис с фиксированной платой.

Настроил Environment variables от PostgreSQL пользователя у лямбды FunctionGraph.

Написал небольшой Serverless адаптер для работы с PostgreSQL базой из лямбды. Нужно аккуратно закрывать за собой соединения, а то они кончатся.

import { Client } from 'pg'export const escapeId = (str: string): string => `"${String(str).replace(/(["])/gi, '$1$1')}"`export const escapeStr = (str: string): string => `'${String(str).replace(/(['])/gi, '$1$1')}'`export const executeStatement = async <T extends Record<string, any>>(  sql: string): Promise<Array<T>> => {  const client = new Client()  await client.connect()  try {    const res = await client.query(sql)    return res.rows  } finally {    await client.end()  }}

Настроил Object Storage Service.

Некое SDK для работы с SberCloud имеется, но чего-то полезного мне там найти не удалось.

Для загрузки картинок из браузера в Object Storage Service через подписанный URL код пришлось писать самому. Не самое приятное занятие угадывать сигнатуры и считать хеши руками.

async (req: Request, res: Response) => {  validateUserHandler(req, res)  const { authToken } = context  const { userId } = req.params  const uploadId = uuidV4()  const body = Buffer.from(    JSON.stringify({      auth: {        identity: {          methods: ['token'],          token: {            id: authToken,            'duration-seconds': '900',          },        },      },    }),    'utf8'  )  const options = {    hostname: 'iam.ru-moscow-1.hc.sbercloud.ru',    port: 443,    path: '/v3.0/OS-CREDENTIAL/securitytokens',    method: 'POST',    headers: {      'Content-Type': 'application/json; charset=utf8',      'Content-Length': body.length,    },  }  const credentialBuffer: Buffer = await new Promise((resolve, reject) => {    const req = https.request(options, (res) => {      res.on('data', (data) => {        resolve(data)      })      res.on('error', (error) => {        reject(error)      })    })    req.write(body)    req.end()  })  const {    credential,  }: {    credential: { securitytoken: string; secret: string }  } = JSON.parse(credentialBuffer.toString('utf8'))  const { securitytoken, secret } = credential  const stringToSign = Buffer.from(    JSON.stringify({      expiration: '2020-12-31T12:00:00.000Z',      conditions: [        { 'x-obs-acl': 'public-read' },        { 'x-obs-security-token': securitytoken },        { bucket: 'anti-cube-images' },        ['starts-with', '$key', `${userId}/`],      ],    }),    'utf8'  ).toString('base64')  const hmac = crypto.createHmac('sha1', secret)  hmac.update(stringToSign)  const signature = hmac.digest('base64')  res.json({    uploadId,    signature,  })}

В целом SberCloud мне понравился. Очень достойно. Не ожидал увидеть международный уровень облачных сервисов на российском рынке. Желаю Сберу обзавестись настоящей Serverless базой данных с платой только за использование. Лучше смотреть в этом плане в сторону CosmosDB от Azure или опенсорсного TiDB на своих серверах. У AWS сделано не особо грамотно, не копируйте у них.

Дополнительно про SberCloud можно посмотреть на YouTube:

• SberCloud Advanced Hacking. Вебинар по Graph Engine Service
• SberCloud Advanced Hacking. Вебинар по API Gateway
• SberCloud Advanced Hacking. Вебинар по Function Graph
• SberCloud.Advanced Hacking // Открытие хакатона
• SberCloud.Advanced Hacking // Воркшоп. Петр Предтеченский
• SberCloud.Advanced Hacking // Воркшоп. Павел Кутаков

Документация: https://docs.sbercloud.ru/

На хакатоне мы с ребятами делали изоморфное приложение на React+Redux. Презентация нашего проекта: https://docs.google.com/presentation/d/1LNjg2xfFHljTuH6ke_lkF6o1m9HTfemWcxW0w1OOssc/edit?usp=sharing

Примечание к переводу: Оригинальная статья была написана до того как стало известно о MV3. Тем не менее она полностью актуальна и для MV3 расширений (по крайней мере на данный момент). Поэтому я решил немного изменить ее название, добавив упоминание "MV3", что нисколько не противоречит содержанию. Если кто не в курсе: MV3 новый формат/стандарт расширений Chrome, должен быть введен в январе 2021 года.

В этой статье, предназначенной для опытных веб-разработчиков, рассматривается (и решается) проблема использования Redux в т.н. событийно-ориентированных (event-driven) расширениях Chrome.

Специфика событийно-ориентированных расширений

Событийно-ориентированная модель расширения впервые появилась в Chrome 22 в 2012 г. В этой модели фоновый скрипт расширения (если есть) загружается/выполняется только когда это нужно (в основном в ответ на события) и выгружается из памяти когда он ничего не делает.

Документация Chrome разработчика настоятельно советует использовать событийно-ориентированную модель для всех новых расширений, а для уже существующих расширений, использующих постоянную (persistent) модель делать миграцию. Есть правда одно исключение (в MV3 уже не актуально, в т.ч. поэтому переход на новую модель в MV3 обязателен). Но похоже что многие расширения до сих пор используют постоянную модель, даже если могут быть событийно-ориентированными. Конечно, многие из них были впервые выпущены до того, как стало известно о событийно-ориентированной модели. И теперь у их авторов просто нет стимула переходить на новую модель. С одной стороны это (пока) необязательно, а с другой означает необходимость множества изменений, не только в фоновом скрипте, но и в других компонентах расширения. К тому же многие при разработке используют кроссбраузерный подход, собирая готовые расширения для разных браузеров из одного и того же исходного кода. Событийно-ориентированная модель на данный момент поддерживается только в Chrome и она существенно отличается от постоянной модели, поддерживаемой остальными браузерами. Естественно, это усложняет кроссбраузерную разработку.

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

Проблема с Redux

Управление состоянием одна из вещей, имеющих особое значение в современной веб-разработке. Каждое веб-приложение (в т.ч. браузерное расширение), как только оно становится достаточно сложным, нуждается в едином и последовательном способе управления своим состоянием. И это то в чем силен Redux.

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

Прежде всего, в любом браузерном расширении может всплыть проблема с правилом "единого источника" это один из фундаментальных принципов Redux, по которому все состояние приложения должно храниться в одном месте. Расширения браузера часто состоят из нескольких отдельных компонентов (таких как фоновые и внедряемые скрипты), что затрудняет соблюдение данного принципа. К счастью эта проблема решаема и есть библиотеки, такие как Webext Redux, которые решают ее с помощью передачи сообщений. К несчастью такое решение неприменимо к событийно-ориентированным расширениям из-за уже упоминавшихся различий между событийно-ориентированной и постоянной моделями. Теперь самое время рассмотреть подробно эти различия.

В постоянной модели расширения его состояние обычно хранится в локальной переменной внутри постоянного (persistent) фонового скрипта, живущего в течение всей сессии браузера, до самого его закрытия. Так что такое состояние всегда доступно остальным компонентам расширения (например, внедряемым скриптам) через фоновый скрипт, который таким образом выполняет роль сервера. Это стандартный постоянный подход к управлению состоянием, который используется в библиотеках, таких как Webext Redux.

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

Решение

Решение заключается в том, чтобы использовать chrome.storage как непосредственное место/способ хранения/изменения состояния. Этот подход (между прочим он явно предлагается в руководстве по миграции) предполагает, что состояние хранится непосредственно в chrome.storage, чье API вызывается всякий раз когда нужно изменить состояние, либо отследить такие изменения.

Как часть стандартного API расширений chrome.storage обладает рядом преимуществ, самое важное из которых то что любой компонент расширения может иметь прямой доступ к нему. Еще одно преимущество автоматическое сохранение состояния между сессиями браузера, что является встроенной фичей, работающей "из коробки".

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

Остается только одна проблема API chrome.storage отличается от Redux, что делает невозможным его использование в качестве замены Redux. Конечно, можно использовать chrome.storage как есть, либо написать к нему кастомную обертку. Однако, Redux уже успел стать чем-то вроде стандарта в управлении состоянием. Так что было бы неплохо как-нибудь адаптировать chrome.storage к принципам Redux, или другими словами, сделать Redux из chrome.storage).

Наша цель в этой статье получить Redux-совместимый интерфейс к chrome.storage, который будет переводить функционал chrome.storage в термины Redux. В терминах API нам нужно реализовать в рамках chrome.storage интерфейс функционала Redux, имеющего непосредственное отношение к хранилищу (store) Redux. Он включает в себя функцию createStore и возвращаемый ею объект Store (хранилище Redux). Ниже их интерфейсы:

Реализация

Итак, прежде всего нам нужно написать класс, реализующий интерфейс Store. Назовем его ReduxedStorage.

Реализовать методы getState и subscribe достаточно просто, т.к. у них есть близкие аналоги в chrome.storage: метод get и событие onChanged. Конечно, они не могут напрямую заменить указанные методы Store, но могут помочь в организации хранения локальной копии состояния в нашем классе. Мы можем инициализировать локальное состояние в нашем классе, вызвав метод get из chrome.storage во время создания экземпляра ReduxedStorage и затем, всякий раз когда появляется событие onChanged, изменять соответственно локальное состояние. Таким образом гарантируется актуальность локального состояния. Тогда getState в рамках нашего класса будет тривиальным геттером. Реализация метода subscribe немного сложнее: он должен добавлять аргумент-функцию к некоторому массиву слушателей, которые будут вызываться всякий раз когда появляется событие onChanged.

В отличие от getState и subscribe, в chrome.storage нет ничего похожего на метод Store.dispatch. Там есть метод set, но его прямое использование противоречит еще одному фундаментальному принципу Redux, по которому состояние Redux присваивается только один раз, во время создания хранилища, после чего оно может быть изменено только через вызов метода dispatch. Так что нам нужно как-то воспроизвести функционал dispatch в нашем классе ReduxedStorage. Есть два способа сделать это. Радикальный предполагает полное воспроизведение соответствующего функционала Redux в рамках нашего класса, короче говоря, тупо скопировать код Redux. Но есть также и компромисный вариант, который и будет рассмотрен ниже.

Идея состоит в том, чтобы создавать новый экземпяр хранилища всякий раз, когда отправляется какое-то действие. Да, это звучит немного странно, но это единственная альтернатива полному копированию выше. Говоря более конкретно, всякий раз когда в нашем классе вызывается метод dispatch, нам нужно создать новый экземпяр хранилища, вызвав "оригинальную" функцию createStore, инициализовать его состояние локальным состоянием из нашего класса и наконец вызвать "оригинальный" метод Store.dispatch, передав ему аргументы из нашего dispatch. Помимо этого, к созданному хранилищу нужно добавить одноразовый слушатель изменения состояния, чтобы когда данное действие дойдет до хранилища, обновить chrome.storage новым состоянием, получающимся в результате данного действия. Далее это обновление должно быть отслежено и обработано слушателем события chrome.storage.onChanged, описанным выше.

Несколько замечаний насчет инициализации состояния: Поскольку метод chrome.storage:get выполняется асинхронно, мы не можем вызывать его из конструктора нашего класса. Поэтому нам придется перенести код вызова chrome.storage:get в отдельный метод, который должен вызываться сразу после конструктора (создания экземпляра класса). Этот метод, назовем его init, будет возвращать промис, который должен быть разрешен, когда метод chrome.storage:get завершит выполнение. В методе init нам также нужно создать еще одно локальное хранилище Redux, чтобы получить дефолтное состояние, которое будет использоваться, если состояние в chrome.storage в данный момент пусто.

Ниже пример как может выглядеть наш класс ReduxedStorage в первом приближении:

Замечание: Мы обращаемся к части данных в chrome.storage под определенным ключом (this.key), чтобы иметь возможность сразу получить новое (измененное) состояние в слушателе chrome.storage.onChanged, не вызывая дополнительно метод chrome.storage:get. Кроме того, это может быть полезно при хранении в состоянии непосредственно массивов, т.к. chrome.storage позволяет хранить на корневом уровне только объект.

К сожалению, в реализации выше есть скрытый недостаток, который возникает из-за того, что мы обновляем свойство this.state не напрямую, а через метод chrome.storage:set, выполняющийся асинхронно. Само по себе это не проблема. Но при создании локального хранилища Redux внутри метода dispatch используется значение свойства this.state, что может представлять проблему, т.к. this.state не всегда может содержать актуальное состояние. Так может быть, если несколько действий отправляются синхронно сразу друг за другом. В этом случае 2-й и все последующие вызовы dispatch имеют дело с устаревшими данными в свойстве this.state, которое еще не успевает обновиться из-за асинхронного выполнения метода chrome.storage:set. Таким образом, синхронное отправление нескольких действий друг за другом может приводить к нежелательным результатам.

Чтобы решить указанную проблему, можно изменить код dispatch так, чтобы использовать для таких синхронных действий одно и то же хранилище Redux. Такое буферизированное хранилище должно быть сброшено по истечении небольшого периода времени (допустим 100 мсек), чтобы для следующих действий использовалось уже новое хранилище. Для этого решения нам потребуется добавить в наш класс дополнительные свойства для буферизированного хранилища и соответствующего состояния. Ниже пример как может выглядеть такая буферизированная версия метода dispatch:

Как это часто бывает, решая одну проблему, можно получить другую. В нашем случае использование буферизированного многоразового варианта хранилища вместо локального одноразового может сломать асинхронную логику в Redux. Асинхронная логика, по умолчанию отсутствующая в Redux, может быть введена с помощью middleware, такого как Redux Thunk. С Redux Thunk можно например отложить отправку действия, используя создатель действия, который возвращает функцию вместо действия. Ниже пример такого создателя действия:

delayAddTodo откладывает отправку действия 'ADD_TODO' на 1 сек.

Если мы попытаемся использовать такой создатель действия с буферизированным вариантом dispatch выше, мы получим ошибку во время вызова this.buffStore.getState внутри колбека this.buffStore.subscribe. Причина в том что колбек this.buffStore.subscribe вызывается как минимум через 1 сек после вызова нашего метода dispatch, когда this.buffStore уже сброшен в null (через 100 мсек после вызова dispatch). При этом предыдущий вариант dispatch без проблем работает с такими асинхронными создателями действий, т.к. использует локальное хранилище, которое всегда доступно соответствующему колбеку subscribe.

Таким образом, нам нужно совместить оба варианта, т.е. использовать, как буферизированный, так и локальный вариант хранилища Redux. Первый будет использоваться для синхронных действий, а последний для асинхронных, занимающих какое-то время, таких как delayAddTodo. Однако, это не значит, что нам нужны два отдельных экземпляра хранилища Redux в одном вызове dispatch. Можно создать экземпляр хранилища один раз, сначала сохранив его в свойстве this.buffStore, а затем скопировать ссылку на него в локальной переменной, назовем ее lastStore. Тогда, когда свойство this.buffStore будет сброшено, lastStore все еще будет указывать на тот же самый экземпляр хранилища и будет доступен соответствующему колбеку subscribe. Следовательно, внутри колбека subscribe можно использовать переменную lastStore как запасную ссылку на хранилище на тот случай, если свойство this.buffStore недоступно, что означает асинхронное действие "в действии"). Когда изменение состояния будет обработано внутренним колбеком subscribe, было бы полезно отписать данный колбек/слушатель от хранилища и сбросить переменную lastStore, чтобы высвободить соответствующие ресурсы.

Кроме того, было бы неплохо провести рефакторинг в коде класса, в т.ч.:

• сделать свойства this.areaName, this.key изменяемыми/настраиваемыми через параметры конструктора.
• переместить код, непосредственно вызывающий API chrome.storage, в отдельный класс, назовем его WrappedStorage.

Итак, ниже окончательная реализация нашего интерфейса:

Его использование аналогично использованию оригинального Redux, за исключением того, что в нашем интерфейсе создатель хранилища (store creator) обернут в функцию и выполняется асинхронно, возвращая промис вместо созданного хранилища.

Стандартное использование интерфейса выглядит так:

Кроме того, с синтаксисом async/await, доступным начиная ES 2017, этот интерфейс может использоваться так:

Исходный код доступен на Github.

Также этот интерфейс доступен как пакет в NPM:

npm install reduxed-chrome-storage

TL;DR

Context и Redux это одно и тоже?

Является ли контекст инструментом управления состоянием?

Являются ли Context и useReducer() заменой Redux?

Когда следует использовать контекст?

Когда следует использовать Context и useReducer()?

Когда следует использовать Redux?

• Большое количество компонентов с состояниями, в которых используются одни и те же данные
• Состояние приложение часто обновляется
• Сложная логика обновления состояния
• Приложение имеет среднюю или большую кодовую базу и над ним работает много людей
• Вы хотите знать когда, почему и как обновляется состояние приложения и иметь возможность визуализировать эти изменения
• Вам требуются более мощные возможности по управлению побочными эффектами, стабильностью (постоянством) и сериализацией данных

Понимание Context и Redux

• Для чего он предназначен
• Какие задачи он решает
• Когда и зачем он был создан

Что такое контекст?

Использование контекста

• Вызываем const MyContext = React.createContext() для создания экземпляра объекта контекста
• В родительском компоненте рендерим &ltMyContext.Provider value={someValue}>. Это помещает некоторые данные в контекст. Эти данные могут быть чем угодно: строкой, числом, объектом, массивом, экземпляром класса, обработчиком событий и т.д.
• Получаем значение контекста в любом компоненте внутри провайдера, вызывая const theContextValue = useContext(MyContext)

import { createContext } from 'react'export const MyContext = createContext()export function ParentComponent({ children }) {  const [counter, setCounter] = useState(0)  return (    <MyContext.Provider value={[counter, setCounter]}>      {children}    </MyContext.Provider>  )}

import { useContext } from 'react'import { MyContext } from './MyContext'export function NestedChildComponent() {  const [counter, setCounter] = useContext(MyContext)  // ...}

Цель и случаи использования контекста

Что такое Redux?

• Управление состоянием
• Цель Redux определение того, почему и как произошло изменение состояния

Redux и React

Цель и случаи использования (React-)Redux

• Полное разделение логики управления состоянием и слоя UI
• Распределение логики управления состоянием между разными слоями UI (например, в процессе перевода приложения с AngularJS на React)
• Использование возможностей Redux middleware для добавления дополнительной логики при инициализации операций
• Возможность сохранения частей состояния Redux
• Возможность получения отчетов об ошибках, которые могут быть воспроизведены другими разработчиками
• Возможность быстрой отладки логики и UI во время разработки

Почему контекст не является инструментом управления состоянием?

• Сохранение начального значения
• Получение текущего значения
• Обновление значения

• Сохранять начальное значение путем вызова хука
• Получать текущее значение также посредством вызова хука
• Обновлять значение, вызывая функцию setState() или dispatch(), соответственно
• Узнавать об обновлении состояния благодаря повторному рендерингу компонента

• Redux сохраняет начальное значение путем вызова корневого редуктора (root reducer), позволяет читать текущее значение с помощью store.getState(), обновлять значение с помощью store.dispatch(action) и получать уведомления об обновлении состояния через store.subscribe(listener)
• MobX сохраняет начальное значение путем присвоения значения полю класса хранилища, позволяет читать текущее значение и обновлять его через поля хранилища и получать учведомления об обновлении состояния с помощью методов autorun() и computed()

React Context не соответствует названным критериям. Поэтому он не является инструментом управления состоянием

Сравнение Context и Redux

• Context
• • Ничего не хранит и ничем не управляет
  • Работает только в компонентах React
  • Передает ниже простое (единственное) значение, которое может быть чем угодно (примитивом, объектом, классом и т.д.)
  • Позволяет читать это простое значение
  • Может использоваться для предотвращения бурения
  • Показывает текущее значение для компонентов Provider и Consumer в инструментах разработчика, но не показывает историю изменений этого значения
  • Обновляет потребляющие компоненты при изменении значения, но не позволяет пропустить обновление
  • Не предоставляет механизма для обработки побочных эффектов отвечает только за рендеринг
  
  
• React+Redux
• • Хранит и управляет простым значением (обычно, этим значением является объект)
  • Работает с любым UI, а также за пределами React-компонентов
  • Позволяет читать это простое значение
  • Может использоваться для предотвращения бурения
  • Может обновлять значение путем инициализации операций и запуска редукторов
  • Инструменты разработчика показывают историю инициализации операций и изменения состояния
  • Предоставляет возможность использования middleware для обработки побочных эффектов
  • Позволяет компонентам подписываться на обновления хранилища, извлекать определенные части состояния хранилища и контролировать повторный рендеринг компонентов
  
  

Context и useReducer()

• Сохраненное значение
• Функцию-редуктор
• Возможность инициализации операций
• Возможность передачи значения и его чтения во вложенных компонентах

• Context + useReducer() основан на передаче текущего значения через контекст. React-Redux передает через контекст текущий экземпляр хранилища Redux
• Это означает, что когда useReducer() производит новое значение, все компоненты, подписанные на контекст, принудительно перерисовываются, даже если они используют только часть данных. Это может привести к проблемам с производительностью в зависимости от размера значения состояния, количества подписанных компонентов и частоты повторного рендеринга. При использовании React-Redux компоненты могут подписываться на определенную часть значения хранилища и перерисовываться только при изменении этой части

• Контекст + useReducer() являются встроенными возможностями React и не могут использоваться за его пределами. Хранилище Redux не зависит от UI, поэтому может использоваться отдельно от React
• React DevTools показывают текущее значение контекста, но не историю его изменений. Redux DevTools показывают все инициализированные операции, их содержимое (тип и полезную нагрузку, type and payload), состояние после каждой операции и разницу между состояниями
• useReducer() не имеет middleware. Некоторые побочные эффекты можно обработать с помощью хука useEffect() в сочетании с useReducer(), я даже встречал отдельные попытки оборачивания useReducer() в нечто похожее на middleware, однако всему этому далеко до функционала и возможностей Redux middleware

Выбор правильного инструмента

Обзор случаев использования

• Context
  
  • Передача данных вложенным компонентам без бурения
  
  
• useReducer()
  
  • Управление состоянием сложного компонента с помощью функции-редуктора
  
  
• Context + useReducer()
  
  • Управление состоянием сложного компонента с помощью функции-редуктора и передача состояния вложенным компонентам без бурения
  
  
• Redux
  
  • Управление очень сложным состоянием с помощью функций-редукторов
  • Прослеживаемость того, когда, почему и как менялось состояние в течение времени
  • Желание полной изоляции логики управления состоянием от слоя UI
  • Распределение логики управления состоянием между разными слоями UI
  • Использование возможностей middleware для реализации дополнительной логики при инициализации операций
  • Возможность сохранения определенных частей состояния
  • Возможность получения воспроизводимых отчетов об ошибках
  • Возможность быстрой отладки логики и UI в процессе разработки
  
  
• Redux + React-Redux
  
  • Все случаи использования Redux + возможность взаимодействия React-компонентов с хранилищем Redux
  
  

Рекомендации

• Если вам требуется просто избежать бурения, используйте контекст
• Если у вас имеется сложное состояние, но вы не хотите использовать сторонние библиотеки, используйте контекст + useReducer()
• Если вам требуется хорошая трассировка изменений состояния во времени, управлемый повторный рендеринг определенных компонентов, более мощные возможности обработки побочных эффектов и т.п., используйте Redux + React-Redux

yarn create react-app state-management# илиnpm init react-app state-management# илиnpx create-react-app state-management

yarn add bootstrap react-bootstrap nanoid# илиnpm i bootstrap react-bootstrap nanoid

• bootstrap, react-bootstrap стили
• nanoid утилита для генерации уникального ID

useState()

const [state, setState] = useState(initialValue)

• state текущее значение состояния
• setState сеттер
• initialValue начальное или дефолтное значение

|--use-state  |--components    |--index.js    |--TodoForm.js    |--TodoList.js    |--TodoListItem.js  |--App.js

// хукimport { useState } from 'react'// компонентыimport { TodoForm, TodoList } from './components'// стилиimport { Container } from 'react-bootstrap'// начальное состояние// изучите его как следует, чтобы понимать логику обновленияconst initialState = {  todos: {    ids: ['1', '2', '3', '4'],    entities: {      1: {        id: '1',        text: 'Eat',        completed: true      },      2: {        id: '2',        text: 'Code',        completed: true      },      3: {        id: '3',        text: 'Sleep',        completed: false      },      4: {        id: '4',        text: 'Repeat',        completed: false      }    }  }}export default function App() {  const [state, setState] = useState(initialState)  const { length } = state.todos.ids  return (    <Container style={{ maxWidth: '480px' }} className='text-center'>      <h1 className='mt-2'>useState</h1>      <TodoForm setState={setState} />      {length ? <TodoList state={state} setState={setState} /> : null}    </Container>  )}

// хукimport { useState } from 'react'// утилита для генерации IDimport { nanoid } from 'nanoid'// стилиimport { Container, Form, Button } from 'react-bootstrap'// функция принимает сеттерexport const TodoForm = ({ setState }) => {  const [text, setText] = useState('')  const updateText = ({ target: { value } }) => {    setText(value)  }  const addTodo = (e) => {    e.preventDefault()    const trimmed = text.trim()    if (trimmed) {      const id = nanoid(5)      const newTodo = { id, text, completed: false }      // обратите внимание, как нам приходится обновлять состояние      setState((state) => ({        ...state,        todos: {          ...state.todos,          ids: state.todos.ids.concat(id),          entities: {            ...state.todos.entities,            [id]: newTodo          }        }      }))      setText('')    }  }  return (    <Container className='mt-4'>      <h4>Form</h4>      <Form className='d-flex' onSubmit={addTodo}>        <Form.Control          type='text'          placeholder='Enter text...'          value={text}          onChange={updateText}        />        <Button variant='primary' type='submit'>          Add        </Button>      </Form>    </Container>  )}

// компонентimport { TodoListItem } from './TodoListItem'// стилиimport { Container, ListGroup } from 'react-bootstrap'// функция принимает состояние и сеттер только для того,// чтобы передать их потомкам// обратите внимание, как мы передаем отдельную задачуexport const TodoList = ({ state, setState }) => (  <Container className='mt-2'>    <h4>List</h4>    <ListGroup>      {state.todos.ids.map((id) => (        <TodoListItem          key={id}          todo={state.todos.entities[id]}          setState={setState}        />      ))}    </ListGroup>  </Container>)

// стилиimport { ListGroup, Form, Button } from 'react-bootstrap'// функция принимает задачу и сеттерexport const TodoListItem = ({ todo, setState }) => {  const { id, text, completed } = todo  // переключение задачи  const toggleTodo = () => {    setState((state) => {      // небольшая оптимизация      const { todos } = state      return {        ...state,        todos: {          ...todos,          entities: {            ...todos.entities,            [id]: {              ...todos.entities[id],              completed: !todos.entities[id].completed            }          }        }      }    })  }  // обновление задачи  const updateTodo = ({ target: { value } }) => {    const trimmed = value.trim()    if (trimmed) {      setState((state) => {        const { todos } = state        return {          ...state,          todos: {            ...todos,            entities: {              ...todos.entities,              [id]: {                ...todos.entities[id],                text: trimmed              }            }          }        }      })    }  }  // удаление задачи  const deleteTodo = () => {    setState((state) => {      const { todos } = state      const newIds = todos.ids.filter((_id) => _id !== id)      const newTodos = newIds.reduce((obj, id) => {        if (todos.entities[id]) return { ...obj, [id]: todos.entities[id] }        else return obj      }, {})      return {        ...state,        todos: {          ...todos,          ids: newIds,          entities: newTodos        }      }    })  }  // небольшой финт для упрощения обновления задачи  const inputStyles = {    outline: 'none',    border: 'none',    background: 'none',    textAlign: 'center',    textDecoration: completed ? 'line-through' : '',    opacity: completed ? '0.8' : '1'  }  return (    <ListGroup.Item className='d-flex align-items-baseline'>      <Form.Check        type='checkbox'        checked={completed}        onChange={toggleTodo}      />      <Form.Control        style={inputStyles}        defaultValue={text}        onChange={updateTodo}        disabled={completed}      />      <Button variant='danger' onClick={deleteTodo}>        Delete      </Button>    </ListGroup.Item>  )}

export { TodoForm } from './TodoForm'export { TodoList } from './TodoList'

import React from 'react'import { render } from 'react-dom'// стилиimport 'bootstrap/dist/css/bootstrap.min.css'// компонентimport App from './use-state/App'const root$ = document.getElementById('root')render(<App />, root$)

• Необходимость передачи состояния и/или сеттера на каждом уровне вложенности, обусловленная локальным характером состояния
• Логика обновления состояния приложения разбросана по компонентам и смешана с логикой самих компонентов
• Сложность обновления состояния, вытекающая из его иммутабельности
• Однонаправленный поток данных, невозможность свободного обмена данными между компонентами, находящимися на одном уровне вложенности, но в разных поддеревьях виртуального DOM
  

useContext() + useReducer()

const TodoContext = createContext()

<TodoContext.Provider value={state}>  <App /></TodoContext.Provider>

const state = useContext(TodoContext)

const [state, dispatch] = useReducer(todoReducer, initialState)

|--use-reducer  |--modules    |--components      |--index.js      |--TodoForm.js      |--TodoList.js      |--TodoListItem.js    |--todoReducer      |--actions.js      |--actionTypes.js      |--todoReducer.js    |--todoContext.js  |--App.js

const ADD_TODO = 'ADD_TODO'const TOGGLE_TODO = 'TOGGLE_TODO'const UPDATE_TODO = 'UPDATE_TODO'const DELETE_TODO = 'DELETE_TODO'export { ADD_TODO, TOGGLE_TODO, UPDATE_TODO, DELETE_TODO }

import { ADD_TODO, TOGGLE_TODO, UPDATE_TODO, DELETE_TODO } from './actionTypes'const createAction = (type, payload) => ({ type, payload })const addTodo = (newTodo) => createAction(ADD_TODO, newTodo)const toggleTodo = (todoId) => createAction(TOGGLE_TODO, todoId)const updateTodo = (payload) => createAction(UPDATE_TODO, payload)const deleteTodo = (todoId) => createAction(DELETE_TODO, todoId)export { addTodo, toggleTodo, updateTodo, deleteTodo }

// утилита для генерации IDimport { nanoid } from 'nanoid'// типы операцийimport * as actions from './actionTypes'export const todoReducer = (state, action) => {  const { todos } = state  switch (action.type) {    case actions.ADD_TODO: {      const { payload: newTodo } = action      const id = nanoid(5)      return {        ...state,        todos: {          ...todos,          ids: todos.ids.concat(id),          entities: {            ...todos.entities,            [id]: { id, ...newTodo }          }        }      }    }    case actions.TOGGLE_TODO: {      const { payload: id } = action      return {        ...state,        todos: {          ...todos,          entities: {            ...todos.entities,            [id]: {              ...todos.entities[id],              completed: !todos.entities[id].completed            }          }        }      }    }    case actions.UPDATE_TODO: {      const { payload: id, text } = action      return {        ...state,        todos: {          ...todos,          entities: {            ...todos.entities,            [id]: {              ...todos.entities[id],              text            }          }        }      }    }    case actions.DELETE_TODO: {      const { payload: id } = action      const newIds = todos.ids.filter((_id) => _id !== id)      const newTodos = newIds.reduce((obj, id) => {        if (todos.entities[id]) return { ...obj, [id]: todos.entities[id] }        else return obj      }, {})      return {        ...state,        todos: {          ...todos,          ids: newIds,          entities: newTodos        }      }    }    // по умолчанию (при отсутствии совпадения со всеми case) редуктор возвращает состояние в неизменном виде    default:      return state  }}

// reactimport { createContext, useReducer, useContext } from 'react'// редукторimport { todoReducer } from './todoReducer/todoReducer'// создаем контекстconst TodoContext = createContext()// начальное состояниеconst initialState = {  todos: {    ids: ['1', '2', '3', '4'],    entities: {      1: {        id: '1',        text: 'Eat',        completed: true      },      2: {        id: '2',        text: 'Code',        completed: true      },      3: {        id: '3',        text: 'Sleep',        completed: false      },      4: {        id: '4',        text: 'Repeat',        completed: false      }    }  }}// провайдерexport const TodoProvider = ({ children }) => {  const [state, dispatch] = useReducer(todoReducer, initialState)  return (    <TodoContext.Provider value={{ state, dispatch }}>      {children}    </TodoContext.Provider>  )}// утилита для извлечения значений из контекстаexport const useTodoContext = () => useContext(TodoContext)

// React, ReactDOM и стилиimport { TodoProvider } from './use-reducer/modules/TodoContext'import App from './use-reducer/App'const root$ = document.getElementById('root')render(  <TodoProvider>    <App />  </TodoProvider>,  root$)

import { useTodoContext } from '../TodoContext'// в компонентеconst { state, dispatch } = useTodoContext()

import * as actions from '../todoReducer/actions'// в компонентеdispatch(actions.addTodo(newTodo))

// componentsimport { TodoForm, TodoList } from './modules/components'// stylesimport { Container } from 'react-bootstrap'// contextimport { useTodoContext } from './modules/TodoContext'export default function App() {  const { state } = useTodoContext()  const { length } = state.todos.ids  return (    <Container style={{ maxWidth: '480px' }} className='text-center'>      <h1 className='mt-2'>useReducer</h1>      <TodoForm />      {length ? <TodoList /> : null}    </Container>  )}

// reactimport { useState } from 'react'// stylesimport { Container, Form, Button } from 'react-bootstrap'// contextimport { useTodoContext } from '../TodoContext'// actionsimport * as actions from '../todoReducer/actions'export const TodoForm = () => {  const { dispatch } = useTodoContext()  const [text, setText] = useState('')  const updateText = ({ target: { value } }) => {    setText(value)  }  const handleAddTodo = (e) => {    e.preventDefault()    const trimmed = text.trim()    if (trimmed) {      const newTodo = { text, completed: false }      dispatch(actions.addTodo(newTodo))      setText('')    }  }  return (    <Container className='mt-4'>      <h4>Form</h4>      <Form className='d-flex' onSubmit={handleAddTodo}>        <Form.Control          type='text'          placeholder='Enter text...'          value={text}          onChange={updateText}        />        <Button variant='primary' type='submit'>          Add        </Button>      </Form>    </Container>  )}

// componentsimport { TodoListItem } from './TodoListItem'// stylesimport { Container, ListGroup } from 'react-bootstrap'// contextimport { useTodoContext } from '../TodoContext'export const TodoList = () => {  const {    state: { todos }  } = useTodoContext()  return (    <Container className='mt-2'>      <h4>List</h4>      <ListGroup>        {todos.ids.map((id) => (          <TodoListItem key={id} todo={todos.entities[id]} />        ))}      </ListGroup>    </Container>  )}

// stylesimport { ListGroup, Form, Button } from 'react-bootstrap'// contextimport { useTodoContext } from '../TodoContext'// actionsimport * as actions from '../todoReducer/actions'export const TodoListItem = ({ todo }) => {  const { dispatch } = useTodoContext()  const { id, text, completed } = todo  const handleUpdateTodo = ({ target: { value } }) => {    const trimmed = value.trim()    if (trimmed) {      dispatch(actions.updateTodo({ id, trimmed }))    }  }  const inputStyles = {    outline: 'none',    border: 'none',    background: 'none',    textAlign: 'center',    textDecoration: completed ? 'line-through' : '',    opacity: completed ? '0.8' : '1'  }  return (    <ListGroup.Item className='d-flex align-items-baseline'>      <Form.Check        type='checkbox'        checked={completed}        onChange={() => dispatch(actions.toggleTodo(id))}      />      <Form.Control        style={inputStyles}        defaultValue={text}        onChange={handleUpdateTodo}        disabled={completed}      />      <Button variant='danger' onClick={() => dispatch(actions.deleteTodo(id))}>        Delete      </Button>    </ListGroup.Item>  )}

// утилита, предоставляемая immerimport produce from 'immer'import { nanoid } from 'nanoid'// типы операцийimport * as actions from './actionTypes'// сравните с "классической" реализацией редуктора// для обновления состояния используется draft - черновик исходного состоянияexport const todoProducer = produce((draft, action) => {  const {    todos: { ids, entities }  } = draft  switch (action.type) {    case actions.ADD_TODO: {      const { payload: newTodo } = action      const id = nanoid(5)      ids.push(id)      entities[id] = { id, ...newTodo }      break    }    case actions.TOGGLE_TODO: {      const { payload: id } = action      entities[id].completed = !entities[id].completed      break    }    case actions.UPDATE_TODO: {      const { payload: id, text } = action      entities[id].text = text      break    }    case actions.DELETE_TODO: {      const { payload: id } = action      ids.splice(ids.indexOf(id), 1)      delete entities[id]      break    }    default:      return draft  }})

// import { todoReducer } from './todoReducer/todoReducer'import { todoProducer } from './todoReducer/todoProducer'// в провайдере// const [state, dispatch] = useReducer(todoReducer, initialState)const [state, dispatch] = useReducer(todoProducer, initialState)

Redux Toolkit

• Состояние всего приложения находится в одном хранилище (store)
• Дочерние компоненты оборачиваются в Provider из react-redux, которому в виде пропа store передается хранилище
• Редукторы (reducers) каждой части состояния объединяются с помощью combineReducers() в один корневой редуктор (root reducer), который передается при создании хранилища в createStore()
• Компоненты подключаются к хранилищу с помощью connect() (+ mapStateToProps(), mapDispatchToProps()) и т.д.

• configureStore() для создания и настройки хранилища
• createSlice() для создания частей состояния
• createEntityAdapter() для создания адаптера сущностей

• createSelector() для создания селекторов
• createAsyncThunk() для создания преобразователей (thunk)

yarn add @reduxjs/toolkit# илиnpm i @reduxjs/toolkit

|--redux-toolkit  |--modules    |--components      |--index.js      |--TodoForm.js      |--TodoList.js      |--TodoListItem.js  |--slices    |--todosSlice.js  |--App.js  |--store.js

// утилита для создания хранилищаimport { configureStore } from '@reduxjs/toolkit'// редукторimport todosReducer from './modules/slices/todosSlice'// начальное состояниеconst preloadedState = {  todos: {    ids: ['1', '2', '3', '4'],    entities: {      1: {        id: '1',        text: 'Eat',        completed: true      },      2: {        id: '2',        text: 'Code',        completed: true      },      3: {        id: '3',        text: 'Sleep',        completed: false      },      4: {        id: '4',        text: 'Repeat',        completed: false      }    }  }}// хранилищеconst store = configureStore({  reducer: {    todos: todosReducer  },  preloadedState})export default store

// React, ReactDOM & стили// провайдерimport { Provider } from 'react-redux'// основной компонентimport App from './redux-toolkit/App'// хранилищеimport store from './redux-toolkit/store'const root$ = document.getElementById('root')render(  <Provider store={store}>    <App />  </Provider>,  root$)

// утилиты для создания части состояния и адаптера сущностейimport {  createSlice,  createEntityAdapter} from '@reduxjs/toolkit'// создаем адаптерconst todosAdapter = createEntityAdapter()// инициализируем начальное состояние// получаем { ids: [], entities: {} }const initialState = todosAdapter.getInitialState()// создаем часть состоянияconst todosSlice = createSlice({  // уникальный ключ, используемый в качестве префикса при генерации создателей операции  name: 'todos',  // начальное состояние  initialState,  // редукторы  reducers: {    // данный создатель операции отправляет в редуктор операцию { type: 'todos/addTodo', payload: newTodo }    addTodo: todosAdapter.addOne,    // Redux Toolkit использует immer для обновления состояния    toggleTodo(state, action) {      const { payload: id } = action      const todo = state.entities[id]      todo.completed = !todo.completed    },    updateTodo(state, action) {      const { id, text } = action.payload      const todo = state.entities[id]      todo.text = text    },    deleteTodo: todosAdapter.removeOne  }})// экспортируем селектор для получения всех entities в виде массиваexport const { selectAll: selectAllTodos } = todosAdapter.getSelectors(  (state) => state.todos)// экспортируем создателей операцииexport const {  addTodo,  toggleTodo,  updateTodo,  deleteTodo} = todosSlice.actions// эскпортируем редукторexport default todosSlice.reducer

import { useDispatch } from 'react-redux'import { addTodo } from '../slices/todosSlice'// в компонентеconst dispatch = useDispatch()dispatch(addTodo(newTodo))

yarn add json-server concurrently# илиnpm i json-server concurrently

"server": "concurrently \"json-server -w db.json -p 5000 -d 1000\" \"yarn start\""

• -w означает наблюдение за изменениями файла db.json
• -p означает порт, по умолчанию запросы из приложения отправляются на порт 3000
• -d задержка ответа от сервера

{  "todos": [    {      "id": "1",      "text": "Eat",      "completed": true,      "visible": true    },    {      "id": "2",      "text": "Code",      "completed": true,      "visible": true    },    {      "id": "3",      "text": "Sleep",      "completed": false,      "visible": true    },    {      "id": "4",      "text": "Repeat",      "completed": false,      "visible": true    }  ]}

"proxy": "http://localhost:5000"

import { createSlice } from '@reduxjs/toolkit'// фильтрыexport const Filters = {  All: 'all',  Active: 'active',  Completed: 'completed'}// начальное состояние - отображать все задачиconst initialState = {  status: Filters.All}// состояние фильтраconst filterSlice = createSlice({  name: 'filter',  initialState,  reducers: {    setFilter(state, action) {      state.status = action.payload    }  }})export const { setFilter } = filterSlice.actionsexport default filterSlice.reducer

// нам больше не требуется preloadedStateimport { configureStore } from '@reduxjs/toolkit'import todosReducer from './modules/slices/todosSlice'import filterReducer from './modules/slices/filterSlice'const store = configureStore({  reducer: {    todos: todosReducer,    filter: filterReducer  }})export default store

import {  createSlice,  createEntityAdapter,  // утилита для создания селекторов  createSelector,  // утилита для создания преобразователей  createAsyncThunk} from '@reduxjs/toolkit'// утилита для выполнения HTTP-запросовimport axios from 'axios'// фильтрыimport { Filters } from './filterSlice'const todosAdapter = createEntityAdapter()const initialState = todosAdapter.getInitialState({  // добавляем в начальное состояние статус загрузки  status: 'idle'})// адрес сервераconst SERVER_URL = 'http://localhost:5000/todos'// преобразовательexport const fetchTodos = createAsyncThunk('todos/fetchTodos', async () => {  try {    const response = await axios(SERVER_URL)    return response.data  } catch (err) {    console.error(err.toJSON())  }})const todosSlice = createSlice({  name: 'todos',  initialState,  reducers: {    addTodo: todosAdapter.addOne,    toggleTodo(state, action) {      const { payload: id } = action      const todo = state.entities[id]      todo.completed = !todo.completed    },    updateTodo(state, action) {      const { id, text } = action.payload      const todo = state.entities[id]      todo.text = text    },    deleteTodo: todosAdapter.removeOne,    // создатель операции для выполнения всех задач    completeAllTodos(state) {      Object.values(state.entities).forEach((todo) => {        todo.completed = true      })    },    // создатель операции для очистки выполненных задач    clearCompletedTodos(state) {      const completedIds = Object.values(state.entities)        .filter((todo) => todo.completed)        .map((todo) => todo.id)      todosAdapter.removeMany(state, completedIds)    }  },  // дополнительные редукторы  extraReducers: (builder) => {    builder      // после начала выполнения запроса на получения задач      // меняем значение статуса на loading      // это позволит отображать индикатор загрузки в App.js      .addCase(fetchTodos.pending, (state) => {        state.status = 'loading'      })      // после получения задач от сервера      // записываем их в состояние      // и меняем статус загрузки      .addCase(fetchTodos.fulfilled, (state, action) => {        todosAdapter.setAll(state, action.payload)        state.status = 'idle'      })  }})export const { selectAll: selectAllTodos } = todosAdapter.getSelectors(  (state) => state.todos)// создаем и экспортируем кастомный селектор для получения отфильтрованных задачexport const selectFilteredTodos = createSelector(  selectAllTodos,  (state) => state.filter,  (todos, filter) => {    const { status } = filter    if (status === Filters.All) return todos    return status === Filters.Active      ? todos.filter((todo) => !todo.completed)      : todos.filter((todo) => todo.completed)  })export const {  addTodo,  toggleTodo,  updateTodo,  deleteTodo,  completeAllTodos,  clearCompletedTodos} = todosSlice.actionsexport default todosSlice.reducer

// после импорта компонента "App"import { fetchTodos } from './redux-toolkit/modules/slices/todosSlice'store.dispatch(fetchTodos())

// хук для доступа к селекторамimport { useSelector } from 'react-redux'// индикатор загрузки - спиннерimport Loader from 'react-loader-spinner'// компонентыimport {  TodoForm,  TodoList,  TodoFilters,  TodoControls,  TodoStats} from './modules/components'// стилиimport { Container } from 'react-bootstrap'// селектор для получения всех entitites в виде массиваimport { selectAllTodos } from './modules/slices/todosSlice'export default function App() {  // получаем длину массива сущностей  const { length } = useSelector(selectAllTodos)  // получаем значение статуса  const loadingStatus = useSelector((state) => state.todos.status)  // стили для индикатора загрузки  const loaderStyles = {    position: 'absolute',    top: '50%',    left: '50%',    transform: 'translate(-50%, -50%)'  }  if (loadingStatus === 'loading')    return (      <Loader        type='Oval'        color='#00bfff'        height={80}        width={80}        style={loaderStyles}      />    )  return (    <Container style={{ maxWidth: '480px' }} className='text-center'>      <h1 className='mt-2'>Redux Toolkit</h1>      <TodoForm />      {length ? (        <>          <TodoStats />          <TodoFilters />          <TodoList />          <TodoControls />        </>      ) : null}    </Container>  )}

// reduximport { useDispatch } from 'react-redux'// stylesimport { Container, ButtonGroup, Button } from 'react-bootstrap'// action creatorsimport { completeAllTodos, clearCompletedTodos } from '../slices/todosSlice'export const TodoControls = () => {  const dispatch = useDispatch()  return (    <Container className='mt-2'>      <h4>Controls</h4>      <ButtonGroup>        <Button          variant='outline-secondary'          onClick={() => dispatch(completeAllTodos())}        >          Complete all        </Button>        <Button          variant='outline-secondary'          onClick={() => dispatch(clearCompletedTodos())}        >          Clear completed        </Button>      </ButtonGroup>    </Container>  )}

// reduximport { useDispatch, useSelector } from 'react-redux'// stylesimport { Container, Form } from 'react-bootstrap'// filters & action creatorimport { Filters, setFilter } from '../slices/filterSlice'export const TodoFilters = () => {  const dispatch = useDispatch()  const { status } = useSelector((state) => state.filter)  const changeFilter = (filter) => {    dispatch(setFilter(filter))  }  return (    <Container className='mt-2'>      <h4>Filters</h4>      {Object.keys(Filters).map((key) => {        const value = Filters[key]        const checked = value === status        return (          <Form.Check            key={value}            inline            label={value.toUpperCase()}            type='radio'            name='filter'            onChange={() => changeFilter(value)}            checked={checked}          />        )      })}    </Container>  )}

// reactimport { useState } from 'react'// reduximport { useDispatch } from 'react-redux'// libsimport { nanoid } from 'nanoid'// stylesimport { Container, Form, Button } from 'react-bootstrap'// action creatorimport { addTodo } from '../slices/todosSlice'export const TodoForm = () => {  const dispatch = useDispatch()  const [text, setText] = useState('')  const updateText = ({ target: { value } }) => {    setText(value)  }  const handleAddTodo = (e) => {    e.preventDefault()    const trimmed = text.trim()    if (trimmed) {      const newTodo = { id: nanoid(5), text, completed: false }      dispatch(addTodo(newTodo))      setText('')    }  }  return (    <Container className='mt-4'>      <h4>Form</h4>      <Form className='d-flex' onSubmit={handleAddTodo}>        <Form.Control          type='text'          placeholder='Enter text...'          value={text}          onChange={updateText}        />        <Button variant='primary' type='submit'>          Add        </Button>      </Form>    </Container>  )}

// reduximport { useSelector } from 'react-redux'// componentimport { TodoListItem } from './TodoListItem'// stylesimport { Container, ListGroup } from 'react-bootstrap'// selectorimport { selectFilteredTodos } from '../slices/todosSlice'export const TodoList = () => {  const filteredTodos = useSelector(selectFilteredTodos)  return (    <Container className='mt-2'>      <h4>List</h4>      <ListGroup>        {filteredTodos.map((todo) => (          <TodoListItem key={todo.id} todo={todo} />        ))}      </ListGroup>    </Container>  )}

// reduximport { useDispatch } from 'react-redux'// stylesimport { ListGroup, Form, Button } from 'react-bootstrap'// action creatorsimport { toggleTodo, updateTodo, deleteTodo } from '../slices/todosSlice'export const TodoListItem = ({ todo }) => {  const dispatch = useDispatch()  const { id, text, completed } = todo  const handleUpdateTodo = ({ target: { value } }) => {    const trimmed = value.trim()    if (trimmed) {      dispatch(updateTodo({ id, trimmed }))    }  }  const inputStyles = {    outline: 'none',    border: 'none',    background: 'none',    textAlign: 'center',    textDecoration: completed ? 'line-through' : '',    opacity: completed ? '0.8' : '1'  }  return (    <ListGroup.Item className='d-flex align-items-baseline'>      <Form.Check        type='checkbox'        checked={completed}        onChange={() => dispatch(toggleTodo(id))}      />      <Form.Control        style={inputStyles}        defaultValue={text}        onChange={handleUpdateTodo}        disabled={completed}      />      <Button variant='danger' onClick={() => dispatch(deleteTodo(id))}>        Delete      </Button>    </ListGroup.Item>  )}

// reactimport { useState, useEffect } from 'react'// reduximport { useSelector } from 'react-redux'// stylesimport { Container, ListGroup } from 'react-bootstrap'// selectorimport { selectAllTodos } from '../slices/todosSlice'export const TodoStats = () => {  const allTodos = useSelector(selectAllTodos)  const [stats, setStats] = useState({    total: 0,    active: 0,    completed: 0,    percent: 0  })  useEffect(() => {    if (allTodos.length) {      const total = allTodos.length      const completed = allTodos.filter((todo) => todo.completed).length      const active = total - completed      const percent = total === 0 ? 0 : Math.round((active / total) * 100) + '%'      setStats({        total,        active,        completed,        percent      })    }  }, [allTodos])  return (    <Container className='mt-2'>      <h4>Stats</h4>      <ListGroup horizontal>        {Object.entries(stats).map(([[first, ...rest], count], index) => (          <ListGroup.Item key={index}>            {first.toUpperCase() + rest.join('')}: {count}          </ListGroup.Item>        ))}      </ListGroup>    </Container>  )}

Recoil

yarn add recoil# илиnpm i recoil

|--recoil  |--modules    |--atoms      |--filterAtom.js      |--todosAtom.js    |--components      |--index.js      |--TodoControls.js      |--TodoFilters.js      |--TodoForm.js      |--TodoList.js      |--TodoListItem.js      |--TodoStats.js  |--App.js

// todosAtom.js// утилиты для создания атомов и селекторовimport { atom, selector } from 'recoil'// утилита для выполнения HTTP-запросовimport axios from 'axios'// адрес сервераconst SERVER_URL = 'http://localhost:5000/todos'// атом с состоянием для списка задачexport const todosState = atom({  key: 'todosState',  default: selector({    key: 'todosState/default',    get: async () => {      try {        const response = await axios(SERVER_URL)        return response.data      } catch (err) {        console.log(err.toJSON())      }    }  })})

import React, { Component, Suspense } from 'react'import { render } from 'react-dom'// recoilimport { RecoilRoot } from 'recoil'// индикатор загрузкиimport Loader from 'react-loader-spinner'import App from './recoil/App'// предохранитель с официального сайта Reactclass ErrorBoundary extends Component {  constructor(props) {    super(props)    this.state = { error: null, errorInfo: null }  }  componentDidCatch(error, errorInfo) {    this.setState({      error: error,      errorInfo: errorInfo    })  }  render() {    if (this.state.errorInfo) {      return (        <div>          <h2>Something went wrong.</h2>          <details style={{ whiteSpace: 'pre-wrap' }}>            {this.state.error && this.state.error.toString()}            <br />            {this.state.errorInfo.componentStack}          </details>        </div>      )    }    return this.props.children  }}const loaderStyles = {  position: 'absolute',  top: '50%',  left: '50%',  transform: 'translate(-50%, -50%)'}const root$ = document.getElementById('root')// мы оборачиваем основной компонент приложения сначала в Suspense, затем в ErrorBoundaryrender(  <RecoilRoot>    <Suspense      fallback={        <Loader          type='Oval'          color='#00bfff'          height={80}          width={80}          style={loaderStyles}        />      }    >      <ErrorBoundary>        <App />      </ErrorBoundary>    </Suspense>  </RecoilRoot>,  root$)

// filterAtom.js// recoilimport { atom, selector } from 'recoil'// атомimport { todosState } from './todosAtom'export const Filters = {  All: 'all',  Active: 'active',  Completed: 'completed'}export const todoListFilterState = atom({  key: 'todoListFilterState',  default: Filters.All})// данный селектор использует два атома: атом фильтра и атом списка задачexport const filteredTodosState = selector({  key: 'filteredTodosState',  get: ({ get }) => {    const filter = get(todoListFilterState)    const todos = get(todosState)    if (filter === Filters.All) return todos    return filter === Filters.Completed      ? todos.filter((todo) => todo.completed)      : todos.filter((todo) => !todo.completed)  }})

// хукimport { useRecoilState } from 'recoil'// стилиimport { ListGroup, Form, Button } from 'react-bootstrap'// атомimport { todosState } from '../atoms/todosAtom'export const TodoListItem = ({ todo }) => {  // данный хук - это как useState() для состояния Recoil  const [todos, setTodos] = useRecoilState(todosState)  const { id, text, completed } = todo  const toggleTodo = () => {    const newTodos = todos.map((todo) =>      todo.id === id ? { ...todo, completed: !todo.completed } : todo    )    setTodos(newTodos)  }  const updateTodo = ({ target: { value } }) => {    const trimmed = value.trim()    if (!trimmed) return    const newTodos = todos.map((todo) =>      todo.id === id ? { ...todo, text: value } : todo    )    setTodos(newTodos)  }  const deleteTodo = () => {    const newTodos = todos.filter((todo) => todo.id !== id)    setTodos(newTodos)  }  const inputStyles = {    outline: 'none',    border: 'none',    background: 'none',    textAlign: 'center',    textDecoration: completed ? 'line-through' : '',    opacity: completed ? '0.8' : '1'  }  return (    <ListGroup.Item className='d-flex align-items-baseline'>      <Form.Check type='checkbox' checked={completed} onChange={toggleTodo} />      <Form.Control        style={inputStyles}        defaultValue={text}        onChange={updateTodo}        disabled={completed}      />      <Button variant='danger' onClick={deleteTodo}>        Delete      </Button>    </ListGroup.Item>  )}

// recoilimport { useRecoilState } from 'recoil'// stylesimport { Container, ButtonGroup, Button } from 'react-bootstrap'// atomimport { todosState } from '../atoms/todosAtom'export const TodoControls = () => {  const [todos, setTodos] = useRecoilState(todosState)  const completeAllTodos = () => {    const newTodos = todos.map((todo) => (todo.completed = true))    setTodos(newTodos)  }  const clearCompletedTodos = () => {    const newTodos = todos.filter((todo) => !todo.completed)    setTodos(newTodos)  }  return (    <Container className='mt-2'>      <h4>Controls</h4>      <ButtonGroup>        <Button variant='outline-secondary' onClick={completeAllTodos}>          Complete all        </Button>        <Button variant='outline-secondary' onClick={clearCompletedTodos}>          Clear completed        </Button>      </ButtonGroup>    </Container>  )}

// recoilimport { useRecoilState } from 'recoil'// stylesimport { Container, Form } from 'react-bootstrap'// filters & atomimport { Filters, todoListFilterState } from '../atoms/filterAtom'export const TodoFilters = () => {  const [filter, setFilter] = useRecoilState(todoListFilterState)  return (    <Container className='mt-2'>      <h4>Filters</h4>      {Object.keys(Filters).map((key) => {        const value = Filters[key]        const checked = value === filter        return (          <Form.Check            key={value}            inline            label={value.toUpperCase()}            type='radio'            name='filter'            onChange={() => setFilter(value)}            checked={checked}          />        )      })}    </Container>  )}

// reactimport { useState } from 'react'// recoilimport { useSetRecoilState } from 'recoil'// libsimport { nanoid } from 'nanoid'// stylesimport { Container, Form, Button } from 'react-bootstrap'// atomimport { todosState } from '../atoms/todosAtom'export const TodoForm = () => {  const [text, setText] = useState('')  const setTodos = useSetRecoilState(todosState)  const updateText = ({ target: { value } }) => {    setText(value)  }  const addTodo = (e) => {    e.preventDefault()    const trimmed = text.trim()    if (trimmed) {      const newTodo = { id: nanoid(5), text, completed: false }      setTodos((oldTodos) => oldTodos.concat(newTodo))      setText('')    }  }  return (    <Container className='mt-4'>      <h4>Form</h4>      <Form className='d-flex' onSubmit={addTodo}>        <Form.Control          type='text'          placeholder='Enter text...'          value={text}          onChange={updateText}        />        <Button variant='primary' type='submit'>          Add        </Button>      </Form>    </Container>  )}

// recoilimport { useRecoilValue } from 'recoil'// componentsimport { TodoListItem } from './TodoListItem'// stylesimport { Container, ListGroup } from 'react-bootstrap'// atomimport { filteredTodosState } from '../atoms/filterAtom'export const TodoList = () => {  const filteredTodos = useRecoilValue(filteredTodosState)  return (    <Container className='mt-2'>      <h4>List</h4>      <ListGroup>        {filteredTodos.map((todo) => (          <TodoListItem key={todo.id} todo={todo} />        ))}      </ListGroup>    </Container>  )}

// reactimport { useState, useEffect } from 'react'// recoilimport { useRecoilValue } from 'recoil'// stylesimport { Container, ListGroup } from 'react-bootstrap'// atomimport { todosState } from '../atoms/todosAtom'export const TodoStats = () => {  const todos = useRecoilValue(todosState)  const [stats, setStats] = useState({    total: 0,    active: 0,    completed: 0,    percent: 0  })  useEffect(() => {    if (todos.length) {      const total = todos.length      const completed = todos.filter((todo) => todo.completed).length      const active = total - completed      const percent = total === 0 ? 0 : Math.round((active / total) * 100) + '%'      setStats({        total,        active,        completed,        percent      })    }  }, [todos])  return (    <Container className='mt-2'>      <h4>Stats</h4>      <ListGroup horizontal>        {Object.entries(stats).map(([[first, ...rest], count], index) => (          <ListGroup.Item key={index}>            {first.toUpperCase() + rest.join('')}: {count}          </ListGroup.Item>        ))}      </ListGroup>    </Container>  )}

Заключение

• Для управления локальным состоянием (состоянием одного-двух компонентов; при условии, что эти два компонента тесно связаны между собой) используйте useState()
• Для управления распределенным состоянием (состоянием двух и более автономных компонентов) или состоянием небольших и средних приложений используйте Recoil или сочетание useContext()/useReducer()
• Обратите внимание, что если вам нужно просто передавать значения в глубоко вложенные компоненты, то вам вполне хватит useContext() (useContext() сам по себе не является инструментом для управления состоянием)
• Наконец, для управления глобальным состоянием (состоянием всех или большинства компонентов) или состоянием сложного приложения используйте Redux Toolkit

Синтаксис

Отношение типов

Управляющие конструкции

В повседневной продуктовой разработке, запертой в корпоративных технологических ограничениях, редко выпадает случай шагнуть за грань добра и зла в самое пекло хипстерских технологий. Но, когда ты сам несешь все риски и каждый день разработки вынимает деньги из твоего собственного кармана очень хочется срезать путь. В один из таких моментов я решил шагнуть в такой темный серверлес, о котором раньше думать было как-то стыдно. Под впечатлением от того, что получилось, я даже хотел написать статью Конец гегемонии программистов, но спустя полгода эксплуатации и развития проекта понял, что ну не совсем еще конец и остались еще места в этом самом serverless-бэкенде, где надо использовать знания и опыт.

Архитектура

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

Второе решение было не хочу ничего менеджить собственными силами, цена devopsов сейчас слишком высока, одной зарплатой можно оплатить год managed-решений в облаках.

Третье, пожалуй самое безрассудное и на грани слабоумия и отваги, рискнуть пойти на новорожденное решение от MongoDB, которое в тот момент называлось Stitch, а сейчас называется Realm (но это не совсем тот самый Realm, а ядреная смесь из Stitch и Realm, которая получилась после приобретения последнего MongoDB, Inc в конце 2019 года)

Backend

В результате серверная сторона вышла вот такой:

Node и Redis в ней появились только для реализации Server Side Rendering и кэширования (ну и для того, чтобы не кормить Atlas лишними платными запросами), для тех кто не решает задачи CEO-оптимизации их можно легко выкинуть.

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

Frontend

Клиентская часть классическая: React + Redux + Redux-Saga + TypeScript

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

Аутентификация и авторизация

Ну а теперь самое интересно, для чего вообще нужно было все это мракобесие с Mongo.Realm. Вместе с лямбдами мы получаем полноценную интеграцию из коробки с ворохом способов аутентификации (Google, Apple, Facebook, Email/Password и прочими) и механизмом авторизации операций до уровня полей в коллекциях:

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

Прочие радости

Также облачная монга нам из коробки дает sync наборов данных с клиентом, push-уведомления, хранилище секретов, триггеры (на события базы, аутентификация, работу по расписанию), вебхуки, хорошие логи и еще много чего. То есть снаружи оно обслуживается и воспринимается как полноценный сервис, при этом не приходится решать вопросы масштабирования и переноса между датацентрами, бекапов, мониторинга и кучи других задач.

Ну, а для самых безбашенных, есть возможность работы через GraphQL.

Как все это работает

В случае если попали в кэш, при 100 RPS на один экземпляр (в конфигурации по одному ядру и одному гигабайту на один экземпляр Node.js под управлением PM2), время ответа укладывается в 200 мс, в противном случае вместе со всеми запросами к Mongo серверный рендер отрабатывает до 500 мс.

В работе с Mongo.Realm есть нюансы, которые никак не отражены в документации, но проявляются во всех недорогих инстансах с разделяемой памятью (M1, M2, M5): если запросы выполняются от имени клиента, то, видимо в качестве защиты от перегрузок, периодически время ответа на какой-нибудь aggregation-pipeline может резко вырасти до 5-10 секунд на запрос. При этом, если вызывается серверная функция (с тем же самым aggregation-pipeline), которая выполняется от имени системного пользователя, то таких трюков не наблюдается.
Возможно дело именно в типе кластера, и со временем это исправят или все решится переходом на М10 и выше, но сейчас для некоторых сложных запросов пришлось пойти на рискованный шаг и для чтения данных анонимными пользователями сделать несколько функций исполняемых от имени системного пользователя, в этом случае правила авторизации для доступа к данным игнорируются, и за безопасностью надо следить уже самим в коде.

В случае аутентифицированного доступа Server Side Rendering не нужен, все работает прямо на клиенте.

Выводы

В заголовок вынесен ресурс потраченный на разработку, а именно полтора программиста (1 фронтендер и бэкендера). Ровно столько и 5 месяцев работы, понадобилось для вывода в прод довольно развесистого портала с собственной системой управления контентом, интеграцией с несколькими поставщиками данных включая нечеткие сопоставления, оптимизированного под самые суровые требования по SEO и c поддержкой мобильный браузеров как first class citizen.

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

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

Redux

Задача

npx create-react-app my-app --template typescriptcd my-appnpm start

npm i redux react-redux redux-mock-store @types/redux @types/react-redux @types/redux-mock-store  

Actions

// actions/actions.test.tsimport { checkboxClick } from '.'describe('checkboxClick', () => {  it('returns checkboxClick action with action name in payload', () => {    const checkboxName = 'anyCheckbox'    const result = checkboxClick(checkboxName)    expect(result).toEqual({ type: 'checkbox/click', payload: checkboxName })  })})

// actions/package.json{  "main": "./actions"}// actions/actions.tsexport const checkboxClick = (name: string) => ({ type: 'checkbox/click', payload: name })

// actionTypes.tsexport const CHECKBOX_CLICK = 'checkbox/click'

// actions/actions.test.tsimport { CHECKBOX_CLICK } from 'actionTypes'import { checkboxClick } from '.'describe('checkboxClick', () => {  it('returns checkboxClick action with action name in payload', () => {    const checkboxName = 'anyCheckbox'    const result = checkboxClick(checkboxName)    expect(result).toEqual({ type: CHECKBOX_CLICK, payload: checkboxName })  })})

// actions/actions.tsimport { CHECKBOX_CLICK } from 'actionTypes'export const checkboxClick = (name: string) => ({ type: CHECKBOX_CLICK, payload: name })

Reducers

{  checkboxName: true}

// reducers/reducers.test.tsimport { checkboxReducer } from '.'describe('checkboxReducer', () => {  it('creates default state', () => {    const state = checkboxReducer(undefined, { type: 'anyAction' })    expect(state).toEqual({})  })})

// reducers/package.json{  "main": "./reducers"}// reducers/reducers.tsconst initialState: Record<string, boolean> = {}export const checkboxReducer = (state = initialState, action: { type: string }) => {  return state}

// reducers/reducers.test.tsimport { CHECKBOX_CLICK } from 'actionTypes'import { checkboxReducer } from '.'describe('checkboxReducer', () => {  it('creates default state', () => {    const state = checkboxReducer(undefined, { type: 'anyAction' })    expect(state).toEqual({})  })  it('sets checked flag', () => {    const state = checkboxReducer(undefined, { type: CHECKBOX_CLICK, payload: 'anyName' })    expect(state.anyName).toBe(true)  })})

// reducers/reducers.tsimport { CHECKBOX_CLICK } from 'actionTypes'const initialState: Record<string, boolean> = {}export const checkboxReducer = (  state = initialState,  action: { type: string; payload?: string },) => {  if (action.type === CHECKBOX_CLICK && action.payload) {    return { ...state, [action.payload]: true }  }  return state}

// reducers/reducers.test.ts  it('sets checked flag to false when it was checked', () => {    const state = checkboxReducer({ anyName: true }, { type: CHECKBOX_CLICK, payload: 'anyName' })    expect(state.anyName).toBe(false)  })

// reducers/reducers.tsimport { CHECKBOX_CLICK } from 'actionTypes'const initialState: Record<string, boolean> = {}export const checkboxReducer = (  state = initialState,  action: { type: string; payload?: string },) => {  if (action.type === CHECKBOX_CLICK && action.payload) {    return { ...state, [action.payload]: !state[action.payload] }  }  return state}

Selectors

// selectors/selectors.test.tsimport { getCheckboxState } from './selectors'describe('getCheckboxState', () => {  const state = {    checkboxes: { anyName: true },  }  it('returns current checkbox state', () => {    const result = getCheckboxState('anyName')(state)    expect(result).toBe(true)  })})

// types.tsexport type State = {  checkboxes: Record<string, boolean>}

// selectors/package.json{  "main": "./selectors"}// selectors/selectors.tsimport { State } from 'types'export const getCheckboxState = (name: string) => (state: State) => state.checkboxes[name]

// selectors/selectors.test.ts  it('returns false when checkbox state is undefined', () => {    const result = getCheckboxState('anotherName')(state)    expect(result).toBe(false)  })

// selectors/selectors.tsimport { State } from 'types'export const getCheckboxState = (name: string) => (state: State) => state.checkboxes[name] ?? false

Store

// store.tsimport { AnyAction, createStore, combineReducers } from 'redux'import { State } from 'types'import { checkboxReducer } from 'reducers'export const createAppStore = (initialState?: State) =>  createStore<State, AnyAction, unknown, unknown>(    combineReducers({      checkboxes: checkboxReducer,    }),    initialState,  )export default createAppStore()

React Components

npm i react-test-renderer @types/react-test-renderer

Checkbox

// components/Checkbox/Checkbox.test.tsximport { create } from 'react-test-renderer'import Checkbox from '.'describe('Checkbox', () => {  it('renders checkbox input', () => {    const checkboxName = 'anyName'    const renderer = create(<Checkbox />)    const element = renderer.root.findByType('input')    expect(element.props.type).toBe('checkbox')  })})

// components/Checkbox/package.json{  "main": "Checkbox"}// components/Checkbox/Checkbox.tsximport React from 'react'const Checkbox: React.FC = () => {  return (    <div>      <input type="checkbox" />    </div>  )}export default Checkbox

// components/Checkbox/Checkbox.test.tsxit('renders label', () => {    const labelText = 'anyLabel'    const renderer = create(<Checkbox label={labelText} />)    const element = renderer.root.findByType('label')    expect(element.props.children).toBe(labelText)  })

// components/Checkbox/Checkbox.tsxconst Checkbox: React.FC<{ label: string }> = ({ label }) => {  return (    <div>      <input type="checkbox" />      <label>{label}</label>    </div>  )}

// components/Checkbox/Checkbox.test.tsx  it('sets name prop as input id', () => {    const checkboxName = 'anyCheckbox'    const renderer = create(<Checkbox name={checkboxName} label={'anyLabel'} />)    const element = renderer.root.findByType('input')    expect(element.props.id).toBe(checkboxName)  })

// components/Checkbox/Checkbox.tsxconst Checkbox: React.FC<{ name: string; label: string }> = ({ name, label }) => {  return (    <div>      <input id={name} type="checkbox" />      <label>{label}</label>    </div>  )}

// components/Checkbox/Checkbox.test.tsx  it('sets name prop as label htmlFor', () => {    const checkboxName = 'anyCheckbox'    const renderer = create(<Checkbox name={checkboxName} label={'anyLabel'} />)    const element = renderer.root.findByType('label')    expect(element.props.htmlFor).toBe(checkboxName)  })

// components/Checkbox/Checkbox.tsxconst Checkbox: React.FC<{ name: string; label: string }> = ({ name, label }) => {  return (    <div>      <input id={name} type="checkbox" />      <label htmlFor={name}>{label}</label>    </div>  )}

// components/Checkbox/Checkbox.test.tsximport { Provider } from 'react-redux'import { create } from 'react-test-renderer'import { createAppStore } from 'store'import Checkbox from '.'// omit old code  it('sets checked flag from store when it`s checked', () => {    const store = createAppStore({ checkboxes: { anyName: true } })    const renderer = create(      <Provider store={store}>        <Checkbox name="anyName" label="anyLabel" />      </Provider>,    )    const element = renderer.root.findByType('input')    expect(element.props.checked).toBe(true)  })

// components/Checkbox/Checkbox.tsximport React from 'react'import { useSelector } from 'react-redux'import { getCheckboxState } from 'selectors'const Checkbox: React.FC<{ name: string; label: string }> = ({ name, label }) => {  const checked = useSelector(getCheckboxState(name))  return (    <div>      <input id={name} type="checkbox" checked={checked} />      <label htmlFor={name}>{label}</label>    </div>  )}export default Checkbox

// components/Checkbox/Checkbox.test.tsximport { ReactElement } from 'react'import { Provider } from 'react-redux'import { create } from 'react-test-renderer'import { createAppStore } from 'store'import { State } from 'types'import Checkbox from '.'export const renderWithRedux = (node: ReactElement, initialState: State = { checkboxes: {} }) => {  const store = createAppStore(initialState)  return create(<Provider store={store}>{node}</Provider>)}describe('Checkbox', () => {  it('renders checkbox input', () => {    const checkboxName = 'anyName'    const renderer = renderWithRedux(<Checkbox />)    const element = renderer.root.findByType('input')    expect(element.props.type).toBe('checkbox')  })  it('renders label', () => {    const labelText = 'anyLabel'    const renderer = renderWithRedux(<Checkbox label={labelText} />)    const element = renderer.root.findByType('label')    expect(element.props.children).toBe(labelText)  })  it('sets name prop as input id', () => {    const checkboxName = 'anyCheckbox'    const renderer = renderWithRedux(<Checkbox name={checkboxName} label={'anyLabel'} />)    const element = renderer.root.findByType('input')    expect(element.props.id).toBe(checkboxName)  })  it('sets name prop as label htmlFor', () => {    const checkboxName = 'anyCheckbox'    const renderer = renderWithRedux(<Checkbox name={checkboxName} label={'anyLabel'} />)    const element = renderer.root.findByType('label')    expect(element.props.htmlFor).toBe(checkboxName)  })  it('sets checked flag from store when it`s checked', () => {    const initialState = { checkboxes: { anyName: true } }    const renderer = renderWithRedux(<Checkbox name="anyName" label="anyLabel" />, initialState)    const element = renderer.root.findByType('input')    expect(element.props.checked).toBe(true)  })})

// utils.tsximport { ReactElement } from 'react'import { Provider } from 'react-redux'import { create } from 'react-test-renderer'import { Store } from './types'import { createAppStore } from './store'export const renderWithRedux = (node: ReactElement, initialState: Store = { checkboxes: {} }) => {  const store = createAppStore(initialState)  return create(<Provider store={store}>{node}</Provider>)}

// components/Checkbox/Checkbox.test.tsximport { renderWithRedux } from 'utils'import Checkbox from '.'describe('Checkbox', () => {

// components/Checkbox/Checkbox.test.tsx  it('sets checked flag from store when it`s unchecked', () => {    const initialState = { checkboxes: { anyName: false } }    const renderer = renderWithRedux(<Checkbox name="anyName" label="anyLabel" />, initialState)    const element = renderer.root.findByType('input')    expect(element.props.checked).toBe(false)  })

// components/Checkbox/Checkbox.test.tsx  test.each`    storedState | state    ${true}     | ${'checked'}    ${false}    | ${'unchecked'}  `('sets checked flag from store when it`s $state', ({ storedState }) => {    const initialState = { checkboxes: { anyName: storedState } }    const renderer = renderWithRedux(<Checkbox name="anyName" label="anyLabel" />, initialState)    const element = renderer.root.findByType('input')    expect(element.props.checked).toBe(storedState)  })

// components/Checkbox/Checkbox.test.tsximport { act } from 'react-test-renderer'// omit old code    it('changes it`s checked state when it`s clicked', () => {    const initialState = { checkboxes: { anyName: false } }    const renderer = renderWithRedux(<Checkbox name="anyName" label="anyLabel" />, initialState)    const element = renderer.root.findByType('input')    act(() => {      element.props.onChange()    })    expect(element.props.checked).toBe(true)  })

// components/Checkbox/Checkbox.tsximport React from 'react'import { useDispatch, useSelector } from 'react-redux'import { getCheckboxState } from 'selectors'import { checkboxClick } from 'actions'const Checkbox: React.FC<{ name: string; label: string }> = ({ name, label }) => {  const dispatch = useDispatch()  const checked = useSelector(getCheckboxState(name))  const handleClick = React.useCallback(() => {    dispatch(checkboxClick(name))  }, [dispatch, name])  return (    <div>      <input id={name} type="checkbox" checked={checked} onChange={handleClick} />      <label htmlFor={name}>{label}</label>    </div>  )}export default Checkbox

AgreementSubmitButton

// components/AgreementSubmitButton/AgreementSubmitButton.test.tsximport { renderWithRedux } from 'utils'import AgreementSubmitButton from '.'describe('AgreementSubmitButton', () => {  it('renders button with label Submit', () => {    const renderer = renderWithRedux(<AgreementSubmitButton />)    const element = renderer.root.findByType('input')    expect(element.props.type).toBe('button')    expect(element.props.value).toBe('Submit')  })})

// components/AgreementSubmitButton/package.json{  "main": "./AgreementSubmitButton"}// components/AgreementSubmitButton/AgreementSubmitButton.tsximport React from 'react'const AgreementSubmitButton: React.FC = () => {  return <input type="button" value="Submit" />}export default AgreementSubmitButton

// components/AgreementSubmitButton/AgreementSubmitButton.test.tsx  test.each`    checkboxState | disabled | agreementState    ${false}      | ${true}  | ${'not agreed'}    ${true}       | ${false} | ${'agreed'}  `(    'render button with disabled=$disabled when agreement is $agreementState',    ({ checkboxState, disabled }) => {      const initialState = { checkboxes: { agree: checkboxState } }      const renderer = renderWithRedux(<AgreementSubmitButton />, initialState)      const element = renderer.root.findByType('input')      expect(element.props.disabled).toBe(disabled)    },  )

// components/AgreementSubmitButton/AgreementSubmitButton.tsximport React from 'react'import { useSelector } from 'react-redux'import { getCheckboxState } from 'selectors/selectors'const AgreementSubmitButton: React.FC = () => {  const checkboxName = 'agree'  const agreed = useSelector(getCheckboxState(checkboxName))  return <input type="button" value="Submit" disabled={!agreed} />}export default AgreementSubmitButton

LicenseAgreement

1. Содержится заголовок и непосредственно текст лицензионного соглашения. Эта часть компонента не требует тестирования.
2. На форме имеется компонент Checkbox с определенными label и name. Это можно и нужно тестировать.
3. На форме имеется кнопка AgreementSubmitButton. Это тоже прекрасно поддаётся тестированию.

// components/LicenseAgreement/LicenseAgreement.test.tsximport { renderWithRedux } from 'utils'import Checkbox from 'components/Checkbox'import LicenseAgreement from '.'jest.mock('components/Checkbox', () => () => null)describe('LicenseAgreement', () => {  it('renders Checkbox with name and label', () => {    const renderer = renderWithRedux(<LicenseAgreement />)    const element = renderer.root.findByType(Checkbox)    expect(element.props.name).toBe('agree')    expect(element.props.label).toBe('Agree')  })})

// components/LicenseAgreement/package.json{  "main": "./LicenseAgreement"}// src/components/LicenseAgreement/LicenseAgreement.tsximport React from 'react'import Checkbox from 'components/Checkbox'const LicenseAgreement: React.FC = () => {  return (    <div>      <Checkbox name="agree" label="Agree" />    </div>  )}export default LicenseAgreement

// components/LicenseAgreement/LicenseAgreement.test.tsximport { renderWithRedux } from 'utils'import Checkbox from 'components/Checkbox'import AgreementSubmitButton from 'components/AgreementSubmitButton'import LicenseAgreement from '.'jest.mock('components/Checkbox', () => () => null)jest.mock('components/AgreementSubmitButton', () => () => null)describe('LicenseAgreement', () => {  it('renders Checkbox with name and label', () => {    const renderer = renderWithRedux(<LicenseAgreement />)    const element = renderer.root.findByType(Checkbox)    expect(element.props.name).toBe('agree')    expect(element.props.label).toBe('Agree')  })  it('renders SubmitAgreementButton', () => {    const renderer = renderWithRedux(<LicenseAgreement />)    expect(() => renderer.root.findByType(AgreementSubmitButton)).not.toThrow()  })})

// src/components/LicenseAgreement/LicenseAgreement.tsximport React from 'react'import Checkbox from 'components/Checkbox'import AgreementSubmitButton from 'components/AgreementSubmitButton'const LicenseAgreement: React.FC = () => {  return (    <div>      <Checkbox name="agree" label="Agree" />      <AgreementSubmitButton />    </div>  )}export default LicenseAgreement

Ключ на старт!

// App.test.tsximport { renderWithRedux } from 'utils'import LicenseAgreement from 'components/LicenseAgreement'import App from 'App'jest.mock('components/LicenseAgreement', () => () => null)test('renders LicenseAgreement', () => {  const renderer = renderWithRedux(<App />)  expect(() => renderer.root.findByType(LicenseAgreement)).not.toThrow()})

// App.tsximport React from 'react'import LicenseAgreement from 'components/LicenseAgreement'const App: React.FC = () => {  return <LicenseAgreement />}export default App

// index.tsximport React from 'react'import ReactDOM from 'react-dom'import { Provider } from 'react-redux'import 'index.css'import store from 'store'import App from 'App'ReactDOM.render(  <React.StrictMode>    <Provider store={store}>      <App />    </Provider>  </React.StrictMode>,  document.getElementById('root'),)

Заключение

• Официальный сайт Redux
• Best practice по разработке приложений с использованием Redux
• Фреймворк для тестирования JS приложений Jest
• Хабрастатья Андрея Хижняка REACT + JEST = TDD