Pull to refresh

Comments 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й вариант таки самый замечательный со всех точек зрения — инкапсулирует в себе логику получения данных и мемоизацию рендера — все в одном методе — не нужно плодить лишних сущностей

Выражаясь вашим языком — вся индустрия IT — это сплошной костыль к нашей бренной жизни :)

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


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

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


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

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

мы разработали свой редакс по следующим причинам:

— мы перешли на hooks и стандартный redux с ними не очень дружит (маинтейнер делал недавно доклад и рассказывал какие они костыли и танцы с бубном применяют чтобы синхронизироваться с жизненным циклом hooks)
— стандартный redux стал медленным из-за вышеописанных проблем (там под капотом создается класс который следит за подписками переподписками родителей и детей и переопределяет их порядок чтобы подписка родителя всегда вызывалась раньше чем у детей) и довольно много весит и есть нормальная альтернатива с контекстом и useRedux
— самое главное: у redux есть большая проблема — stale props и zombie children — react-redux.js.org/next/api/hooks#stale-props-and-zombie-children

альтернатива весит вообще ничего и нас полностью устраивает своей простотой и скоростью работы

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

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


stale props и zombie children

thx, почитаю.


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

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

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

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


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

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

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

Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
Россия
Website
vk.com
Employees
1,001–5,000 employees
Registered
Representative
Екатерина