#Review Affiction/angular-feature-sliced

[azinit]

Repository: https://github.com/Affiction/angular-feature-sliced

Methodology version: 2.0

[azinit]

🟩 Начну с хорошего

praise: Радует, что в целом структура соответствует некой конвенциональности с FSD, хоть и с небольшими расхождениями

[azinit]

nitpick(to-improve): Как улучшить - можно все же попытаться придерживаться более конвенционального нейминга, чтобы не было потом конфликтов с тулкитом FSD

• components => ui

nitpick(to-improve, public-api): Ну и файлы рекэспорты внутри модулей тоже бы не помешали

[azinit]

Т.е. прям значительно проще становится, открывая такую структуру

• хоть assets и не держал бы так глобально
• и environments спрятать ближе к shared/config (но тут возможно уже специфика ангуляра, точно не знаю)

[Affiction]

• хоть assets и не держал бы так глобально
• и environments спрятать ближе к shared/config (но тут возможно уже специфика ангуляра, точно не знаю)

Это некий дефолт в проекте, не хотелось бы трогать такие вещи.
assets и environments(альтернатива shared/config) на любом чистом проекте уже законфигурены в angular.json.

[azinit]

Так и понял)

[azinit]

praise: Тоже верно спроектировано, что store инициализируется в app

[azinit]

praise: То что логика роутинга находится в одном месте (да и еще близко к pages) - тоже крутецки!

[azinit]

praise: Страницы тоже сделаны по большей части по канону:

• Композируется логика из нижележащих слоев
• При этом логика страницы остается максимально тонкой

[azinit]

praise: Тоже здорово, что удается грамотно композировать локальные сегменты и нижележащие слои

[Lonli-Lokli]

Разве импорты на 2 уровня вверх хорошо? ConfigService

[azinit]

@Lonli-Lokli
feature-sliced/documentation#52 (reply in thread)

[azinit]

praise: Тоже канонично получается, что вся доменная логика ближе к entities расположена

[azinit]

🟥 Теперь криты)

issue(public-api): Очень много мест, где внутренности модулей импортируются напрямую, минуя уровень public-api

suggestion(public-api): Лучше в указанных местах объявить файлы-реэкспорты, хоть у ангуляра и есть для этого отдельно "**.module.ts" подход. Хотя бы на уровне слайсов
(хотя можешь тут как раз таки развернуть - почему возможно PublicAPI с реэкспортом тут будет избыточен тогда)

[azinit]

P.S. Получить такие ворнинги можно через eslint-config 😏

[azinit]

Вот как частные примеры нарушения Public API

[azinit]

issue(conventionality, naming): Уже много раз обсуждали, касаемо проблемы конвенциональности

Да, безусловно, никто не может запретить использовать собственные названия слоев/сегментов
Но и надеяться, что это будет лучше сказываться на коммуникации и профитности тулкита - тоже не стоит (пока что) 🤔

suggestion(conventionality, naming): По возможности, как писал выше, лучше бы все же переименовать components в ui)

(либо же можешь описать, почему не зашел вариант с ui)

[azinit]

А если надо будет положить куда-то логику, не относящуюся к компонентам, но так же реализующими UI-логику? 🤔
(тот же canvas, или всякие mapbox-like решения? куда их кладете в ангуляре?)

[Affiction]

Надеюсь понял правильно)

Чтобы упростить компоненту часть логики можно выносить в сервис/презентер/директиву и положить рядом с основным компонентом

my-page/
  components/
    foo/
      baz.directive.ts  # если связанность высокая компоненты и директивы. Случай крайне редкий.
      foo.presenter.ts
      foo.service.ts
      foo.component.ts

В остальном всё нормально можно натянуть на FSD, что-то реюзабельное идёт в lib, БЛ в model

pages/my-page/lib/foo.directive.ts
pages/my-page/model/foo.service.ts
shared/lib/directives/foo.directive.ts etc.

[azinit]

Ну т.е. angular в этом плане прям component-oriented, и все крутится вокруг него, если мы говорим про реализацию UI-логики, да?

[Affiction]

Всё верно, все те же компоненты, только добавили дополнительно парочку абстракций чтобы не придумывали велосипеды)

[azinit]

Понял, спасиб за разъяснения)

@feature-sliced/core будут мысли какие по ситуации?

[azinit]

praise: Еще касаемо api - тоже получается довольно канонично)

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

[azinit]

praise(routes): Еще из хорошего - что в shared тащишь только общую логику по работе с роутами, но не саму специфику роутов (от этого тоже есть проблемы)

[azinit]

nitpick: Разве что - public api тоже бы унифицировать

thoughts: А то получается, что можно использовать как routerModel.RouterFacade , так и RouterFacade отдельно

Может потом проблем при рефакторинге создать 🤔

[azinit]

nitpick(to-improve, non-blocking): Тут кста, та же проблема с public api)

[Affiction]

nitpick: Разве что - public api тоже бы унифицировать

thoughts: А то получается, что можно использовать как routerModel.RouterFacade , так и RouterFacade отдельно

Может потом проблем при рефакторинге создать 🤔

RouterFacade сервис используется чисто для DI.

Хотелосьбы писать:

class FooComponent {
    constructor(private routerFacade: RouterFacade){}
}

вместо:

class FooComponent {
    constructor(private routerFacade: routerModel.RouterFacade){}
}

Потому экспортируется и то, и то, в противном случае выйдет что мы нарушим правило с публичным апи

export * as TaskModel from './model'; // экспортируем всё кроме TaskFacade
export * as TaskLib from './lib';
export { TaskFacade } from './model/task.facade.ts'; // проблема появляется здесь
export { TaskModule } from './task.module';

Есть идеи как разрулить такое?)

[azinit]

Да ощущение, что все это резолвится банальным реэкспортов юнитов из сегментов таким образом, чтобы при использовании не надо было лезть во внутренности (т.е. как ты описал как раз)

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

Но с DI в целом непросто может быть, так что понимаю
(хотя в целом пока не особо вижу проблемы использования routerModel.RouterFacade)

[azinit]

🟨 Теперь non-blocking

Осталось немного 😏

nitpick(to-improve, non-blocking): Некрит, но можно попробовать придерживаться порядка импортов для слоев - для консистентности

Подробнее тут, автофиксится спокойно

[azinit]

nitpick(to-improve, non-blocking, public-api): Некрит, но для app и environments - тоже бы файлы реэкспорты объявить

[azinit]

nitpick(to-improve, non-blocking, naming): Некрит, но если есть возможность не дублировать неймспейсы в структуре - будет лучше
(и для рефакторинга, и для восприятия)

Т.е. тут toggle-task/**/toggle-task излишен, как если бы было pages/some/some-page-content/...

[Affiction]

Обычно компоненты генерируются через cli. На выходе получаем foo.component.(html|css|ts), внутри FooComponent и в метаданных указан selector: 'prefix-foo'. С одной стороны можно изначально сгенерировать просто card, но тогда внутри нужно переименовать selector компонента на уникальный, если 2 одинаковых селектора будет, то компилятор выдаст ошибку. Если честно, нигде не видел чтобы такое практиковали с разным неймингом селектора и файлов)

[azinit]

Эхх, опять специфика ангуляра ставит палки)
Но оке, если это конвенционально, то тут ничего не сможем сделать
Просто я в целом к тому, чтобы не порождать модули типа pages/some/some-page-content, т.к. это избыточный нейминг)

@feature-sliced/core не дадут соврать, уже думаем этот антипаттерн в доку занести))

[azinit]

nitpick(to-improve, non-blocking, shared): Некрит, но точно ли нужно для shared uikit отдельный сегмент создавать, если идет подвязка на внутреннюю либу? 🤔

[azinit]

nitpick(to-improve, non-blocking, shared): Ну и тут тоже - есть сомнения определенные, что к любому сегменту shared стоит обращаться через единый файл реэкспорт
(почти то же, что для entities и features делать такой же общий Layer PublicAPI 😏 )

Особенно учитывая - что там только UIKit, даже без lib

[Affiction]

Здесь не знал куда положить)

UiKitModule закинул в share/ui
SharedModule закинул в shared/lib

[azinit]

nitpick(to-improve, non-blocking, model): Некрит и внутреннее устройство model - зависит от команды и стека

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

Возможно у rxjs такие же практики - тогда ок)
Но если есть возможность держать это все добро в одном файле - то мб и к лучшему? 🤔

[azinit]

Хотя это даже не non-blocking , а скорее размышления

[Affiction]

Сторы генерируются схематиком nx. Структура здесь +- дефолтная. В store-name.models.ts обычно лежит не конкретная моделька, а всё что относится к данному стору

[azinit]

🔳 Теперь чисто мысли

thoughts(structure): Структура каждого модуля выглядит прям оверхедно, ввиду специфики ангуляра
А если еще добавить **.module.ts файлы - то вообще жесть)

Надеюсь тут или выше раскроешь подробней - почему это ОК для ангуляра

[azinit]

thoughts(public-api): Тоже интересно, что приходится заранее объявлять импортируемые зависимости и экспортируемые юниты

Но чет даже при всей строгости FSD кажется оверхедно, если такое пытаться "подружить" с файлами реэкспортами 🤔

[Affiction]

В Ангуляре всё построено на концепции модулей. Каждый модуль может быть вполне самостоятельной либкой. Потому с нашей стороны мы готовим модуль, импортируем зависимости которые будем использовать, например в компонентах, и экспортируем то с чем конечный пользователь может взаимодействовать.

• В declarations мы указываем какие компоненты, директивы, пайпы относятся к этому модулю (нужно компилятору)
• В imports мы указываем какие сторонние модули нужны чтобы компоненты адекватно работали. Пример, в SharedModule экспортируется CommonModule, который позволяет в разметке использовать базовые дериктивы *ngIf, *ngFor, пайпы DatePipe и тд. Если не передать, то компилятор упадёт с ошибкой если будем пытаться использовать выше перечисленные директивы.
• В exports передаёт то что можно будет использовать в других модулях при импорте конкретного модуля. Так сказать некое публичное апи
• В providers регестрируются сущности для DI

Я бы не сказал что здесь будут какие-то проблемы. Пример, делаем фичу, сразу создаём ангуляр модуль под фичу, в ней регистрируем компонент в declarations, и добавляем в exports чтобы могли использовать в сторонних модулях. Дальше чтобы использовать на конкретной пейдже, мы добавляем модуль фичи в imports нашей пэйджи, и после этого можем спокойно использовать фичу в разметке, вставив простой тег <prefix-my-feature></prefix-my-feature>

[azinit]

Реактовцы рвут волосы на себе от такой "осознанной декларативности"))

Но в целом да, понимаю что специфика ангуляра во многом

[azinit]

Тут проблемно именно, что PublicAPI в случая ангуляра оформляется на двух уровнях:

• Файлы реэкспорты (чтобы во внутренности не лезть)
• **.module файлы (чтобы "компилятор ангуляра" подхватил)

[azinit]

FINAL

Фух, постарался сильно не докапываться, но основные моменты расписал)

@Affiction, если получится хотя бы криты поправить - то уже можем заливать твой пример в доку

[azinit]

Ну и это тоже тут оставлю, чтоб не потерялось

https://www.npmjs.com/package/@feature-sliced/eslint-config

[Lonli-Lokli]

Появилась новая фишка - standalone components, компоненты без NgModule (как условный докер)

[azinit]

@Affiction FYI

[Affiction]

https://angular.io/guide/standalone-components

The standalone component feature is available for developer preview. It's ready for you to try; but it might change before it is stable.

Пока не вижу чтобы фича глобально повлияла на структуру.
В будущем если фича приживётся, подрефачу продж

[Lonli-Lokli]

@Affiction А почему вообще не используется libs из Nx?

[Affiction]

@Lonli-Lokli на сколько помню, там нету никаких вещей которые могли бы стать либами