Всем привет, меня зовут Сергей Сибара, я фронтенд-разработчик в ИТ-холдинге Т1. Эта статья — продолжение предыдущей: Мой справочник по Feature-Sliced Design. На этот раз я рассмотрю, как по моему субъективному мнению улучшить файловую структуру проекта, нарушая рекомендации FSD — архитектурной методологии для проектирования фронтенд-приложений.
В конце статьи есть ссылки на другие подходы к организации файловой структуры фронтенд-приложений.
Всем привет, меня зовут Сергей Сибара, я фронтенд-разработчик в ИТ-холдинге Т1. Так как при использовании Feature-Sliced Design (FSD) возникает много вопросов и разные люди понимают её по-разному, я решил написать статью-справочник, раскрывающий некоторые подробности методологии.
В этой части я опишу, приблизительно какую архитектуру использую в своих проектах. MobX взят, так как он довольно простой и удобный, из коробки есть готовая реализация паттерна Observer, автоматическая мемоизация и автоматическое обновление компонентов при изменении состояния хранилища.
Я много раз читал, как кто-то попробовал MobX, у него код получился запутанным с не контролируемыми изменениями, после чего он продолжил писать на Redux. Для MobX нет рекомендованной архитектуры. Но при использовании и соблюдении в MobX строгой и однообразной (имеется ввиду одинаковой в различных участках проекта) архитектуры, можно получить понятный код с контролируемыми изменениями в сколь угодно большом проекте. Я опишу один из вариантов, как этого добиться.
Эта часть статьи будет об осмыслении составляющих Redux. Так ли они необходимы, что является их аналогом. Также будет предложена более удобная альтернатива хука useReducer.
На самом деле, я не буду воспроизводить Redux. Вместо этого, в следующей части будет описано, как спроектировать более удобную архитектуру с использованием MobX. Следующая часть в основном для тех, у кого проекты на MobX получались запутанными, с неконтролируемыми изменениями.
В этой части статьи я хочу показать, что:
— редьюсеры - это аналог обычных чистых функции для получения нового состояния.
— селекторы - это аналоги обычных функций с мемоизацией, которые возвращают данные.
— dispatch + action + action creators - это аналог обычных вызовов функций, и разбиение на dispatch, action, action creators является зачастую ненужным и используются не к месту.
В этой статье я покажу, как для React-компонентов реализовать один из подходов на основе сущностей и их составляющих. Описываемый подход используется для решения той же проблемы, что HOC и Custom hooks – повторно использовать код между множеством однотипных объектов/функций и разбивать сложные объекты (такие как компоненты в веб-разработке) на более простые составляющие.
Даже если этот подход вам не интересен, как минимум вы увидите, как можно переделать структуру функциональных компоненты и компонентов-классов под свои нужды. Узнаете нестандартные приемы, которые можно использовать при разработке компонентов.
Те, кто пишет компоненты-классы, узнает, как повторно использовать код более эффективным способом, чем HOC, не создавая лишние компоненты-обертки.
В этой статье я опишу различные техники повторного использования кода и разбиения сложных объектов на части, с которыми я столкнулся. Постараюсь объяснить, почему классическое наследование, а также некоторые другие популярные подходы не работают в сложных случаях, и какие есть альтернативы.
Будет рассказано о декораторах, стратегиях, Entity Component, Entity Component System, деревьях, State Machine, частично о хранении хуков в React.
Возможно многих удивит, что в основе большинства подходов повторного использования кода лежат стандартные структуры данных – массив, список, словарь, дерево, граф.