Feature Sliced Review 🍰

[azinit]

Во-первых, спасибо большое что смог заняться этим! 🚀 🚀

Отпишу мысли тут, потом бы в GH-Discussions трансформировать, как тут

В упомянутой ишьюс кста тож отписал, почему формат PR тут для ревью не оч подходит

---

P.S.

• Ссыль на воркспейс с кодом для ревью
• Ссыль на "оригинальную" TodoApp на реакте

[azinit]

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

praise: Здорово, что удалось переиспользовать shared-модули "as-is", без всякого шаманства

[azinit]

praise: Получилось довольно таки соответствующе FS по структуре и конвенциям)

Посмотрим что потом @niyazm524 скажет, но кажется прям топчик вышло (даже если чисто внешне на структуру смотреть)

[niyazm524]

Да, согласен, + не догадался бы компонент RouterView в pages оставить)

[azinit]

praise: С провайдерами тоже довольно интересно вышло)

Прям по канону

[azinit]

praise: Хз что @niyazm524 скажет, но кажется довольно интересно получилось с Public API компонентов разобраться 👍

[azinit]

praise: Круто также, что удалось передать мысль о "композиции логики"

[azinit]

Теперь криты

Их нет, ни за что существенного глаз не зацепился

Аж свербит :D

[azinit]

Теперь прочие замечания

nitpick(non-blocking): Убрать бы все глобальные стили на уровень app

thoughts(non-blocking): Похожий недочет был и в оригинальном TodoApp
Но лучше чтоб все глобальные стили в одном месте декларировались

feature-sliced/examples@a20375a

[azinit]

nitpick(non-blocking): Сейм, это подключение глобальных стилей - желательно вынести на уровень src/app/styles/index.scss как в оригинале

thoughts: Если импорты нод-модульных стилей подтупливают, мб этот коммит поможет 🤔
feature-sliced/examples@6a83c96

[azinit]

issue(non-blocking): Хз насколько во vuex приемлемы концепции селекторов, но прям не оч, что при использовании приходится эту логику дублировать

suggestion(non-blocking): По-хорошему сделать так, чтобы эта логика определялась
на уровне taskModel, а логика страницы лишь композировала бы все это и оставалась тонкой при этом (как в оригинале)

[azinit]

@niyazm524 мб ты тут что подскажешь

[azinit]

nitpick(non-blocking): Вот прям вообще некрит - но если бы получилось эту логику модели данных вынести в отдельный model.ts файл, где велась бы работа с vuex / событиями и прочим - прям было бы топчик

thoughts(non-blocking): Но мы у себя в TodoApp так не делали, так что рили некрит)

UPD: Мб @niyazm524 что подскажет

[azinit]

thoughts(non-blocking): Поначалу показалось "Ух жирная моделька, прям нарезать надо"

Но потом вчитавшись стало ясно - что там все то минимально необходимое + с обвязками вокруг vuex

Мб @niyazm524 подскажет как можно упростить модельку сущности

[azinit]

thoughts(non-blocking): Кста хз насколько так принято в мире vue
Но это изначальное деление по "сабмоделям" с реэкспортом ключевых из effector изначально пошло)

Т.е. мб это даже избыточно, и хватило бы обычных реэкспортов

А с другой стороны, классно что под это удалось подвязать префиксацию нейминга 👍

@niyazm524, опять же, поправь если ошибаемся

[azinit]

thoughts(non-blocking): В целом ощущение, что в страницах все равно слишком много логики остается

Возможно из-за того что "сливаются" импорты и отдельно сетапинг юнитов для темплейта

[azinit]

question(non-blocking): Чутка смутил момент с неймспейсами
У нас тип vuex тоже глобальный стор, где напрямую к каждому "министору" надо обращаться по имени?)
(а не по экспортируемому юниту, как в эффекторе)

thoughts(non-blocking): Энивей, кажется, что такое все равно как будто можно решать геттерами/селекторами но мб глаз замылен и это ОК на самом деле выглядит

[niyazm524]

Для Options API были придуманы хелперы типа mapGetters, но в Vuex 4 это считается нормой

[azinit]

И потихоньку вопросы по Vue

question: @niyazm524 ОК ли делать так композицию разметки и логики в мире Vue? Или можно лучше/проще/по-другому?

[niyazm524]

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

Другое дело, что лучше было бы сделать что-то вроде хука, при вызове функции которой делался бы router.replace на страницу { name: 'Error404', path: route.fullPath }, насколько помню, так должно работать, и весьма незаметно для пользователя.

[EliseyMartynov]

@niyazm524 так было в "оригинальном" ToDo example у FS. Поэтому так и написано. А так да - это классика делать error page :)

[azinit]

question: @niyazm524 Знаешь как проблему с типами полечить?

[niyazm524]

Я ещё не работал с script setup, на прод такое не допустят пока :(

[azinit]

на прод такое не допустят пока :(

@niyazm524 Т.е. это далеко от RealWorldVueProject на данный момент?)

[niyazm524]

Не то чтобы критично, просто некоторое API не обкатано ещё, а так, как пример архитектуры, думаю, весьма хорошо. К RealWorldVueProject приблизило бы использование error-pages. А так, даже использование Vite это уже ред флаг для коммерческого проекта, по крайней мере пока

[azinit]

thoughts: Прям флешбеки от redux-toolkit...

[niyazm524]

Когнитивная сложность _/‾

[azinit]

@niyazm524 А как упростить?

[azinit]

UPD: А, увидел ниже - т.е. предлагаешь полагаясь на те статьи модель данных переписать? (СТМ обработку)

[niyazm524]

На самом деле не призываю, мне кажется, это больше вкусовщина — кому как нравится
Но предлагать — да, предлагаю)

[azinit]

Итого

В целом кажется все оч даже хорошо, все вещи что отписал - скорее ToImprove (даже критов не нашлось)

Остались вопросы разве что по специфике Vue, но думаю @niyazm524 ответит

[azinit]

Дождемся вердикта от @niyazm524, влития правок - и думаю можно будет организовывать сэндбокс и добавление в общий список примеров)

[azinit]

@niyazm524 глянь тоже пож проект в целом)
Мб еще за что глаз зацепится

https://github.dev/EliseyMartynov/fs-vue

[niyazm524]

Хотел написать о Vuex, про который Илья выразился "как в эффекторе"

Учитывая, что в Vue 3 reactivity api вынесли в независимый модуль, стало возможным писать сторы, обходясь только reactive, computed и методами. Если плагины для Vuex не нужны, а отладка не страшное слово, то я вижу это вполне себе выходом из такого мозаичного кода.

Конечно, это всё вкусовщина, но я, признаться, был разочарован, когда они ушли с options API к Composition, не сделав такой ход в Vuex (понятно, что совместимость, но всё же)

Приведу несколько ссылок, описывающих этот метод раз два

[niyazm524]

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

[azinit]

@niyazm524 Спасибо за экспертное ревью! 🚀

[EliseyMartynov]

@niyazm524 Мне @azinit сказал, что ты знаешь за бэсикс React'а. Не кажется ли, что подход с провайд инжектами очень плохо будет скейлится? Все-таки Feature Sliced подразумевает, что мы будем писать долгоживущий проект (а значит немаленький). Как аналогию хотел бы привести:

по ощущениям это как приложение на редакс тулките перенести на контексты (концепции похожи оч сильно у vuex и rtk && провайд/инжекты и context)

И мое мнение в этом плане, что если мы будем писать средний+ проект на контекстах (рассуждаю как Реактер сейчас), то это очень страшно даже представить)
Просто насколько я слышал от ребят из Vue чатика (давным давно еще, когда только появлялся провайд/инжект) - это именно очень похоже с концептом React Context.

[niyazm524]

Да, ты прав, provide/inject это по сути тот же useContext

Возможно, не полностью понял вопрос, но в любом случае, какая бы архитектура не была, часто прибегать к использованию provide/inject = похоронить проект заживо.
Я считаю, что их использование не должно выходить за рамки разработки плагинов и хуков для них, то есть, чтобы provide был только на root уровне, за исключением случаев, когда ты полностью осознаешь, что делаешь.

[EliseyMartynov]

@niyazm524 Понял. Из-за недостаточности времени не могу глубоко вникнуть в паттерн без Vuex.
Когда мы выбираем Feature Sliced архитектуру, значит подразумеваем достаточно большой проект => исходя из моего поверхностного представления, довольно страшно писать без дебаг тулинга. А как ты выше и написал, с отладкой есть вопросы при таком подходе.

[EliseyMartynov]

@niyazm524 еще поделюсь небольшой болью, с которой столкнулся, когда писал на Вью. В Реакте мы можем передать пропом все, что угодно - даже компонент (или даже render-функцию, что почти одно и то же). Во Вью так делать нельзя, если говорим про классику SFC - и если хотим передать компонент в дочерний, то нам нужно делать слот (на сколько я понимаю, если захотим вывернуться с кастомными рендер функциями, то может так и можно сделать, но выглядит это ужасно).
The problem:

• вот у нас есть Ant в примере, и у него есть слот actions в компоненте Card. Этот Card у меня непосредственно обернут в entitie, и чтобы в entitie мне передать слот actions из уровня page, мне в моей entitie дополнительно нужно создавать слот actions.
• таким образом я передаю слот actions из уровня page, и описываю его еще на уровне entitie.
• почему так больно? Решается ли это чем-то?

[niyazm524]

Да, сам не раз сталкивался с подобным, был даже кейс, когда воспользоваться слотом было невозможно, и пришлось писать компонент-обёртку (props{component,renderSlots,renderProps} и setup возвращающий функцию)
Не без доли горести будет сказано, но нормального и удобного способа передачи и наследования слотов я не нашёл :/

[kaguya3222]

@niyazm524 @EliseyMartynov Привет) Я из fs community, интересуюсь связкой vue + fs.

У меня вопрос касательно концепции отделения БЛ от ui логики. Большинство проектов на вью (да и не только вью) миксуют ее прямо в компонентах. Какие у нас есть в целом инструменты для отделения? Как я понял в этом проекте как раз таки vuex и его модули идут как контейнеры для бизнес логики.

Меня немного смущает идея использования стейт менеджера как контейнера для бизнес логики, т.к тот же vuex пораждает глобальный стейт. Не странно ли делать глобальный стейт для какой нибудь формы, которая всего на одной странице используется? Условно говоря, мы уйдем с этой страницы, а данные этой формы во vuex останутся лежать, нам нужно постоянно следить за тем что бы сбрасывать состояние модуля во vuex. Не проблема ли это?

[kaguya3222]

@niyazm524 Идея с хуками звучит хорошо, но вот для меня например это проблема, т.к проект на Nuxt2, без возможности миграции на Vue 3, т.к по словам кор тимы, ssr для vue 3, с которым пойдешь уверенно в прод - не готов. И мне бы хотелось юзать подход, который для vue 2 подойдет.

Я вижу такие варианты:

1. миксины (худший наверное)
2. vuex (имеет те проблемы, которые обсудили выше, но хорошо подходит для shared стейта)
3. Взять что то по типу: https://github.com/vuejs/composition-api, в случае, если хуки все же лучший вариант.
4. Renderless компоненты, как компоненты-контейнеры которые поставляют модель данных локального стейта? в целях разделении ui логики и бизнес логики.

Что бы было понятно о чем я говорю, локальный стейт для меня - стейт, который пропадает, как только компонент, использующий его, демонтируется.

То есть мы можем юзать vuex/pinia/любой другой СТМ для описания модели, которая подходит под shared state, например: entities/user/model, но ту же модель данных для локального стейта можно определять внутри renderless компонента:

**/model/index.vue

export default {
   computed: {
     isLoading() { ... } ,
   },
  methods: {
     doSomeLogic() { ... }
  },
  render() {
     return this.$scopedSlots.default({
        doSomeLogic,
        isLoading
     })
  }
}

**/ui/index.vue

<template>
  <Model v-slot="{ doSomeLogic, isLoading }">
     <span v-if="isLoading>I'm loading</span>
     <button @click="doSomeLogic">Click</button>
  </Model>
</template>

Renderless компоненты в принципе являются хорошим решением, когда у тебя есть разные представления, но одна логика. Я бы предложил их использовать для кейсов, когда есть слайс, в котором есть какая то БЛ, но она вообще никак не подходит под shared стейт, но миксовать ее с ui логикой в одном компоненте не хочется.

[niyazm524]

Хах, да, согласен, миксины это только если тебе не заплатили. Renderless компоненты действительно выглядят очень выигрышно на фоне всего остального, я использовал этот подход в достаточно редких случаях, так что не могу сказать, что там нет никаких проблем.
Если всё нормально, то даже через метод исключения можно сказать, что это лучший вариант.
Плагин хуков выглядит, как очень грамотный, но всё же костыль, а создавать инстанс модуля vuex и привязывать его к жизненному циклу компонента (видел подобное) звучит как дичь, да и время онбординга станет 📈

[kaguya3222]

@niyazm524 Спасибо за фидбек по поводу renderless компонентов как контейнеров с логикой.

Продолжу тут тему про стейт менеджеры и их роль как контейнеров для бизнес логики в методологии. Я уже ни раз говорил, и тут, и в группе, и в личке у @azinit, что мне не нравится описывать БЛ каждого модуля в стейт менеджере. Возможно, потому что я за свой маленький опыт использовал только стейт менеджеры, которые реализуют FLUX архитектуру (Vuex например), и они мне всегда казались местом, куда должен попадать только Application state (далее - AS) . То есть условный список книг, который есть только на одной странице, не должен попадать в AS. И в последние дни я как раз изучаю тему с управлением состояния, и я наткнулся на интересное видео Ильи Климова. В нем как раз обсуждаются противоречивые подходы в работе с СТМ flux-like архитектуры, или же просто "как не надо делать". И как раз на этом тайм коде начинается речь про это (но желательно с нуля конечно глянуть). И я в целом с Ильей согласен.

Я двумя руками за то, что бы выносить модель какого-нибудь 'entities/user` в СТМ, т.к это чистый AS. Но модель списка книг выносить в стору, когда она используется только в одном месте - мне понять сложно такое.

Поэтому и меня интересуют подходы, как можно отделить БЛ от UI логики, не записывая БЛ в СТМ.

[azinit]

Поэтому и меня интересуют подходы, как можно отделить БЛ от UI логики, не записывая БЛ в СТМ.

Советую как раз прочитать нашумевшую статью про отделение UI и логики от @Kelin2025
(там пример на реакт, но общая суть применима и для Vue по идее)

UPD: Думаю, можно это у самого Ильи подробнее в чате спросить в контексте Вью)
(даже просто вне контекста FSD)

https://kelin2code-mu.vercel.app/posts/stop-writing-logic-in-components

[azinit]

БЛ, но это не лучший вариант, поскольку иногда всё равно приходится миксовать.
Может быть, выносить её в те же хуки..
@azinit, что думаешь?

Мы с @niyazm524 тоже не раз обсуждали как лучше отделять это в мире Вью - и увы там не так много способов, особенно если речь не про Vue3

Тут кажется действительно почти единственное что остается делать (особенно в контексте FSD) - держать компоненты максимально тупыми (особенно если речь про shared/entities)
А всю логику выстраивать в верхних слоях (даже если придется порой от этого марать компоненты виджетов/страниц)

СТМ тут лучше поможет, но опять же - проблема бойлерплейта и переиспользования от этого не сильно меньше станет