Управление стейтом с помощью React Hooks – без Redux и Context API

[polRk]

Было бы хорошо начать использовать typescript ибо это накладывает большие ограничения на использование библиотеки VKUI, которой до сих пор нельзя пользоваться.

[ArthurSupertramp]

ВКонтакте есть подвижки на тему TS, поэтому есть вероятность, что в VKUI он тоже появится. К сожалению, точнее пока сказать не могу.

[nshkaruba]

Топ!

[Staltec]

А теперь, посмотрите на код приведённый в примерах и спросите себя: «Я действительно хочу поддерживать этот треш годами?».

[bex2014]

Этих статей уже куча… и оказывается, что хуки это еще не то, что может заменить redux, что надо писать еще свои дополнения. Уже несколько таких реализаций есть. Вообщем опять будет зоопарк из этих кастомных дополнений.

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

[ArthurSupertramp]

А зачем останавливаться?) Я в одном из своих проектов до сих пор использую Redux, в другом – вообще ничего не юзаю, кроме state и props, потому что приложение маленькое. По-моему это классно, когда люди придумывают новые подходы, особенно если их идеи снабжены аргументацией.

[gnaeus]

Более того, как выяснилось впоследствии, хуки и контекст в текущем виде не могут полностью заменить Redux. Потому что useContext() перерисовывает компонент при любом изменении значения в Context.Provider. И подписаться только на интересующие нас части состояния как в mapStateToProps невозможно. Приходится писать свой кастомный HOC по типу connect из react-redux. Что убивает саму идею хуков для управления состоянием относительно сложных приложений. Хотя для простых сойдет.

[faiwer]

По ссылке 2 обёртки и 1 костыль. По сути там предлагается ровно то что делает connect: Memo + HoC (вариант 2) + context. О чём выше и написал gnaeus. Вариант 3 там видимо шутки ради указан :)

[faiwer]

Я не состою в священной церкви Абрамова. И вариант номер 3 это самый настоящий костыль (я уж молчу про то, что хуки сами по себе похожи на тот ещё костыль). Такое не должно проходить код-ревью.

P.S. Я понимаю когда "лебезят" перед действительно выдающимися программистами, но камон, причём тут Абрамов. Он просто публичная фигура от команды React, не более.

[faiwer]

Присмотрелся внимательнее к 3-му варианту. Признаю, что был неправ, т.к. прочитал тот код по диагонали и воспринял третий вариант как объединение контейнера, вьюхи и мемоизации в одной функции. А там всё-таки вьюха отдельно (<ExpensiveTree className={theme} />).

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

Стесняюсь спросить, а зачем вы его руками на хуках написали? Что именно в стандартном connect вас не устроило так сильно, что сподвигло вас на велосипед?

но тем не менее его успешно все его используют

шутка про wordpress & drupal & joomla & ...
P.S. мне one-way подход нравится, но всё таки успешность слабый аргумент.

[faiwer]

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

О я на эти грабли натыкался. Пару лет назад этого не было и я ловил адовые глюки на этой почве. Когда у детей падал mapStateToProps, до того как React успевал их убить.

stale props и zombie children

thx, почитаю.

возможно осенью будет доклад на #ReactRussia если тема будет интересна широкой аудитории

Про широкую аудиторию не скажу, но лично мне был бы интересно послушать.

[david_mz]

Расскажите, очень интересно. Ещё статью написать можно.

[gnaeus]

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

А откуда в Context API лишние перерисовки по сравнению с подходом из статьи?
Возьмем для примера, как это реализовано в библиотеке constate:

1. Пишем произвольный кастомный хук с useState / useReducer
2. Распространяем его состояние вниз по дереву компонентов с помощью Context.Provider
3. Подписываемся на изменения состояния с помощью useContext

Рендеринг будет вызван только для подписавшихся компонентов.

[amakhrov]

Я бы даже добавил, что подход в статье вызывает перерисовку всех-всех подписанных компонентов на каждое изменение стейта — неважно, что там изменилось.