Как стать автором
Обновить

Комментарии 19

Было бы хорошо начать использовать typescript ибо это накладывает большие ограничения на использование библиотеки VKUI, которой до сих пор нельзя пользоваться.
ВКонтакте есть подвижки на тему TS, поэтому есть вероятность, что в VKUI он тоже появится. К сожалению, точнее пока сказать не могу.
А теперь, посмотрите на код приведённый в примерах и спросите себя: «Я действительно хочу поддерживать этот треш годами?».
НЛО прилетело и опубликовало эту надпись здесь
Этих статей уже куча… и оказывается, что хуки это еще не то, что может заменить redux, что надо писать еще свои дополнения. Уже несколько таких реализаций есть. Вообщем опять будет зоопарк из этих кастомных дополнений.

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

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

НЛО прилетело и опубликовало эту надпись здесь

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

НЛО прилетело и опубликовало эту надпись здесь

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


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

НЛО прилетело и опубликовало эту надпись здесь

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


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

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


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

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

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

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


stale props и zombie children

thx, почитаю.


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

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

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

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


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

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

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

Зарегистрируйтесь на Хабре , чтобы оставить комментарий