Если серьезно, то преимущество редакса это иммутабельность. K.O.
Но вы платите огромную цену ради нее - бойлерплейтом, производительностью и скоростью разработки. Поэтому возникает вопрос - действительно ли вам настолько сильно нужна иммутабельность?
⬇️
1. В какой ситуации вообще вам может понадобиться иммутабельность на фронте? Мне в голову приходит какой-нибудь текстовый редактор, чтобы легко можно было реализовать undo/redo.
2. Но в реальном мире вам для текстового редактора скорее всего понадобится режим совместного редактирования и там уже нужно реализовывать совсем другие паттерны, а не примитивный Memento.
3. Говоря о преимуществах иммутабельности, часто упоминают простоту логирования и возможность "поднять" приложение из снапшота состояния. Но почему для логирования вы вдруг решили брать старое состояние, сравнивать его с новым, а разницу выводить?
4. Почему нельзя просто повесить new Proxy() и логировать вообще все что угодно, хоть каждое обращение к объекту?
Ах да, в IE11 ведь нету Proxy. Ну что ж, печально работать на проекте, который поддерживает браузер, от поддержки которого год назад отказался сам Microsoft.
5. По правде говоря, редакс-фанбоям не нужна иммутабельность сама по себе. Их просто привлекает "ореол крутости" ФП - чистые функции и все такое. В таких случаях я объясняю фанбоям, что методы MobX хоть и не являются чистыми, но они идемпотентные.
6. Конечно большинство фанбоев ничего не слышали про идемпотентность, но "крутость" этого слова заставляет их успокоиться и хотя бы посмотреть в сторону MobX.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
1. Используя Selenium-библиотеки вы получаете кучу очень хрупких абстракций. Возьмем, например, yandex.ru/dev/hermione/:
Hermione => WebdriverIO => Selenium => Java-интерфейс => драйвер под конкретный браузер.
На каждом из уровней вас ждут проблемы, прям как в фильме "Начало".
С бэкендом определились. Идем дальше по пирамиде тестирования.
⬇️
1. В основе пирамиды на мой взгляд должны стоять не Unit-тесты, а строгая типизация и строгие линтеры. Помимо стандартных ESlint-плагинов, типа react, react-hooks, jsx-a11y, node, promise, import и т.д., обратите внимание на: github.com/SonarSource/es… и github.com/sindresorhus/e…
2. Готовые конфиги (типа eslint-config-airbnb) мне не нравятся тем, что они смешивают стилистические и логические правила. Для стилистических обычно хватает prettier.io, а логические придется вручную собирать среди кучи плагинов, о которых я говорил выше.
Победило тестирование. Начнем с обсуждения того, из-за чего чаще всего возникают баги на фронте.
⬇️
1. 99% багов возникают на стыке систем. Условно говоря , на фронте все ок, на бэке все ок, а баги возникают в процессе их взаимодействия. Бэкенд поменял формат ответа и забыл вас об этом предупредить - и все сломалось. Поэтому в первую очередь решите вопросики с бэкендом.
2. Научите бэкендеров версионировать API и расширять ручки без ломающих изменений. Естественно, доверять на слово нельзя. Должны быть автоматические проверки всех ответов бэкенда на соответствие схеме. В GraphQL это работает из коробки.
Второе преимущество Redux - его дикая популярность. Расскажу, что делать, если в детстве трудовик оставался с вами наедине, сажал к себе на колени и заставлял писать на Redux.
⬇️
Благодаря повальной чипизации населения общий интеллектуальный уровень людей растет. Поэтому каждый год удовлетворенность Редаксом падает, с 93% в 2016 году до 67% в 2020: 2020.stateofjs.com/ru-RU/technolo…
Так что имеет смысл хотя бы познакомиться с альтернативами.
Если же в 2021 году вы начинаете новый проект с Redux, то имеет смысл задуматься о своем предназначении в жизни. Разве для этого вы родились? Чтобы писать бесконечный бойлерплейт?
Возьмите хотя бы redux-toolkit.js.org и забудьте про трудовика как про страшный сон.
Идем дальше. Расскажу, что делать, если физрук оставлял вас после уроков и не давал пользоваться GraphQL.
⬇️
1. GraphQL крут тем, что из коробки дает тебе документацию, валидацию запросов/ответов и TS-типы. Об этом подробно рассказала @pgurtovaya на прошлой неделе.
2. Но проблема в том, что бэкендеров, которые только вчера отказались от SOAP или RPC в пользу JSON REST API, довольно трудно заставить заехать на GraphQL.
Поэтому расскажу, как получить developer experience хотя бы приближенный к GraphQL.
1. BFF - это адаптер к внешним API, который агрегирует запросы из разных источников и отдает на фронт в удобном для фронта виде.
В Яндексе BFF используется повсеместно. Подробнее в статье от @amel_true - habr.com/ru/company/yan…
2. BFF - это отличное решение, но только если у вас очень сильная команда инфры. Деплоить, мониторить, балансировать, логировать - все это не так просто, как кажется. Если у вас нет выделенной команды инфраструктуры (или сильных DevOps), не стоит в это ввязываться.