HighLoad vs HighExtensible — эффективность против антихрупкости

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

Принят закон об электронных досье на жителей России

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

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

Вашему городу нужен метробус

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

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

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

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

5 практических рекомендаций по использованию React-хуков в продакшне

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

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

5 практических рекомендаций по использованию React-хуков в продакшне

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

5 практических рекомендаций по использованию React-хуков в продакшне

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

5 практических рекомендаций по использованию React-хуков в продакшне

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

5 практических рекомендаций по использованию React-хуков в продакшне

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

Как уменьшить количество и увеличить читаемость кода в react-redux, redux-saga

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

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

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

Госдума вводит штрафы за нарушение карантина и распространение фейковых новостей о коронавирусе

del

Минтруд: зарплаты в нерабочую неделю должны сохраниться на обычном уровне

A ИП уже не граждане?

Как уменьшить количество и увеличить читаемость кода в react-redux, redux-saga

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

Знание и состояние

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

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

Как уменьшить количество и увеличить читаемость кода в react-redux, redux-saga

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

Как уменьшить количество и увеличить читаемость кода в react-redux, redux-saga

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

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

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

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

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

Как уменьшить количество и увеличить читаемость кода в react-redux, redux-saga

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

Как уменьшить количество и увеличить читаемость кода в react-redux, redux-saga

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

Как уменьшить количество и увеличить читаемость кода в react-redux, redux-saga

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

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

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

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

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

Как уменьшить количество и увеличить читаемость кода в react-redux, redux-saga

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

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

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

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

Java: вещи, которые могут показаться любопытными и разработчику со стажем

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

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

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