Как стать автором
Обновить
22
0
Дмитрий Панюшкин @gnaeus

Пользователь

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

Я конечно не оправдываю overengineering, и три слоя объектов это реально перебор. Но вот ubiquitous language — действительно полезная штука. Особенно, когда она работает не только для разработчиков, но и для PM, тестеров, аналитиков. Потому что в противном случае появляется по два-три названия для одного и того же: одно в багтрекере, другое в документации, третье в коде.

обеспечить комфортную температуру

варения лягушки

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

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


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


В статье неспроста упоминаются "маломобильные" в т.ч. люди с детьми или грузами. Так что каждый из нас является маломобильным время от времени. Но доступный для них транспорт — ну разве что в городах миллионниках да и то в гомеопатических количествах.

И это отражено в сигнатуре useCallback в @types/react


function useCallback<T extends (...args: any[]) => any>(
  callback: T, deps: DependencyList
): T;

Спасибо тебе, добрый человек!

В чем ошибка-то?
A, понятно. В TS оно без массива зависимостей вообще не скомпилится.

Я конечно понимаю, что это перевод. Но пользуясь случаем хочу спросить у знающих людей:
как тестировать хоть сколько-нибудь сложные custom Hooks? Например, с контекстом, асинхронными эффектами или third-party хуками.

Иначе будут создаваться новые increment, decrement, reset при каждом перерендере Component. И ниже по дереву не будут работать всякие React.memo / React.useMemo.

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

Потому что нужна некая транзакционность, иначе можно получить рендер в невалидном состоянии: например обращение к null в одном из селекторов.


Да, это можно решить и по-другому (напр. redux-batched-actions), но ванильный Redux ничего не говорит об этом.

Но хуки из коробки не предоставляют никакого механизма подписки на изменения частичного стейта из useReducer для компонентов-потомков в глубине дерева.

Я бы еще добавил в копилку систем управления внешним состоянием ("знанием" в Вашей терминологии) всяческие библиотеки для кеширования вроде zeit/swr или react-query, в которых поддерживается концепция Query / Mutation.


Если проводить аналогию с базами данных, то GraphQL будет как полноценная реляционка.
А эти так, key-value. Зато никаких ограничений на источники данных.

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

Проблема в том, что видение авторов React отличается от авторов MobX. И такое чувство, что первые пытаются усложнить жизнь вторым.


Например, если раньше можно было просто навесить @observer на класс, то теперь с хуками встречаются вот такие чудеса: useObservableSource, потому что props не реактивны.


Все это печально, и отпугивает новичков от MobX. Поэтому он и не так популярен, как мог бы.


кто после вас будет работать с этим «замечательным» кодом

Ну на MobX я видел не менее «замечательный» код, где reaction на reaction-е и subscribe-ом погоняет. Хотя многое можно было запихнуть в @computed. Это все говорит о том, что инструментом нужно еще уметь пользоваться. А не «вот вам MobX и будет счастье».

А еще rematch, easy-peasy, симбиоты тут ниже в треде проскакивали, тысячи их…
И на каждом проекте своя байда. А голый Redux неюзабелен. Тем и бесит =(

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

Ну прелесть этого подхода в том, что он не вносит нового API. Просто расшаривает состояние custom Hook на поддерево компонентов.


Нравится нам это или нет, но в React по сути придумали свою систему реактивности,


  • с атомами: useState()@observable,
  • производными: useMemo()@computed,
  • и эффектами: useEffect()reaction().

Часто этого бывает достаточно.


P.S. Против MobX ничего не имею. Сам начинал с Knockout еще, и был очень рад, когда кто-то реализовал подобную концепцию для React.

Кстати, есть еще вот такой https://github.com/diegohaz/constate способ обойтись React Context API для не очень сложной логики. В двух словах: оборачиваем custom Hook в Context.


Бонусом идет bottom-up проектирование:


  • пишем логику непосредственно в компоненте,
  • стало сложно — оборачиваем в custom Hook
  • стало нужно в двух местах — оборачиваем custom Hook в Context.

При этом объем рефакторинга минимальный. Вес самой либы 0.5 Kb

Никаких граблей

Ну такое себе:


// a == null
a.equals(b);
// NullPointerException

Информация

В рейтинге
Не участвует
Откуда
Калуга, Калужская обл., Россия
Дата рождения
Зарегистрирован
Активность