ReactJS *

С code splitting я познакомился очень давно, в году так 2008, когда Яндекс немного подвис, и скрипты Яндекс.Директа, синхронно подключенные на сайте, просто этот сайт убили. Вообще в те времена было нормой, если ваши "скрипты" это 10 файлов которые вы подключаете в единственно правильном порядке, что и до сих пор (с defer) работает просто на ура.
Потом я начал активно работать с картами, а они до сих пор подключаются как внешние скрипты, конечно же lazy-load. Потом уже, как член команды Яндекс.Карт, я активно использовал ymodules возможность tree-shaking на клиенте, что обеспечивало просто идеальный code splitting.

А потом я переметнулся в webpack и React, в страну непуганных идиотов, которые смотрели на require.ensure как баран на новые ворота, да и до сих пор так делают.

Code splitting — это не "вау-фича", это "маст хэв". Еще бы SSR не мешался...

React 16.18 — первый стабильный релиз с поддержкой react hooks. Теперь хуки можно использовать не опасаясь, что API изменится кардинальным образом. И хотя команда разработчиков react советует использовать новую технологию лишь для новых компонентов, многим, в том числе и мне, хотелось бы их использовать и для старых компонентов использующих классы. Но поскольку ручной рефакторинг — процесс трудоемкий, мы попробуем его автоматизировать. Описанные в статье приемы подходят для автоматизации рефакторинга не только react компонентов, но и любого другого кода на JavaScript.

На днях ковыряясь в множестве файлов redux'a, где по логике файлы вынесены в reducers, actions, константы типов actions. Bсе это оказалось весьма не простая задача держа все эти типы файлов у себя в голове и прослеживать логику. И… эврика, появилась идея упрощения написания redux логики. Возможно создавая свой велосипед, но кто не пытался писать свои велосипеды? Но главное это не написание а поддержка написанного когда. Давайте я вам немного постараюсь показать свое видение моей логики redux'a.

О чем пойдет речь?

Посмотрим на метаморфозы редьюсеров в моих Redux/NGRX приложениях за последние пару лет. Начиная с дубового switch-case, продолжая выбором из объекта по ключу и заканчивая классами с декораторами, блекджеком и TypeScript. Постараемся обозреть не только историю этого пути, но и найти какую-нибудь причинно-следственную связь.

Начнём с железа

Доброго времени суток.

У вас тоже есть знакомый react-разработчик, который рассказывает восхитительные истории о сайд-эффектах в redux? Нет?! Могу я стать этим человеком?

Автор взял на себя смелость не писать вводную часть о том, что же из себя представляет библиотека redux saga. Он надеется, что в случае недостаточности данных великодушный читатель воспользуется поиском хабра или официальным туториалом. Приводимые примеры во многом упрощены для передачи сути.

Приветствую, сегодня я собираюсь поговорить с вами о способе организации Reducer'a. И рассказать с чего я начал и к чему пришел.

Итак, есть некий стандарт по организации Reducer и выглядит он следующим образом:

export default function someReducer(state = initialState, action) {
    switch (action.type) {
    case 'SOME_REDUCER_LABEL':
    return action.data || {};
    default:
    return state;
    }
}

Тут все просто и понятно, но немного поработав с такими конструкциями я понял что данный метод имеет ряд сложностей.

• Метки надо как то хранить, потому что они начали расползаться по проекту и уползать далеко за пределы контроллеров.
• Метки надо было делать уникальными, потому что иначе могло быть пересечение с другими reducer'ами
• Большая часть времени при работе с такой структурой тратилась на организацию кода, нежели на обработку входящих данных
• И когда меток в reducer набирается много — код становиться неряшливым и трудно читаемым, ну и общее пространство имен меня откровенно не радовало.