#Полезное

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

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

Случайно нашел удобный загрузчик видео с YouTube - Statcher7.
Можно пользоваться на любой ОС.

Может скачивать видео и даже целые плейлисты! Гибко настраиваются, есть поддержка 4К. Работает быстро и без ограничений.

#Полезное

Вчера не смог выложить пост также по отсутствию времени - исправляемся.

Нашёл бесплатный редактор PDF файлов на macOS, Linux. Работает оффлайн и не требует мощной системы.

Позволяет быстро отредактировать текст, поправить вёрстку, добавить что-либо или даже обрезать страницу.

#Паттерны

Разработкой задуманного, к сожалению, заниматься пока некогда, поэтому временно я буду постить всякие полезности для себя и вас. Скорее всего этот формат постов перетечёт на постоянку параллельно с разработкой.

Наткнулся на известный паттерн Observer. Решил, что нужно закрепить его.

Смысл данного паттерна в том, что у нас должен быть Observer (Подписчик) и Subject (Источник событий). Подписчики подписываются на события источника, а источник при изменении своего состояния уведомляет подписчиком об изменении.
Всем приходит уведомления и подписчики реагируют на него. Все - это весь смысл.

Когда это может быть полезно?

- когда на одно событие реагируют несколько компонентов системы
- когда нужна архитектура, которую легко расширять, благодаря возможности подключения/отключения подписчиком "на лету"
- когда хочется уменьшить зависимость источника от подписчиков

Пример кейса:
Заказ на маркетплейсах. У него есть статусы: создан, оплачен, в пути, ожидает получения, получен.
В данном случае заказ воспринимается как источник событий, а подписчики, к примеру: уведомление, аналитика, начисление бонусов реагируют на на изменение состояния источника, то есть статуса.

#Архитектура

Сегодня я хотел бы поделиться своим взглядом на различные типы архитектур, используемые для создания Frontend-приложений:

- Монолит

Монолитная архитектура предполагает, что все приложение, включая пользовательский интерфейс (UI) и логику, хранится в одной кодовой базе. Она отлично подходит для небольших проектов, не требующих масштабирования, так как обеспечивает удобство отладки и быстрый старт разработки. Однако у этого подхода есть и недостатки: высокая связанность кода и медленная скорость развертывания. Чаще всего монолит используется в случаях, когда требуется быстрый запуск.

- Модульная архитектура

В модульной архитектуре код делится на независимые модули, каждый из которых можно разрабатывать, тестировать и вносить изменения отдельно от остальных. Из плюсов можно выделить возможность параллельной разработки модулей, что снижает сложность кодовой базы. Однако при увеличении количества модулей усложняется масштабирование и обзор кода. Модульная архитектура используется, когда требуется крупный монолит с сохранением модульности без необходимости переписывать код.

- Микрофронтенды

Микрофронтенды представляют собой подход, при котором приложение делится на изолированные друг от друга проекты. Этот метод хорош для команд, где каждая отвечает за свою часть приложения, что упрощает масштабирование. Однако усложняется взаимодействие между этими проектами, а также возникают риски несогласованности UX/UI.

- Feature Sliced Design (FSD)

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

Давайте подробнее рассмотрим слои:

- app: отвечает за конфигурацию приложения, роутинг, хранилище данных и другие аспекты
- pages: хранит страницы
- widgets: объединяет различные фичи, такие как баннеры, формы, посты и меню
- features: содержит бизнес-логику: кнопки авторизации, манипуляции с товарами и т. д.
- entities: хранит данные и логику работы с сущностями приложения
- shared: включает участки кода, которые используются по всему приложению: UI-компоненты, типизацию, хуки и т. д.

Слайсы представляют собой способы взаимодействия: типы, хуки, API, UI и другие. Они содержатся в сегментах.

#Паттерны

К сожалению или счастью, у жизни бывают перемены. Я с ними столкнулся и немного сбился с пути, но сдаваться не буду - пробуем и идем дальше.

Изучил еще один интересный паттерн Command.

Основная идея в том, чтобы использовать единый интерфейс для описания всех типов операций. Тогда для добавления новой операции в системе достаточно реализовать единый интерфейс.

Паттерн полезен, когда нужно:
- сохранять историю действий
- иметь возможность отката и повторения действий
- логирование и протоколирование

Необходимо создать класс Command с методами execute(), cancel(), name(). От него наследуются классы как самостоятельные команды, к примеру: HistoryCommand, UndoCommand, RedoCommand.

Методы:
- execute() - выполняет необходимую логику и сохраняет ее в историю действий
- cancel() - отменяет выполненное действие
- name() - возвращает имя команды

Паттерн определено сказка для терминальных (TUI) приложений