Перейти к основному содержимому

Введение

Sagun — это фреймворк для разработки React приложений, работающий поверх знакомых библиотек, таких как redux и redux-saga, который убирает весь бойлерплейт, а также позволяет легко расширять и тестировать код за счет применения проверенных десятилетиями паттернов проектирования, таких как MVC и DI.

На что ориентирован фреймворк​

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

Для разработки лендингов, или маленьких приложений данный фреймворк скорее всего будет избыточен.

Почему потребовалось создавать фреймворк​

  • Экосистема React в основном представляет собой набор библиотек, которые по отдельности решают свои задачи, но нет никаких четких паттернов как из них сделать хорошую архитектуру.
  • Библиотеки зачастую подталкивают разработчиков к упрощениям (например, писать все через react hooks), что хорошо подходит для быстрого прототипирования, но плохо отражается на качестве приложений, поскольку размываются, а то и вовсе пропадают границы и контракты между слоем предоставления, логикой приложения, доменной логикой и тд. А правильные абстракции и контракты - основа хорошей архитектуры.
  • Еще один паттерн, который является крайне полезным - Dependency Injection, в экосистеме React представлен только в виде React-контекстов, т.е. существует только на уровне представления, когда нужнее всего он при написании логики приложения и доменной логики, что опять же стимулирует разработчика писать код прямо в компонентах, смешивая все в одну кучу.
  • Если говорить про Redux, то код на нём наполнен бойлерплейтом, и даже более поздние решения, такие как redux-toolkit, предоставляют с одной стороны довольно перегруженный, а с другой — не очень гибкий API

При этом в поколении фреймворков до React, таких как KnockoutJS, BackboneJS, AngularJS и тд. при других их проблемах повсеместно применялись паттерны проектирования, и в среднем приложения были лучше структурированы, проще масштабировались и тестировались.

Таким образом хотелось создать решение, которое бы взяло лучшее из мира React и мира до React.

Почему Redux​

  • Исторические причины, на момент, когда фреймворк формировался, Redux был мейнстримным решением.
  • На текущий момент существует и все еще создается огромное количество приложений на Redux, которые могут извлечь пользу из фреймворка
  • Сама по себе базовая реализация Redux в его изначальном виде проста, понятна и довольно расширяема, что позволяет написать поверх свое более продвинутое решение

Почему redux-saga​

  • библиотека имеет очень мощный и при этом небольшой (в сравнении, например, с RxJS) API
  • дает огромную гибкость при работе с асинхронностью, позволяет просто писать сложные вещи
  • позволяет описать в одном месте любой сколь угодно сложный сценарий не размазывая его кусочками (как это делает, например, redux-thunk)
  • позволяет полностью отделить и удобно протестировать бизнес логику независимо от UI
  • за счет генераторов в основе из коробки предоставляет крутые свойства, например, возможность гранулярно прервать любую сложную асинхронную логику без необходимости пробрасывать abort контроллеры и проверять во многих местах факт отмены

Зависимости​

  • React 16+ (поддержка 16, 17, 18, 19)
  • Redux, react-redux, redux-saga
  • Immutable.js
  • TypeScript с experimentalDecorators: true

Следующие шаги​