Как стать автором
Обновить

Архитектура фронтенд-приложений на React. (Нам не нужен FSD)

Уровень сложностиСредний
Время на прочтение9 мин
Количество просмотров15K
Всего голосов 15: ↑14 и ↓1+13
Комментарии192

Комментарии 192

FSD это просто структура папок а не архитектура

А здесь у автора что? Не тоже самое ли?

И если уж на то пошло, это не просто структура папок, это слои с правилами взаимодействия друг с другом! Что еще в твоем понимании архитектура?

В данном контексте архитектура - это определенный "фреймворк" того как мы организуем код в проекте. Это не только про структуру папок, но и про их содержание и связи.

Вот из-за такого понимания fsd у многих разработчиков автор, я думаю, и решил использовать что-то проще. Вникать слишком долго, а при первом просмотре кажется, что это просто структура папок.
Даже в этой статье есть слои, как в fsd. Вам не кажется, что это не структура папок?

Если вникнуть ещё глубже, FSD может не понравиться

я не говорил что fsd идеален. Может нравиться может нет. Мне раньше нравился к примеру, но сейчас после релиза 2.1 перестал. Мой тезис был "это не просто структура папок". К чему это нравится, не нравится не очень понимаю.

Так чем fsd-то хорош? Не масштабируемая штука абсолютно. А если что-то не масштабируется, толку от этого нет никакого, имхо. Вот есть у тебя папка фичей со слайсами. Она же будет бесконечно раздуваться по мере увеличения проекта из-за ограничений вложенности. (Да, я понимаю, что в сегментах может быть что угодно. Но зачем тогда оно вообще надо). Мне вот понравилась идея фрактальной структуры. Если какая-то часть проекта большая, там будет много папок и файлов. И всё это будет инкапсулировано в одном месте, а не разнесено по разным папкам.

Да будет много папок, но зато удобней переиспользовать и опять же fsd не говорит сколько нам кода в папке писать. Ну есть у нас форма авторизации в 4 разных вариантах просто ложим в одну фитчу и через public API отдаём. Мне кажется классическая архитектура проектов ещё менее масштабируема.

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

Удобнее? Это как? Удобнее чем это?) Вы просто прочитайте что что вы написали) Ложим в фичу, через public api отдаем, джину лампу трем. Как будто реактивный двигатель для Союз-1 разрабатываете. И да, а с чего это вдруг в фичу? Почему не в widgets? :D Вопрос смешной да?) Такого вопроса вообще априори не должно возникать.

import { LoginForm } from 'components/LoginForm';

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

Мне кажется классическая архитектура проектов ещё менее масштабируема.

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

Удобней чем без fsd. Если сможете скинуть документацию вашей архитектуры можем с ней сравнивать. Вам "кажется" лучше всей командой делать проекты по принципу "я так чуствую"?)

Ответ на ваш вопрос:

Features

Этот слой предназначен для основных взаимодействий в вашем приложении, действий, которые важны вашим пользователям. Эти взаимодействия часто затрагивают бизнес-сущности, поскольку сущности — это то, о чём ваше приложение https://feature-sliced.design/ru/docs/reference/layers

Удобней чем без fsd

???

Если сможете скинуть документацию вашей архитектуры можем с ней сравнивать

У нее нет документации, она интуитивно понятная. Если вам не понятно назначение файлов и папок из этих примеров, то у меня для вас плохие новости. Я скинул вам конкретные примеры структуры, пожалуйста. сравнивайте. Просто пройдитесь комментам тут полно примеров структуры файлов и папок. Они говорят сами за себя.

Вам "кажется" лучше всей командой делать проекты по принципу "я так чуствую"?)

Нет. По принципу здравого смысла. Один из них это делать жизнь проще, а не делать жизнь сложнее.

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

Аххах. Я читал эти "определения" ко всем "слоям". Это просто маразм. И ваш комментарий не раскрыл, почему LoginForm должен лежать именно в features, а не в widgets или в entites. Более того, у вас не найдется утвердительного ответа, ибо этого не знает никто.

Слой features предназначен для взаимодействий то есть для кнопок, инпутов, форм и т.д. Это знаю минимум я потому что прочитал документацию и теперь и вы потому что прочитали комментарий)

не в entities лежит потому что это действие а не отображение данных

не в widget потому что это обособленная часть функционала которую можно переиспользовать не нуждающаяся в композиции с entities

про какой "здравый смысл" вы говорите? Если мой здравый смысл говорит использовать fsd я не здоров?) Вы знаете кажется вы единственный знаете как надо, а люди использующих и продвигающих fsd шизики выдумавшие сами себе проблемы чтобы больше работать)

не в entities лежит потому что это действие а не отображение данных

Т.е. форма не отображает данные?) Submit формы это не действие?) А поля формы, это что, не данные которые улетят на сервер?)

не в widget потому что это обособленная часть функционала которую можно переиспользовать не нуждающаяся в композиции с entities

Что?)))

про какой "здравый смысл" вы говорите? Если мой здравый смысл говорит использовать fsd я не здоров?) 

Ну, скажем так, ваши вкусы специфичны)

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

Да нет, много кто знает как надо) Просто вам скучно использовать простые принципы и решения и вам создаете себе проблемы, а потом пытаетесь их решать)

Кажется вы решили решили что fsd плох так и не разобравшись в нем)

Т.е. форма не отображает данные?) Submit формы это не действие?) А поля формы, это что, не данные которые улетят на сервер?)

Форма заставляет пользователя что то сделать
entity и feature это как существительное и глагол
И вся форма будет feature вместе с jsx стилями и тд.

не в widget потому что это обособленная часть функционала которую можно переиспользовать не нуждающаяся в композиции с entities

Что?

слой widget обычно используют как композиционный слой для feature и entity. К примеру в widget посте лайк будет feature и через prop прокидываться в слот в сам компонент поста который entity

Да нет, много кто знает как надо) Просто вам скучно использовать простые принципы и решения и вам создаете себе проблемы, а потом пытаетесь их решать)

Ну с таким подходом и реакт не нужен вовсе

Перечитайте свой коммент и осознайте, что это абсурд, вы пытаетесь ответить на вопрос почему компонент LoginForm  нужно положить в features, а не в widgets или в entities, а почему бы и не в shared? Сама эта ситуация уже маразм.

В классической архитектуре такого в принципе быть не может. Если компонент будет использовать в разных местах, то это src/components, в остальных случаях он находится в локальной папке components например страницы, которая для удобства может быть разбита на компоненты. Если ты добавляешь глобальное состояние, оно без вариантов идет в src/globalState, если локально, то оно лежит рядом с компонентом и называется state.ts .

Разницу улавливаете, в одном случае все предельно просто и интуитивно понятно, для всех и всегда. А в другом случае взрыв мозга

Форма заставляет пользователя что то сделатьentity и feature это как существительное и глаголИ вся форма будет feature вместе с jsx стилями и тд.

И да, это не ответ на вопрос. Луна в Сатурне потому что небо зеленое, чай уплыл, а пыль погасла.

слой widget обычно используют как композиционный слой для feature и entity. К примеру в widget посте лайк будет feature и через prop прокидываться в слот в сам компонент поста который entity

Омг, ну это же просто дичь. FSD доводит элементарные вещи до абсурда.

не в shared потому что это бизнес логика нашего приложения. если вынести её в другое приложение она потеряет смысл.

Вы же предлагаете просто в components всё кидать и говорите что так проще. Причем проще потому что лично вам интуитивно понятней) Ваша классическая архитектура как вы её описали только у вас в голове. Я вот такой как у вас реализации вообще не встречал с components в страницах. Самое плохое в этом всём что работая в команде надо руководствоваться хоть какой то архитектурой и документацией. Руководствуясь здравым смыслом у вас крокозябра получитсья.

опять какие то поля, луны в сатурнах. Если вы не понимаете вы спросите что не понимаете, а лучше перечитайте доку доклад какой-нибудь послушайте.

Я вот такой как у вас реализации вообще не встречал с components в страницах.

Чем меньше опыта(в разрезе кол-ва проектов), тем меньше шанс что вы видели тот или иной подход.

Самое плохое в этом всём что работая в команде надо руководствоваться хоть какой то архитектурой и документацией

Есть вещи не нуждающиеся в документации. Ибо они и так предельно ясны.

function sum(a: number, b: number) {
  retrun a + b;
}

Это нуждается в документации? Нет, тут всё говорит за себя.
Более того, никто не запрещает на классику написать документацию. Это супер быстро и супер просто.
pages - для страниц
layuots - для лейтаутов
components - для общих компонентов
вложенная папка components - для локальных компонентов, которые необходимы исключительно этой странице/компоненту/лейауту и т.п.

Ну и так далее. Всё же элементарно. А вы опять какую-то смуту наводите, якобы тут что-то сложное, не понятное, бардак и т.п. Ну бред же.

Руководствуясь здравым смыслом у вас крокозябра получитсья.

Ахах. Ясно.

Если вы не понимаете вы спросите что не понимаете, а лучше перечитайте доку доклад какой-нибудь послушайте.

Так вы называйте вещи конкретно своими именами, не называйте стакан объектом, не называйте стул объектом по крупнее. Просто говорите стакан и стул.

я вам про одно вы мне про другое. Где я говорил что в каждый проект надо добавлять fsd?

Где вы нашли что я был против папок под глобальный Стейт, лэйауты и тд?

"Чем меньше опыта(в разрезе кол-ва проектов), тем меньше шанс что вы видели тот или иной подход"

трава зеленая. небо синее. Если вы пытались так завуалировать что у меня не хватает опыта то вот ответ.

Вы вот не трогали fsd получается у вас меньше опыта?

какие стаканы и стулья?))) где вы что не поняли из того что я говорил? Хватит метафор пожалуйста

Вы вот не трогали fsd получается у вас меньше опыта?

Как раз таки наоборот) Из-за опыта мне достаточно провести мысленный эксперимент чтобы увидеть сразу к чему приведет использование FSD или использование Effector и т.п. Чтобы понять, оно будет лучше чем Х или нет. Ну и касаемо самом FSD я видел его на 2х проектах в которых приходилось вносить доработки, это конечно было фрик шоу) Вполне ожидаемое фрик шоу, другого я и не ждал, ибо и так все понятно если просто взглянуть на эту мертворожденную концепцию)
Я же не извращенец или фанатик, я ленивый человек и если что-то добавляет удобства, я обязательно это использую. Если бы FSD приносил удобство по сравнению с классикой, я бы сразу же перевел все свои проекты на FSD и новые начинал с FSD. Или же если бы redux был удобнее чем mobx, я бы сразу выкинул mobx и перешел на redux. И т.п.

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

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

У меня в отличии от вас позиция не предвзятая и не фанатичная, а просто вытекает из фактов и простых принципов. Всё сугубо ради удобства и выгоды с точки зрения трудозатрат. Зачем мне на проекте применять подход Y, если с ним я в 2 раза больше времени трачу на реализацию таких же задач, как тратил бы если бы использовал подход X.

Например в 2016 году я считал что typescript это оверхед, с 2012 по 2016 ни разу TS не юзал, но в уже 2017 я пересмотрел свою позицию и с тех пор typescript only. До появления async/await в Node.js ноду я тоже не рассматривал в серьез как инструмент для написания бэка. Но JS эволюционировал, стал значительно круче и вуаля, в 2018 я уже писал бэкенд на Node.js с удовольствием.

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

С чего классическая архитектура менее масштабируемая? Может быть вы понимаете что-то другое под этим словом. Вам никто не запрещает создавать компоненты в компонентах, ну и так далее, в "классической" архитектуре.

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

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

fsd заставляет оперировать бизнес сущностями что помогает проекту масштабироваться и переиспользовать код

Что значит оперировать бизнес-сущностями? Наличие папки "entities"? И как это поможет, если этих бизнес-сущностей тысячи

Про масштабирование и пере-использование я описал выше

тысяча бизнес сущностей это где столько?)
Да поможет так как обычно они валяются где то внутри components в лучшем случае, а чаще просто размазаны по всем компонентам. Когда они выделяются сразу становится проще понимать что где лежит и что от чего зависит.
Минимум "тысяча" бизнес сущностей не будут и зависеть от друг друга и мы будем это понимать потому что это заложено в архитектуру. От чего что зависит в папке components поймешь только пересчитав весь код

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

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

Пока все ваши мифические доводы крутятся в парадигме из разряда: земля плоская, потому что я стою в поле, смотрю вперед и не вижу что это шар. А вот если бы вы использовали fsd, то тогда вы бы всё увидели)

> Может уже пора снять розовые очки наконец? В реальных проектах всегда есть сложные компоненты/сущности/суслики/кролики/называйте как угодно, которые зависят от других, в этом весь смысл компонентного подхода.
Сложить лапки и плакать предлагаете?)

> Вы прикрываетесь абстрактными сущностями, избегая конкретики, потому что как только дело доходит до конкретных примеров, то сразу все становится элементарно и вся мифическая сложность сразу улетучивается
Я не понимаю вас. Вам пример из жизни привести? У меня нет кода который я бы мог скинуть в общий доступ) Есть много примеров в документации fsd. Я ничего не избегаю. У меня нет цели вас обмануть. С fsd правда может быть удобней делать проект.

> Пока все ваши мифические доводы крутятся в парадигме из разряда: земля плоская, потому что я стою в поле, смотрю вперед и не вижу что это шар. А вот если бы вы использовали fsd, то тогда вы бы всё увидели)

Ну если вы встречали таких проектов где хотелось бы добавить правил на архитектуру то видимо вам правда не нужен fsd сейчас)

Сложить лапки и плакать предлагаете?)

Называть вещи своими именами и принять тот факт, что реально сложные вещи буду при любом раскладе сложными, никакая fsd/классика и т.п. этого не облегчит.
И не надо тут пытаться умножать сложность простых вещей в разы, называя их абстрактными сущностями. Таким образом якобы только у вас(тех кто манипулирует на этом) такие сложности что ппц, а все остальные максимум это цвет кнопок меняют и не понимают истинных "проблем".

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

Я не понимаю вас. Вам пример из жизни привести? У меня нет кода который я бы мог скинуть в общий доступ) Есть много примеров в документации fsd. Я ничего не избегаю. У меня нет цели вас обмануть. С fsd правда может быть удобней делать проект.

Классика. Типичная "удобная" отмазка. Я не могу, я не я, посмотрите на примеры. Эти примеры не дают никакого ответа на вопрос, почему конкретно fsd будет лучше классики. А знаете почему? По тому что же, почему и вы не можете конкретного примера предоставить.

Ну если вы встречали таких проектов где хотелось бы добавить правил на архитектуру то видимо вам правда не нужен fsd сейчас)

Вы прикалываетесь? Вы опять сравниваете fsd с какой-то выдуманной плохой архитектурой, на фоне которой fsd якобы лучше. Речь идёт о совершенно конкретной архитектуре здорового человека(пример базовой структуры есть в комментах) и FSD. Вы понимаете что у вас нет ровно ни одного реального аргумента, подтвержденного кодом и/или структурой папок и файлов. Всё на что вас хватает это фантазии каких-то мнимых кейсах где якобы FSD лучше.

Очень сложно понять плюсы FSD, если не читал документацию и не пробовал использовать. Я не смогу вам доказать, что все эти абстракции вполне конкретные и помогают.
Во-первых, я сравниваю FSD с выдуманной архитектурой, а вы — с той, что у вас в голове, «здравым смыслом». Документации на вашу архитектуру нет, поэтому с ней сравнить никак не получится.
Во-вторых, вы просто отрицаете то, что я говорю, даже не понимая, о чем я говорю (ответ про public API был просто «нет»). Покажите мне код, где все понятно — это вам заклинание какое-то? Зайдите в документацию, посмотрите доклады, сделайте пару проектов — потом любой проект на FSD станет простым и понятным.
Сейчас наш диалог в каждой ветке строится так: «FSD структура папок мне и так все понятно! FSD нужен для сложных проектов и имеет вот такие плюсы… Мне вот в этом примере все понятно — вы некомпетентны» конец потому что вы просто перешли на личности забыв про тему спора. Если так хотите, готов провести вам вводную лекцию с примерами, но только за деньги.

Я не смогу вам доказать, что все эти абстракции вполне конкретные и помогают.

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

Мой полет мыслей:
1) Форма входа на сайт содержащая поля логина и пароля - это конкретика. И сразу все легко да?

2) Задача, добавить на эту форму входа капчу - это конкретика, тоже сразу все понятно.


А теперь ваш полет мыслей:
1) Слой авторизации. Что конкретно в него входит, что именно имеется ввиду? Почему Х в него входит, а Y не входит?

2) Задача, добавить капчу в слое авторизации. Куда конкретно ее добавить? Только на вход? Только на регистрацию? Или туда и туда?


Поэтому то, что вы говорите я не понимаю и другие тоже, вы скрываете конкретику намеренно. Только вы знаете что вы подразумеваете по слоем авторизации или под слоем товара например. Больше никто. Когда называешь вещи своими именами, то всё для всех становится предельно понятно и просто с первого раза. Не надо 10 раз задавать уточняющие вопросы и гадать на кофейной гуще, а что же конкретно он имеет ввиду.

Нет такого слоя, как авторизация. Возможно, вы имели в виду слайс. Если вы добавляете форму, кнопку или что-то для взаимодействия с пользователем (тут надо понимать, какова цель компонента), то это в слое feature. В будущем, по этой же логике, когда вы захотите использовать или изменить эту форму, вы будете знать, что она в feature. И что самое приятное — другие люди, знакомые с FSD, сразу поймут что она точно там. Капча — это тоже очевидная feature. Выносить её в отдельный слайс бессмысленно, если она не переиспользуется в другом месте.
То есть если задача “добавить капчу в форму авторизации”, я на случайном FSD проекте, не зная о нём ничего заранее, захожу в папку feature/AuthForm, смотрю там index.ts и вижу, что экспортирует слайс (потому что public API). Дальше иду в компонент формы авторизации и добавляю капчу. Все задача выполнена.
В вашем случае я, скорее всего, иду на страницу с авторизацией (я предположил, что у вас есть папка pages), там смотрю код и пытаюсь понять, где авторизация. Найдя что-то типа AuthForm, иду внутрь и добавляю капчу. Звучит не сложно. Но в FSD я понимаю, что в слое feature я завишу только от слоя entity и shared. А используется авторизация в widget или page. И используется не какой-то файл из feature/AuthForm, а то, что прописано в index.ts.
В папке components понять, от чего зависит то или иное решение, можно только идя от page вниз по коду. Да, приходится каждый раз задаваться вопросом “что куда ложить” во время создания. Это такой налог. Ещё налог — это то, что порог входа увеличивается на проект. Поэтому в приведённых вами примерах FSD будет очень сильно мешать, и поэтому же большинство его кастомят.

Как правильно подметил @clerik_r

Вы можете дать конкретный пример большого проекта, сделанного по FSD? Чтобы было конкретно видно, в чем преимущества данной структуры папок. Чтобы мы говорили не о чем-то абстрактном, а по существу.

А как классика этому мешает?

@NikitaLikosovтак как классика этому мешает?

что помогает проекту масштабироваться и переиспользовать код

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

возможно вам понравится версия 2.1. Я пробовал на реальных проектах. С 3 проекта научился и стало прям удобно и понятно.

возможно вам понравится версия 2.1

Это я уже видел. Да, оно стало лучше чем было. Это факт.

Но это всё равно полумера и все равно FSD кривая мертворожденная история. Он сливает по всем фронтам классике. Хоть убей, не понимаю стремление некоторых людей собственноручно заставлять себя страдать.

С 3 проекта научился и стало прям удобно и понятно.

На счет удобно и понятно это вы конечно преувеличиваете и лукавите))) Такие тезисы не применимы к fsd.

А вот ключевое тут: с 3его проекта.
В стандартной классической архитектуре вам бы сразу, сходу все было понятно, ведь ее фишка в том что она интуитивно понятна и максимально логичная. всегда и для всех. А не только для тех, кто посветил ей пару тысяч часов и пару десятков проектов, участвовал в паре десятков созвонов где обсуждали что есть wdgets, что есть features, что есть shared (спойлер: и в итоге все равно никто не понял что есть что).

Обычно, когда говорят о стандартной классической архитектуре, все представляют себе разные вещи. Что такое fsd можно просто прочитать у них в доке. Да и мне кажется сложно утверждать, что слои и public api это не удобно и не понятно. С тем что текущий вариант разделения по 6 слоям часто пораждает больше вопросов чем ответов я согласен.

Именно поэтому мы и предлагаем наш подход. У FSD высокий порог вхождения, а также есть споры по поводу ее эффективности на дистанции, но сама идея создания общей договоренности о том, как строить проекты, абсолютно правильная. Говоря о классической архитектуре, каждый будет понимать свое и делать все по своему. И это не предположение, а личный опыт работы с командами. Насколько это проблема для ваших задач - решать вам. Мы же убедились в эффективности наличии общего фреймворка.

Также важно понимать, что те правила, которые мы предлагаем - это реакция на определенные боли с точки зрения Development Experience, с которыми мы сталкивались на протяжении многих лет работы, и которые с большой долей вероятности будут стрелять в "классической" архитектуре.

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

Я постарался подробно описать это в своей статье, но если что-то осталось непонятным - это можно спросить или прокомментировать.

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

Какие конкретно боли? И почему это боли? Каким образом они стреляют?

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

Один раз зайдя на проект и увидел структуру файлов и папок в классике сразу всем становится все понятно. Что, как, зачем и почему. Ключевые слова: интуитивно понятная и логичная. Что конкретно тут может быть не понятно?

каждый будет понимать свое и делать все по своему

С чего вы это решили? И каким это образом имея такую структуру кто-то вдруг будет ее понимать как-то по особенному и делать по своему, вопрос как именно остается открытым. Тут все названо не абстрактно, а вполне конкретно. Компоненты, страницы, глобальной состояние, маршруты, конфиг и т.п. Как можно трактовать страницы по разному? Как можно трактовать компоненты по разному?
С таким же успехом можно сказать: Архитектура которую вы предлагаете плохая. И далее пояснение вашей логики Почему плохая? А просто потому что я так написал, мне так кажется. Или стандартный фейковых аргумент, а исходя из моего опыта такие архитектуры превращаются в помойку и т.п.

В случае с FSD основная идея как раз в четком определении границ и связей между фичами, слоями и модулями. Это не просто про папки и их содержимое, а про продуманное разделение ответственности и упрощение поддержки проекта.

В случае с FSD основная идея как раз в четком определении границ и связей между фичами, слоями и модулями.

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

Это не просто про папки и их содержимое, а про продуманное разделение ответственности и упрощение поддержки проекта.

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

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

Где в вашем примере мне сделать переиспользуемую на разных страницах форму зависимую от самописных ui компонентов? Кажется папка components быстро превратится в помойку спагети кода. Если проект маленький то я согласен что лучше вашего примера не придумать

Где в вашем примере мне сделать переиспользуемую на разных страницах форму зависимую от самописных ui компонентов?

src/components разумеется

Кажется папка components быстро превратится в помойку спагети кода.

Если компонентов полно, то да(если делать всё в тупую). И нет разницы, будет ли она называться shared или widgets или animals.

Открою секрет, например папка components может быть дополнительно структурирована по типу/назначению компонентов. Например:

src/
  components/
    formFields/
      Input/...
      Textarea/...
      Select/...
    anyOther/
      Component1/...
      Component2/...

Уже не похоже на помойку да? И это касается любых папок, это все и так очевидно и интуитивно понятно, ограничений нет, от слова никаких.

Если проект маленький то я согласен что лучше вашего примера не придумать

Вообще нет разницы какой размер, он работает шикарно на всех.

мне кажется тоже самое если ввести слои будет удобней. Допустим оставить как у автора статьи 3 слоя (положить их вашу папку components) и сразу понятно что за что отвечает и что с чем связанно. Добавить public api из fsd ещё удобней, а там уже пару шагов до самого fsd)

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

и сразу понятно что за что отвечает и что с чем связанно

А так что, не понятно?))

src/
  components/
    SmartForm/
      index.tsx // Сам компонент
      state.ts // Локальное состояние компонента (если нужно)
      styles.module.scss // Стили компонента

Вот смотрю и вообще не понимаю что тут к чему)) Вообще не понятно)) Если бы не подсказки в виде комментариев никогда бы не догадался с первого раза)

если ввести слои будет удобней

Правда?)) pages, layouts, components, globalState и т.д. и т.п. это так, шутка какая-то. А если добавить правило - каждый файл не более 10 строк, то будет ещё удобнее, а если добавить правило что в каждой папке должно быть не менее 4х папок, то будет ещё удобнее. Мы уже почти достигли идеала, круто. Везде есть мера и здравый смысл, не надо выходить за их пределы.

Опять же, если эти правила только добавят сложности, то оно и не надо

Именно, они только добавят сложности. И да, не надо этого. Только для прям сложных компонентов можно добавлять дополнительные деления, ибо для них это логично и интуитивно понятно.

Добавить public api из fsd ещё удобней

Эмммм, нет)

а там уже пару шагов до самого fsd)

Упаси)

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

Это называется выдавать желаемое за действительное.

Можно сказать так(это не мои мысли, а выдумка для иллюстрации манипуляции через слова об опыте):

  • Из личного опыта я вижу, что писать аналог Figma на голом языке brainfuck с транспиляцией в JS это приятно, удобно и помогает легко и быстро ориентироваться.

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

Ну и так далее.

так это вы просто не хотите привыкать к новому и выдаете желаемое за действительное! Обоюдоострый меч)

Описанные вами папки это не слои в понимании fsd. Ну и если вы считаете что слои имеют столько же смысла что правило добавлять в папку 4 папки то я не знаю что ответить)

про public API. да!

так это вы просто не хотите привыкать к новому

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

выдаете желаемое за действительное!

Я привожу конкретные примеры с конкретной структурой папок и файлов. Их может любой сторонний наблюдатель посмотреть и сравнить с тем, что предлагает fsd.
А вы говорите о каком-то якобы опыте и о том, что якобы этот опыт показал что fsd это якобы удобно. Т.е. то, что нельзя проверить и объективно оценить.

Описанные вами папки это не слои в понимании fsd

Ахахах. Оперировать такими понятиями как "в понимании fsd" это абсурд высшей степени. Типо это эталон, по которому мы сверяемся, что в его понимании подпадает по ту или иную трактовку, а что нет.

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

А что по вашему описанные мною файлы и папки такое? Набор рандомных букв? Наверное не понятно что в них должно лежать да?)

Ну и если вы считаете что слои имеют столько же смысла что правило добавлять в папку 4 папки то я не знаю что ответить)

Вы его увидели первый раз в FSD и у вас все ассоциации с этим словом только завязаны на fsd?) Поэтому вы не понимаете что такое components, pages, layouts, globalState и т.п.

про public API. да!

Ясно, понятно)))) С import и export мы работать не умеем)

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

Хорошо, поздравляю, вы победили! Вы во всем правы пойду учиться работать с import и export.

Это здравая мысль, учиться никогда не поздно

Отлично. Вы разбили компоненты на подпапки. И так же у вас разбиты utils, hooks, helpers, state. Причем структура разбиения зачастую совпадает. Так почему бы не зайти с другой стороны и первым уровнем сделать разбиение по сущностям, а уже потом по типу используемого кода?

Более того, у вас частично так и есть на картинке: вместо shared у вас выступает первый уровень проекта, а бизнес зависимые вещи лежат в pages.

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

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

Потому что это не удобно и не применимо в реальности. На реальном проекте не только черное и белое, а все градации серого. А если проект сложный, то и вся цветовая палитра может быть.
И не все привязано к "сущностям", и не все "сущности" изолированы друг от друга, в реальной жизни все сложение, с ветвлениями где многое зависит от многого, в том числе одна "сущность" зависит от другой или сразу от нескольких, более того эти "сущности" могут зависеть от сторонней логики, не связанной напрямую с какой-то "сущностью". И вообще проект это далеко не только набор "сущностей". Поэтому ваш вариант не подходит и может быть лучшей заменой классики.
И вообще мыслить "сущностями", а не конкретными вещами - это путь в никуда.

И так же у вас разбиты utils, hooks, helpers, state. Причем структура разбиения зачастую совпадает. {{И дальше ваша мысль про "сущности"}}

Так же? Это как?
Как образом например:
hooks/useOutsideClick
hooks/useBoolean
hooks/useSwite
И т.д. и т.п. имеют отношения с сущностям?

Как образом например:
utils/formValidator
utils/asyncHelpers
И т.д. и т.п. имеют отношения с сущностям?

Аналогично и касаемо всего остального. Опять же, все просто, сущности просто тут не нужны и не применимы, страница логина это просто страница логина, не больше не меньше. Фильтр списка товаров, это просто фильтр списка товаров, не больше не меньше. Сам по себе список товаров, это просто список товаров, не больше не меньше. Карточка товара, это просто карточка товара, не больше не меньше. Все это по сути просто детали реализации проекта, например интернет магазина. Вот всё, всего лишь на всего.
А вы начинаете всё переусложнять, вводить дополнительные слои абстракций, какую-то чудоковатую структуру файлов и папок придумывать. Зачем? Рад чего? Я понимаю если бы это реально упрощало и ускоряло разработку, делала бы ее приятной и интуитивно понятной. Но нет, этот подход делать все ровно наоборот. Вместо того, что элементарную вещь типа страницы входа или фильтра реализовать так же элементарно, ты вынужден перешагивать через 100500 ограничений и дополнительных абстракций.

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

Это просто слова, которые ничего не значат. Любой может использовать этот трюк.

"Сколько я не работал на разных проектах, проекты где был применен fsd банкротились на следующий день"

"Сколько я не работал на разных проектах, сова прилетала к моему окну ровно в 12:44"

"Сколько я не работал на разных проектах, только использование $mol делало проект идеальным"

.hooks/useOutsideClick

отлично, этот хук не привязан к сущности и складывается в shared.

а вот допустим: hooks/useOrderItems - уже привязан к заказу и его можно положить в домен заказа. Зачем он мне на глобальном уровне, если я использую его только для некоторых компонентов (которые так же привязаны к этому домену)?

Все зависит от размера проекта. Если у вас 20 хуков, то конечно нет ничего плохого в классическом разбиении. Когда их перешагивает за 200? отслеживать то , что уже написано по определенному домену - становится очень сложно

Это просто слова, которые ничего не значат. Любой может использовать этот трюк.

И да, и нет. Классическое разбиение не предлагает хороших решений для проблемы роста числа файлов объединенных по одному типу. Соответственно на больших проектах это приводит к свалкам. Если у вас есть контр примеры, я с радостью их услышу. Но пока весь мой опыт это только подтверждает

Вы может не понимаете смысл классики? С чего вы вообще решили что там нет вложенностей? Что там нет разбиения на логические уровни?

Ваш пример с useOrderItems, только хуки не использованы, вместо них MobX ибо я например адекватный человек.

src/
  pages/
    OrdersPage/
      index.tsx // Тут UI
      state.ts // Тут локальное состояние для этой страницы
      styles.module.scss // Стили для этой страницы

Всё лежит друг с другом, это обычная классика. Уже 100 раз приводил эту структуру. В чем тут проблема? Не понимаю. Хоть тысяча таких страниц, пожалуйста, легко.

Это работает в обе стороны. Может это вы не понимаете фсд и о чем говорит ваш собеседник?

Окей. Допустим у вас тысяча страниц и 10 из них использует одну и туже функцию или компонент который завязан на бизнес. Где вы его разместите в данной структуре? У вас из вариантов тольк либо его привязать к странице, либо скинуть в кучу. В первом варианте у вас страница выступает в роли домена, а в другом варианте у вас начинает копиться свалка в общих компонентах, так как вы туда помещаете все общие компоненты по всем доменам.

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

Общий компонент в src/components или никто не запрещает в src/compoents/orderSpecified/{компоненты}
если они все сгруппированы по какому-то признаку и при этом используются в разных местах. Так же можно и src/components/formFields/{компоненты для форм}

Общие функции в src/heplers или src/utils как больше нравится называть.
Если они шарят какое-то общее состояние глобальное, то оно лежит в src/globalState например src/globalState/orderState

все верно, когда их становится в "куче" много, их начинают групировать в этой куче. Более того, как правило это приводит и к тому что в других "кучах" так же возникает необходимость групировки.
в итоге у нас /orderSpecified повторяется в нескольких разделах. И самое веселое когда в одном разделе это уже сгрупированно, а в другом нет, и там начинают групировку. Это часто приводит к тому , что появляются расхождения.

Идея же групировки по бизнесу разворачивает порядок групировки - вначале идет домен, а уже потом любое удобное разбиение (в том числе и классическое). В таком случае вам сложнее получить разные имена и сразу видно весь функционал по определенной доменной области. Это отсекает разные проблемы от поиска функционала по домену: например components/cart/... и components/order/... (и попробуй угадай как это назвал прошлый разраб), в то время как уровень ниже уже легко разбивается по любой другой системе со строго определенными разделами.

Так же я заметил, что у вас смешаны в кучу бизнес компоненты и инструментальные примитвы. Если мы разбиваем по доменам, то никто не машает нам вынести инструменты общие для проекта в shared. Это позволяет лучше понимать какими инструментами мы обладаем, а не разбираться в мешанине: бизнес/не бизнес.

все верно, когда их становится в "куче" много, их начинают групировать в этой куче. Более того, как правило это приводит и к тому что в других "кучах" так же возникает необходимость групировки.в итоге у нас /orderSpecified повторяется в нескольких разделах. И самое веселое когда в одном разделе это уже сгрупированно, а в другом нет, и там начинают групировку. Это часто приводит к тому , что появляются расхождения.

И где проблема? Все сгруппировано. Все логично и все понятно.

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


Плюс вы фантазируете со сложность поиска. Во первых есть ctrl + f, во вторых, вы знаете где нужный вам компонент находится на странице, допустим вам надо пофиксить сворачивающийся блок на странице товара, он идет сразу после блока описание, зашли в src/pages/orderDetails/index.tsx и вот вы увидили нужный вам компонент в JSX'e, ctrl+click по нему и вуаля, вы уже в этом компоненте, 30 секунды и все дела. Дальше уже пофиксили и дело сделано.

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

И где проблема? Все сгруппировано. Все логично и все понятно.

в итоге в идеальном мире все сведется к или

components/order

hooks/order

и наоборот

order/components

order/hooks

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

Вы выдумали сценарий где проект пишут джуны или вообще неадекваты.

увы, но нет. Мало кто нормально поддерживает нормальное именнование подгрупировки синхронизированное между components, helpres ... Да и в принципе это довольно странно:может быть на один домен 30 коммпонентов, и один хук. Что мы будем в этом случае делать? в каждом разделе создавать подраздел по домену? а если не создадим, то нужно будет помнить про то, что для вот этого домена есть хук?

Плюс вы фантазируете со сложность поиска. Во первых есть ctrl + f, во вторых, вы знаете где нужный вам компонент находится на странице, допустим вам надо пофиксить сворачивающийся блок на странице товара, он идет сразу после блока описание, зашли в

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

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

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

Ну и кстати если рассуждать про абстрактный огромный проект, где есть "мусорка", то этот проект должен быть разбит на микрофронты, причем заранее, до появление этой самой "мусорки". И тут уже бац и все эти драматизированные проблемы файлов и папок опять улетучиваются сразу)

Ну и кстати если рассуждать про абстрактный огромный проект, где есть "мусорка", то этот проект должен быть разбит на микрофронты, причем заранее, до появление этой самой "мусорки". И тут уже бац и все эти драматизированные проблемы файлов и папок опять улетучиваются сразу)

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

Это не какой-то абстрактный проект. Три моих последних проекта были именно такмими, и только в одном мы делали переход на микрофронты. И этот переход был обусловлен не тем что нужно разбить на домены(это разбиение прекрасно выполняется и без микрофронтов), а тем что хотелось развязать релизный цикл между командами и где каждая команда выполняла релиз отдельно

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

С развитием компонентного подхода пришел концепт переиспользуемости, то есть в src/components кладутся однообразные компоненты типа Button, Form, Cart. Они могут использовать глобальные вызовы api и читать данные из глобальных сторов globalStores, но могут и через пропы принимать что-то кастомное, специфичное для страницы, на которой используются. Это логичное, минималистичное и удобное деление и называется "классической структурой", и в статье показан ее кастомный вариант, который хорошо масштабируется и интуитивно используется, несмотря на определенную чрезмерную интерпретацию (типа pages и layouts почему-то кладутся в components).

Внимательно читаю вашу дискуссию, но я тут на светлой стороне, хотя в словах Клерика она звучит грубо иногда)

В точку!)

Они могут использовать глобальные вызовы api и читать данные из глобальных сторов globalStores

Button тоже может? Выглядит так, что в components у вас будут намешаны компоненты с разной семантикой. Ну или не будут, но тогда, скорее всего, в вроде как "простой" классической внутри спрячется семантическая посложнее. Толку тогда от это вроде как "простого" декорирования?..

О какой конкретно сложности вы говорите? Для вас что, сложно когда Button может дергать что-то из глобального стора?

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

Например, кнопка читает глобальную тему стилей и нужно на лету менять цвет всех кнопок на проекте. Допустим, что css variables не используются, а тема хранится в глобальном сторе или передается как во многих UI библиотеках через верхнеуровневый контекст, либо css in js. В этом случае безусловно через пропсы каждой кнопке передавать текущий цвет нелогично.

Второй пример - локализация. Есть 10 языков, данные текстов хранятся в глобальном сторе. Button сделали с таким интерфейсом, что текст опционален - `<Button text={store.localize('Ok')} />`, а по дефолту кнопка имеет текст Ok. Это часто используется например в модалках или конфермах, когда есть 2 кнопки - отказ и принять, и не хочется каждый раз тексты передавать через пропы. Разумеется, кнопка возьмет дефолтный текст из глобального стора, если хранение локализации находится там.

Третий пример - есть специфичная кнопка src/components/ButtonGetUser, которая используется на 5 страницах и должна вызвать апи получения данных по пользователю, и вызвать модальное окно с показом его данных. Этот кейс ближе к админкам. Зачем дублировать логику, передавая в onClick одну и ту же логику, если этот компонент может сам обратиться к глобальному апи и глобально вызвать модалку - DRY принцип в действии.

Я не задумываюсь о разделении "глупый компонент", "тупой компонент", "компонент, принимающий все только через пропы", "компонент, способный сам вызывать глобальные действия" - если того требует логика, компонент может трансформироваться между этими состояниями без лишней когнитивной нагрузки и выделения дополнительных сущностей - адаптеров, коннекторов, контроллеров, HOC, виджетов и что только не видел еще для "соблюдения неких принципов".

Про декорирование не понял, я вроде о нем ничего не говорил)

Третий пример - есть специфичная кнопка src/components/ButtonGetUser

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

Про декорирование не понял, я вроде о нем ничего не говорил)

Это в переносном смысле - не про декораторы. В папке components плоская структура подпапок? Никакой группировки нет? Button и ButtonGetUser лежат рядом? Если плоская, то где та грань, когда надо начинать группировать? Если группируется, то по какому принципу? Если как-то семантически и подпапок немного, то смысл в этой декоративной "components"?..

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

Кому-то достаточно и доменов в pages

Не прозрачный намек, кому-то заменяется на "дуракам". Кавычки не спроста.

А кто-то видит необходимость и поглубже в DDD погрузиться

Ещё не прозрачный намек, кто-то заменяется на "умный". Кавычки не спроста.

Фронтовые приложения растут в масштабах и лучшие практики проектирования тоже постепенно заходят во фронт.

Смешно, "лучшие" практики, ага. Превращать простые вещи в переусложненный ад, это конечно "лучшая" практика. А потом плакаться и "решать проблемы", которые сами себе создали и ещё сверху навесили кучу правил и ограничений на каждый чих. Зато потом они называют свою проекты большими, или сложными. Но мы то знаем, что их проекты на самом деле не сложные, просто они их уничтожили сами.

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

 Когда рядом лежит Button и ButtonGetUser

В чем проблема? Там черным по белому написано "Кнопка"(Button), "Кнопка получить пользователя"(ButtonGetUser). Исходя из названия назначения этих компонентов понятны. Там же не ASdqwe и Yerqw, где не понятно что это, пока не зайдешь внутрь.

Дураки/умные - это же надо так умудряться интерпретировать. Я текст на абзацы не просто так разбиваю - там цельная мысль в нескольких предложениях, нет смысла выхватывать предложения из контекста.

Исходя из названия назначения этих компонентов понятны

Конечно. А вот когда у вас рядом лежит 20 кнопок, а ещё некоторые компоненты выглядят как кнопки, но по настоящему виджеты, а ещё часть кнопок лежит в страницах, так как подумалось что они слишком частные, то узнать о наличии нужного кода: задача уже не тривиальная.

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

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

Или у нас есть функционал по показу надоедливого баннера с предложение включить пуши. У него так же может отсутствовать страница.

Дальше ещё интереснее получается: вот у нас есть дефолтная кнопка из кита с 3-5 разными дизайнами.

И допустим кнопка которая меняет дизайн в зависимости от наличия подписки или ее отсутствия. Вопрос: вы ее куда сложите? В кнопки? Тогда у вас там помимо базовой кнопки будет десяток других кнопок. А если она в место кнопки будет ещё отображать значок, то ее всё ещё имеет смысл хранить в кнопках? Или вы в страницу положите? А из уже 3 разные. Объедините их в группу? Хмм кажется тогда это уже не страница. И где искать эту кнопку, и знать что ее уже реализовал кто-то?

О а вот ещё пример: вам нужно отображать номер карты на странице с определенным форматированием. Где сложить функцию форматирования? В utils? А там уже сотня разных других форматирований для других сущностей, так как форматирование повторяется из раза в раз.

Если вы это серьезно, то крайне недооцениваете классическую структуру.

Несколько "связанных модалок" - это несколько "независимых модалок, вызываемых колбеками при закрытии со статусом успех". Эти модалки лежат в components/modal/lib и могут вызывать друг друга. Если они вызываются только с одной страницы - то будут лежать в папке страницы.

Что за modules (модули) в замену семантичным pages не понимаю. Звучит как заменим "страницу" на "модуль" - как это можно вообще придумать?

Показ баннера - компонент лежит в components/banner, вызывается параметром в глобальном сторе showBanner: boolean. Этот компонент смотрит в глобальный стор и при изменении значения отображается. Он не зависит от страниц.

"кнопка которая меняет дизайн в зависимости от наличия подписки" - интересный кейс, то есть если передал onClick то один вид, если не передал - то другой. Решается маппером в компоненте components/button. Если ей нужен значок - он передается через проп <Button leftIcon={''} rightIcon={''} />, никакой необходимости делать дубляжи компонентов на каждый проп нет.

Функции форматирования строк складываются в utils/formatString, которая экспортирует объект с 100 разными видами форматирования, если это нужно проекту. Это по факту исключает дубляж - глазами пробежаться по методам куда проще, чем искать в море widgets, entity, app, feature и т.п. разнородных файлов с форматированиями.

Нападки в целом "из пальца", попробуйте сами в классике писать - там нет перечисленных проблем)

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

Не совсем понимаю почему вы все хотите складывать в страницы. Даже если их 0 или 2+.

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

Вот взять пример с модалками: вы их сложили в модалки. Отлично. Но там 7 модалок на 3 разных сценария. Более того, у них есть ещё несколько специфических визуальных компонентов, которые имеют значение в рамках работы с емвйлом, но не имеют никакого значения за его рамками. Например, какие-то специфические кнопки. И конечно же у вас есть что-то, что хранит сами сценарии вызова этих модалок. Для примера пусть это будет какой-то отдельный компонент, который вы на верхний уровень роутинга складываете и так он доступен на всех страницах.

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

В вашей структуре будут два варианта:

  1. Все модалки, компоненты и утилиты лежат на верхних уровнях components/ utils/ hooks/. Могу смело сказать, что при наличии 10+ таких сущностей навигация в проекте становится возможной только по прямым ссылкам в файлы.

  2. На каждом уровне создаётся ./emailConfirmation. (На практике никто под один хук не создаст такую папку и он потеряется в общей куче). В итоге, что-то просачивается в глобальное пространство имён, а что-то лежит в папке. Но нигде не обозначено в явном виде должно оно использоваться напрямую или оно имеет смысл только в контексте определенного домена

Проблема в моем опыте: я обычно прихожу на большие проекты на которые люди потратили десятки или сотни тысяч часов.

Это всё объясняет, такие проекты безальтернативно обречены быть крайне неприятными в работе. У вас судя по всему опыта на на приятных проектах нет, либо вы завидуете тем, у кто на них работает)

  1. Все модалки, компоненты и утилиты лежат на верхних уровнях components/ utils/ hooks/. Могу смело сказать, что при наличии 10+ таких сущностей навигация в проекте становится возможной только по прямым ссылкам в файлы.

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

Почему же безальтернативно? Они вполне приятны после определенного рефакторинга и осмысления. В нем стоят интересные задачи и меньше свалки чем в растущем проекте на классической структуре. Поэтому я скорее сочувствую тем кто вынужден работать в ее рамках.

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

Почему же безальтернативно? Они вполне приятны после определенного рефакторинга и осмысления.

К чему этот самообман?

В нем стоят интересные задачи и меньше свалки чем в растущем проекте на классической структуре. Поэтому я скорее сочувствую тем кто вынужден работать в ее рамках.

А да, ну ясно тогда.

Проблема в том, что в итоге у вас все теже десять слоев,

Эммм нет, откуда бы? Любой компонент/страница/и т.п. напрямую общается с локальным/глобальным состоянием и/или через контекст с состоянием родительского компонента если есть такая потребность.

В чем самообман? Это вполне реальный кейс из моего опыта работы.

У вас есть глобал стор

У вас есть локальный стор

У вас есть страница

У вас есть кастомые хуки

У вас есть утилитарные функции

У вас есть компоненты (а в них сколько угодно уровней)

В итоге работая с одним сценарием - у вас открыто пол проекта в дереве файлов.

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

В чем самообман? Это вполне реальный кейс из моего опыта работы.

Ах, ну раз вы говорите что реальный, значит поверим вам на слово.

В итоге работая с одним сценарием - у вас открыто пол проекта в дереве файлов.

Нет, ровно столько, сколько нужно. Тем более все зависимости явные и очевидные, всё на ладони.

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

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

Ах, ну раз вы говорите что реальный, значит поверим вам на слово.

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

Нет, ровно столько, сколько нужно. Тем более все зависимости явные и очевидные, всё на ладони.

Кажется вы не понимаете о чем я говорю. у вас в принципе такая ситуация не может быть. Вот я открываю utils - и у меня лежат там только утилиты по нужному домену. Вы открываете utils, и у вас там утилиты по всем доменам + еще и технические утилиты. Так что нет, у вас открыто не все что нужно а намного больше.

Плюс тонны повторяющегося кода, т.к. это архитектура не особо дружит с DRY.

Почему не дружит? Не вижу никакой разницы в этом отношении с классикой.

От же самый сценарий с ней займет в разы больше времени чем в классике из-за неповоротливости, ограничений.

В зазы больше времени? на планировании разбиения по доменам это действительно займет больше времени, только не в разы, а на 1-2%. Ровно так же как как и любые другие ограничения кода которые заставляют задуматься о том как писать код, что бы потом не получить проблем.

YASGNI

Отличный принцип. Бавают проекты где и классическое разбиение избыточно, а можно все сложить в 1 - 2 файла. Но когда ты понимаешь что тебе понадобится больше 10 файлов, ты понимаешь, что нужна уже система распределения файлов.

В моем случае речь идет о ситуации когда файлов намного больше и классика уже плохо справляется.

Вы открываете utils, и у вас там утилиты по всем доменам + еще и технические утилиты

1) Открою тайну, разные "домены" могут и используют общие utils, в противном случае у вас ANtI DRY и дублирование кода.
2) В чем проблема? Ну лежат там разные утилиты, и что теперь? Как это реально мешает?

Нет ы должны поверить вам, что поправде проект был мне не приятен, хотя ни проекта, ни меня вы толком не знаете.

Ну когда вам говорят я видел НЛО в небе вчера и это прям точно пришельцы. Вы поверите? Вот вы же не знаете этого человека и что он видел, но вот он вам это сказал. What you gonna do with that?

Почему не дружит? Не вижу никакой разницы в этом отношении с классикой.

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

только не в разы, а на 1-2%. Ровно так же как как и любые другие ограничения кода которые заставляют задуматься о том как писать код, что бы потом не получить проблем.

Я например и так проблем не получаю, вообще никаких и никогда не получал, т.к. у меня классика. Там просто это исключено физически ибо нет жестких ограничений. Она супер легко и быстро адаптируется под конкретную специфику любого проекта.

В моем случае речь идет о ситуации когда файлов намного больше и классика уже плохо справляется.

Она отлично справляется. А вы просто говорите, что она плохо справляется. Тут есть огромная разница. Вы хотите выдавать желаемое за действительное, и даже верите в это реально. А мне пофиг на конкретные убеждения, для меня важен реальный профит, если MobX дает мне этот реальный профит по сравнению с остальным, разумеется я использую его, если классика дает мне реальный профит по сравнению с остальным, разумеется я использую ее. Я с 2016 до 2021 использовал Webpack, казалось бы, а потом попробовал Vite и он реально для меня лучше, т.к. при прочих равных он быстрее, поэтому теперь я двигаюсь с Vite'ом. Если бы FSD давала реальный профит, то я бы без задней мыслей ей пользовался. Но увы и ах, лучше классики для фронта пока ничего не придумано.

Открою тайну, разные "домены" могут и используют общие utils, в противном случае у вас ANtI DRY и дублирование кода.

а в чем секрет, и как это мне противоречит? Более того причем тут DRY?

2) В чем проблема? Ну лежат там разные утилиты, и что теперь? Как это реально мешает?

в тмо что у вас забит экран не нужными файлами, соотвественно навигация в них хуже. Согласитесь: найти 1 файл среди 10 проще чем среди 50.
Более того, если вы даже не знаете как называется файл, то найти подходящий код пролистав 10 файлов проще чем 50.
Зачем мне код каждого домена, если я могу использовать код только нужного?
С такой логикой, а что бы нам все файлы не объеденить в один)

Ну когда вам говорят я видел НЛО в небе вчера и это прям точно пришельцы. Вы поверите?

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

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

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

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

 Она супер легко и быстро адаптируется под конкретную специфику любого проекта.

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

Если бы FSD давала реальный профит, то я бы без задней мыслей ей пользовался.

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

а в чем секрет, и как это мне противоречит?

Вот цитата ваша

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

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

Забит?) Прям ненужными?) У меня проблем с навигацией нет и так понятно где что лежит, а если не понятно, то CTRL+Click по нужной функции/классу/компоненту в том месте где он применяется и вуаля. Плюс есть такая штука как ctrl+f. В общем видите, у вас какие-то проблемы с навигацией, что вы их выделяете, а у меня их нет и не было никогда, поэтому я их даже не выделяю как преимущества, т.к. это вещь сама собой разумеющиеся.

В отличии от нло, я говорю про вполне реальную технологию, которую использовали некоторые люди и довольны.

Очевидцы НЛО так же говорят. Что вы что вы, вот я точно видел НЛО, а остальные нет.

Более того я привел несколько кейсов когда она работает лучше.

Я ни одного реального кейса не увидел. Только вымышленные и абстрактные. А цену, за так называемое решение этих кейсов вы платите каждый день. У вас все крутится вокруг вымышленных "помоек" и "сложной навигации". А когда мы возвращаемся в реальность, то никаких проблем с навигацией на самом деле нет в классике и "помоек" тоже, любой проект где больше 3х папок и файлов тогда можно называть помойкой)

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

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

соотвественно вовсе не обязательно происходит дублирование кода

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

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

Ни одной реальной проблемы тут не увидел опять. С этим работать легко, быстро и проблем нет. В противном случае я был бы религиозным фанатиком FSD. Я же не мученик и специально себя не мучаю.

ну как мы видим, вы не готовы критически подойти к вашему суждению о фсд. 

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

что-то у вас конструктивизм совсем потерялся. и пошли суждения из разряда - что-то плохое потому, что плохое.

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

Ключевое - "не обязательно". Потому что дублирование происходит и много. 

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

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

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

Хорошо, попробуем с другой строны, раз вы не понимате на синтетических примерах. Я сейчас возьму один из проектов написанных на классике, и попрошу в них что-то найти. Вы попробуете или найти нужный код по предложенному мной домену, или предложить, что можно сделать для упрощения его поиска. https://playcode.io/2233829.
Давайте, вот тут посмотрим, что у нас есть по чатам? Как быстро вы нейдете весь функционал связанный с ними.

Я сейчас возьму один из проектов написанных на классике, и попрошу в них что-то найти. Вы попробуете или найти нужный код по предложенному мной домену, или предложить, что можно сделать для упрощения его поиска. https://playcode.io/2233829.Давайте, вот тут посмотрим, что у нас есть по чатам? Как быстро вы нейдете весь функционал связанный с ними.

Ну во первых 5 секунд, и это без шуток. Ctrl+f и написал chat.

Во вторых в вашем наигранном примере даже это наиграно, когда доходит до такого, все эти компоненты просто в папку chat/ складывают и все)

В этом и смысл я взял классическую структуру в чистом виде и мы тут решаем куда и как ее менять.


Отлично, но вы пропустили вы пропустили, что есть еще много messages, или например кнопку отправки сообщения (sendButton)

То есть вы выделяете домен внутри каждой папки (если там так же есть необходимость). То есть у вас происходит, что все файлы по домену лежат в
/components/chat
/pages/chat
/utils/chat
/store/chat
/hooks/chat

в разбиении на домены это идет наоборот:
/chat/components
/chat/pages
/chat/utils
/chat/store
/chat/hooks

и тут мне не нужно даже искать, а есть ли у меня утилиты на чат в utils, так как они уже лежат рядом.
Более того, решение выделить папку в components появляется далеко не сразу. И как мы видим - не все связанное с чатом реально имеет chat в названии. Там вполне может быть и messages. И вот какой-то разработчик выделил chats в comonents, а в hooks как лежал какой-нибудь useMarkMessageAsReaded так и лежит. Подобные кейсы очень частые.

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

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

И в этом огромный плюс, в виде удобства, гибкости, скорости и отсутствия лишнего дублирования.

У меня же обратная ситуация - ничего из того что я осознано пометил как открытое для использования- наружу и не торчит. соотвественно сложнее получить связь всех ко всем.

Ровно как и сложнее делать вообще все, что касается работы над таким проектом. А связь всех ко всем во первых высосана из пальца и не реалистична от слова совсем, во вторых возможность связи между компонентами системы на практике и в реальном мире дает только плюсы. А минусы как обычно только абстрактные и теоретические в специально выдуманных сценариях. И все равно эти "минусы" ничтожны по сравнению с плюсами.

И в этом огромный плюс, в виде удобства, гибкости, скорости и отсствия лишнего дублирования.

так и у меня дублирования нет. Если компонент предполагает свое использование в других местах - открываем его в явном виде.

А по поводу остального: с той же аргументацией можно все методы класса сделать публичными - это тоже даст гибкость, удобство и скорость. (но это привнесет еще и те проблемы про которые я пишу)

А связь всех ко всем во первых высосана из пальца и не реалистична от слова совсем, во вторых возможность связи между компонентами системы на практике и в реальном мире дает только плюсы.

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

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

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

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

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

Ключевое - "дублирования вытекающего из фсд нет." Оно вытекает из DDD из которого вытекает FSD, вы просто решили таким образом прикрыть FSD. Настоящий FSD как и настоящий DDD без дублирования невозможен, иначе весь их "смысл" теряется и вы уже получается лицемерите. Это говорить что вы веган, но есть сыр)

Вы не пишите на фсд, но утверждаете

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

. Да есть люди у которых вкусы специфичны, да есть люди которые нюхают клей, и т.п. 

эк вас понесло, теперь люди которые имеют другие вкусы отличные от вас похожи на наркоманов.
Почему бы не взять пример из спорта: вот вы любите бегать на скорость, а я полумарафоны. Следует ли что одно хуже другого? вовсе нет.

что в вашем конкретном случае есть особые предпочтения, они не объективные, а просто вам так нравится и считаете что так хорошо

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

Настоящий FSD как и настоящий DDD без дублирования невозможен,

Почему же фсд не возможен? можно пример кода который я буду вынужден продублировать?

 достаточно просто взглянуть) FSD не исключение)

Я знаю не мало людей которые считали что-то плохим пока не разобрались. Более того, разве вы не писали что изначально тс вам не понравился?

Кстати возник еще один вопрос: вот вы и сами выделяете домены, хотя считаете, что все из них должно быть открыто для использвания. Скажите, какая принципиальная разница будет между тем, что домен будет на первом уровне папок (как у меня), а не на втором(как у вас)?

Более того, разве вы не писали что изначально тс вам не понравился?

Так и есть, я же говорю я не фанатик, если бы в FSD я видел реальные удобства перебивающие классику по совокупности взвешенных факторов, я бы использовал FSD. Ну и TS тут не особо подходит под аналогию, потому что JS и TS это грубо тоже самое, только в TS есть возможность типизировать. А FSD и классика диаметрально противоположные.

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

Опять не та аналогия, конечно для вас она удобна) Но более корректная в данном случае аналогия из спорта будет такая:
Мы оба бежим марафон в +25 градусов.
- Я бегу в современно легкой футболе, шортах и максимально удобных кроссовках.
- Вы бежите в зимней фуфайке, толстых штанах и в берцах туго затянутых.

Почему вы так побежали? На этот вопрос нет ответа рационального. Просто вы так захотели, вам так нравится. Отсюда и специфичные вкусы.

Так и есть, я же говорю я не фанатик,

Как упомяналось вами выше: говорить и быть это разные вещи.

Если вы одно тяжело принимали, может и сейчас такаяже проблема?

Но более корректная в данном случае аналогия из спорта будет такая:

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

Но в данном контексте любой из вкусов можно назвать специфичным.

Кстати возник еще один вопрос: вот вы и сами выделяете домены, хотя считаете, что все из них должно быть открыто для использвания. Скажите, какая принципиальная разница будет между тем, что домен будет на первом уровне папок (как у меня), а не на втором(как у вас)?

Скажите, какая принципиальная разница будет между тем, что домен будет на первом уровне папок (как у меня), а не на втором(как у вас)?

Принципиальная такая - в моем случае это не будет каким-то правилом, это будет продиктовано удобством. А так, как жестких правил и ограничений нет, то и политика "все что касается chat должно лежать в папке chat" тоже не актуальна для меня) Все лежит ровно так, где удобно и так, как удобно. Это самое главное правильно, что все было удобно, легко и просто)

Если вы одно тяжело принимали, может и сейчас такаяже проблема?

Точно не в этом случае

в моем случае это не будет каким-то правилом, это будет продиктовано удобством.

Чем больше проект растет, чем важнее его структурированность и согласованность, и правила помогают этому следовать. Вы раз за разом говорите про удобство, но на примере легко упустили части функционала.

Чем больше проект растет, чем ваджнее его структурированность и согласованность

Всё равно не вижу где тут в классике проблемы, только если вы сами специально создаете надуманными примерами. Ну большой стал проект и что теперь. Ну теперь <Button /> использует не 10 страниц, а 110. Теперь <Input /> и <Select /> не на 3х страница, а на 53. Какая разница то? Просто стало больше всего и все, при том же подходе - Keep It Simple.

привел не надуманный пример, а вполне реальный пример.

Проблемы нет в применении uikit. Как видите он и в fsd максимально открыт.

Другое дело с доменами: тут как и в классах у вас есть закрытый и открытый функционал. У вас же все открытое и каждый может использовать все. Согласно вашей логике - мы должны отказаться от приватных методов, так как это мешает писать проект "просто". И вот это просто приводит к тому, что происходит хаос и все дёргают все подряд, и ты не можешь ничего поменять.

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

Почему же фсд не возможен?

Потому что для избегания дублирования вы все кладете в shared. А потом вы гордо говорите, все что относится к моему "домену" находится в одной папке. Но есть нюанс, все остальное что он тянет из вне, это не считается и мы тут закрываем глазки. Классно)

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

Потому что для избегания дублирования вы все кладете в shared.

почему все? я складываю туда только то, что не связано с бизнес логикой. Соотвсетственно, я не понимаю проблемы: у нас в shared лежит всякий инструментарий, и с тем же успехом он мог лежать в node_modules. Пока это никак мне не противоречит. Все что относится к домену - лежит все еще к домену.

Назовите конкретный пример кода, котоырй я буду вынужден продублировать.

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

Первый момент:
С ваших слов все что касается "домена" chat лежит не только в папке chat? А это противоречит вашим убеждениям из вашей "доменной" религии. И какой тогда в этом смысл?

Второй момент:
Т.е. если вы не будете форматировать дату и показывать пользователю из России YYYY-MM-DD вместо DD.MM.YYYY , то это ничего страшного, это к бизнес логике отношения не имеет? То есть если вы не будете показывать кнопку "Войти", то это ничего страшного, это не относится к бизнес логике?

Бизнес логика не имеет никакого смысла и не несет ни какой пользы без инструментария. Ибо без него ей нельзя воспользоваться.

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

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

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

Все что относится к домену - лежит все еще к домену.

Ага, обязательно)) Это мы уже выяснили)

С ваших слов все что касается "домена" chat лежит не только в папке chat

можно привести слова, где говорится, что-то относящееся к домену чатне лежит в нем?

Т.е. если вы не будете форматировать дату и показывать пользователю из России YYYY-MM-DD вместо DD.MM.YYYY , то это ничего страшного, это к бизнес логике отношения не имеет? 

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

Бизнес логика не имеет никакого смысла и не несет ни какой пользы без инструментария. 

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

Так что, получается используя shared вы лицемерите говоря что у вас все разбито по "доменам" и всё что касается "домена" лежит в его попке

Все что касается бизнеслоки домена лежит в домене. А причем тут инструментарий так и не понятно. В кнопке из material-ui есть бизнеслогика или привязанность к домену? нет. Так почему она должна лежать в его рамках? И реакт тащить в домен?

Это так забавно, как вы неправильно используете инструмент, а потом обвиняете, что оно не работает)

можно привести слова, где говорится, что-то относящееся к домену чат не лежит в нем?

Опять манипуляции уровня начальных классов. Чат не использует кнопки? Чат не использует инпуты? Чат не использует приведение дат к единому формату? И т.д. и т.п. Ваш чат ничто, без этих элементов. Которые у вас лежат в shared и используются вашим "доменом" чата. Поэтому то, что касается чата у вас лежит не только в папке с ним. Привет лицемерная религия с двойными стандартами.

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

Да, вот именно. Они и должны лежать в shared. И без него(инструментария из shared), ваши "домены" не являются работоспособными, а значит они зависят от него. Вот опять ваша религия ударила в грязь лицом

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

Так у меня с этим нет проблем)) Это у вас религия что все что касается "Домена" должно лежать в его папке. Только есть нюанс, ваш "домен" на самом деле это ничто, пустышка, пустой слово.

Ваш компонент не имеет никакого смысла без реакта

Да, поэтому у меня именно реактовский компонент и у меня нет с этим проблем) Так же как чат не имеет никакого смысла без кнопок, инпутов и т.д. он зависим от всего этого. Это это всего лишь чат. Страница с чатом, виджет часа, вообще без разницы. Просто чат и чат. А не всемогущий "домен".

Все что касается бизнеслоки домена лежит в домене. А причем тут инструментарий так и не понятно. В кнопке из material-ui есть бизнеслогика или привязанность к домену? нет. Так почему она должна лежать в его рамках?

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

Подводя итог:

Ваш "домен" — ничто без shared/помойки или как вы там называете общие вещи. И он не является чем-то самодостаточным от слова совсем. Поэтому весь культ вокруг "ничто" бессмысленный.

Весь код использует реакт. Вывод? Реакт должен лежать в каждом домене) срочно распаковываем и складываем исходники!

В чем разница, что это за код пока он не привязан к бизнесу?

Кстати, шаред может вообще отсутствовать и все будет лежать в нодмодулях. Но согласно вашей логике: нужно срочно их вытащить и сложить в домены)

Это у вас религия что все что касается "Домена" должно лежать в его папке. Только есть нюанс, ваш "домен" на самом деле это ничто, пустышка, пустой слово.

Оно пустое для вас так как вы не понимаете его. Ещё раз: код хранит бизнес логику? Нет? Тогда почему он должен лежать в домене?

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

Соответственно, вы делаете неверные выводы из этого. Вы готовы слышать собеседника или мы тут расходимся? А то меня уже напрягают ваши попытки задеть собеседника с учётом, что вы взяли молоток, пытаетесь забить его ручкой гвоздь, утверждая что так и нужно (ведь он должен забить гвоздь, следовательно и ручкой это можно сделать), и из этого делаете вывод что молоток плохой инструмент. И в упор не слышите объяснений.

Я не понимаю, вы так хотите доказать, что вы правы и не готовы увидеть все это с другой перспективы? Окей, могу не мешать.

Я реалист, я знаю что чат это просто чат. а не "домен". Я знаю что страница логина это просто страница логина а не "домен".

Я не вижу никаких "доменов", я вижу только чат, страницу логина, список комментариев. Я вижу реальные вещи, а не вымышленные. Думаю реальными вещами, а не вымышленными. И главное вещи которыми я думаю максимально конкретные и понятные, а не размытые и не имеющие строго описания. У меня 0 проблем касающихся архитектуры, т.к. я использую классику. У вас наоборот целый набор проблем, которые вы пытаетесь решить способами, не предназначенными для этого. А я эти "проблемы" (в фронтовых SPA) решил лет 7 назад и не испытываю их по сей день. Т.к. лекарство предельно простое.

Вы говорите "домен" то, "домен" сё, а на самом деле это пустое место. Я не пляшу вокруг пустого места. И не выстраиваю архитектуру вокруг пустого места.

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

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

Ох уж эта отсылка авторитету. Я реалист/прагматик/гений/филантроп - значит я прав, а вы нет)

Страница логина - это страница логина. Кто спорит? И она так же смело принадлежать домену, например авторизации, в котором будет десяток страниц и компонентов.

Вы не видите доменов, соответственно из этого вытекает ваша не способность эффективно с ними работать.

Вас ноль проблем касающихся разбиения папок? Верю, на определенных проектах их и не будет. Более того для вас не проблема искать (и терять компоненты) в списках на 100+ штук. (Кстати это продемонстрировано на реальном примере, с которого вы сразу ушли, так как на нем видно проблемы классики)

Бизнес логика вполне выделяется. Микрофронтенды и микросервисы этому подтверждение. Но согласно вашей логике все должны от них отказаться так как доменов нет, и их нельзя выделить. Пойду напишу ребятам, пусть обратно все сливают ведь классика так прекрасно работает./с

И главное не забыть побольше вставить про то как собеседник манипулирует, это точно докажет что вы правы.

Окей на том и завершаем? Доменов не существует, соответственно микрофронты и микросервисы невозможно выделить и нужно слить?

Так же вы утверждаете, что в пространстве на 300 компонентов проще искать чем в пространстве на 30 компонентов. Конечно это так, кто может подумать иначе?

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

P.s. казалось бы просто осмыслить что такое домен и как его можно реализовать - и все обретёт смысл, но видимо нужно продолжать бить гвоздь деревянной ручкой и утверждать что молоток не работает

Ох уж эта отсылка авторитету.

Это когда говорят. а вот Вася сказал "...", поэтому я так делаю/считаю. И это я порицаю.

Бизнес логика вполне выделяется. Микрофронтенды и микросервисы этому подтверждение.

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

Страница логина - это страница логина. Кто спорит? И она так же смело принадлежать домену, например авторизации, в котором будет десяток страниц и компонентов.

Вот видите, как только доходит до конкретики всё сразу становится элементарным. Вообще не проблема, пускай себе лежат страницы связанные с авторизацией в подпапке auth. Вообще в этом нет проблем в классической архитектуре, потом что они их не создает)

Вы не видите доменов, соответственно из этого вытекает ваша не способность эффективно с ними работать.

Вижу реальные вещи, например когда компоненты для работы с формой можно сгруппировать в formFields или как угодно можно называть. Но для меня это просто группировка для удобства, а не "домен" ради "домена".

Вас ноль проблем касающихся разбиения папок?

Были бы они, я бы искал пути их решения, а не мучался)

И главное не забыть побольше вставить про то как собеседник манипулирует, это точно докажет что вы правы.

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

Простой пример, почему именно дешевые манипуляции бесят людей:
- Гражданину задают совершенно конкретный вопрос: "Почему в бюджете вы указали что освоили деньги на строительство больницы, по адресу г. X, ул. Y, дом Z, а больницы нет? Ведь вы лично ставили подпись и в прошлом году говорили что до DD.MM.YYYY больница будет построена. А уже год прошел с этой даты."
- И вот этот самый гражданин начинает рассказывать про то, всё что угодно, но только не про конкретно поставленный вопрос.

Доменов не существует, соответственно микрофронты и микросервисы невозможно выделить и нужно слить?

Микрофронты и микросервисы вполне себе выделяются в отдельные вещи, но это не несет прямой связи с "доменами" и бизнес логикой. Например микросервис авторизации, с одной стороны сам по себе, а с другой стороны от него все (якобы независимые "домены") зависят. И вот ты вроде A вынес, но A без B ничего из себя не представляет, так же как B без A. Вот тебе и связь все ко всем, которую вы так боитесь почему-то. Я то не боюсь, более того наоборот, она максимально удобна.

Так же вы утверждаете, что в пространстве на 300 компонентов проще искать чем в пространстве на 30 компонентов. Конечно это так, кто может подумать иначе?

Да.
1) CTRL+F в IDE пофигу сколько там компонентов в пространстве.
2) CTRL+Click в IDE пофигу сколько там компонентов в пространстве.

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

С чего это вдруг? Тысячный раз повторяю, классика не накладывает жестких ограничений, т.е. вы не должны, что-то делать просто потому что. Разумеется если метод/класс/компонент/whatever не использует кто-то из вне, то его можно делать приватным. Ключевое слово можно. Хочешь будет приватное, хочешь нет, вообще без разницы по большому счету. На работоспособность программы не влияет.

P.s. казалось бы просто осмыслить что такое домен и как его можно реализовать - и все обретёт смысл, но видимо нужно продолжать бить гвоздь деревянной ручкой и утверждать что молоток не работает

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

поэтому я так делаю/считаю. И это я порицаю.

Это не обязательно, можно так же делать и через себя.

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

далеко не всегда. Вполне типичный кейс когда митрофронты используют один и тот же кит.

А сама по себе отдельно бизнес логика никуда не выделяется, ибо она сама по себе никому не нужна.

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

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

Вижу реальные вещи, 

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

Были бы они, я бы искал пути их решения, а не мучался)

увы, слепое отрицание - именно так и проявляется. Например некоторые люди так отрицали тс. Только спустя какое-то время они согласились с его удобством.

Нет не докажет, но укажет на дешевые манипуляции.

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

но это не несет прямой связи с "доменами" и бизнес логико

ухх. я так понимаю про с ддд не разобрались.

1) CTRL+F в IDE пофигу сколько там компонентов в пространстве.

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

С чего это вдруг? 

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

Принцип ровно тот же: вы считаете что закрытость определенного кода это плохо - так что я лишь продолжил вашу логику.

заметьте, это у меня нет никаких проблем с архитектурой и с навигацией и т.п.,

  1. конечно нет проблем, так как вы терпеть не можете больших проектов и максимально быстро с них устраняетесь.

Я то как раз бью по гвоздю молотком,

Молоток - это разбиение проекта по ддд. Я предлагаю вам понять, что такое домен и как его использовать. Вы выхватываете молоток и начинаете его неверно использовать - как вы не верно используете ддд. Я вам указываю на вашу ошибку - что вы не верно поняли его использование. Вы продолжаете мысль, что если это молоток - и им нужно забивать гвозди, то можно бить и ручкой. (причем, судя по вам вы не пользовались молотком и вам никогда не приходилось забивать гвозди, ну ии вы забивали их плоскогубцами и посчитали это удобным).

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

Вполне типичный кейс когда митрофронты используют один и тот же кит.

Логично, потому что без него они бесполезны.

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

И как именно вы что-то выделяете в отрыве от всего остального? Вот чтобы ваша выделенная бизнес логика имела хоть какой-то смысл.

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

Я так не говорил. Ибо стейт != бизнес логика в отрыве от всего. Стейт это общая часть приложения, без него приложение бесполезно. Так как стейт бесполезен без других компонентов системы.

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

Вы тоже не понимаете что такое "домен". Делаете вид что понимаете, нельзя понимать то, что оторвано от реальности.

увы, слепое отрицание - именно так и проявляется. Например некоторые люди так отрицали тс. Только спустя какое-то время они согласились с его удобством.

Да нет, не слепое. И опять, TS и FSD вещи не сравнимы в данном контексте, TS == JS, именно "==". А FSD !== классике. Это диаметрально противоположная вещь.

Я хотя бы указывал на конкретные примеры

Рассуждая "доменами" это не конкретные примеры. Это абстракции.

ухх. я так понимаю про с ддд не разобрались.

Разобрался давно, оно не работает во фронте без боли и страданий. А я не люблю боль и страдания, простая арифметика.

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

ctrl + click в помощь. Страница на которой находится "подопытный" в помощь. В ее коде все видно и названий никаких знать не нужно.

Принцип ровно тот же: вы считаете что закрытость определенного кода это плохо - так что я лишь продолжил вашу логику.

Плохо, при условии если это мешает разработке. В остальных случая по барабану.

Молоток - это разбиение проекта по ддд

Ага, конечно же))) И как же эти "идиоты" не использующие ддд живут, кошмар просто. Счастливые люди.

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

Так вы сами не понимаете, говорите что вокруг одни проблемы и всё сложно, при это используете "домены" и "молоток" ддд. А я использую классику и говорю что все легко и просто. Так где выигрыш?
Я думаю когда все легко и просто это и есть Win Win.
А когда все сложно и постоянно надо решать какие-то "проблемы" которые вы сами себе создаете на каждом шагу это Epic Fail.
Опять же простая арифметика. Как можно говорить что боль и страдания это хорошо, а простота и лёгкость это плохо?

Логично, потому что без него они бесполезны.

Вообще бывают разные варианты. Но не суть - микрофронты часто используют как разбиение по доменам. И даже вы упоминали их в этом контексте. А теперь вдруг доменов нет.

И как именно вы что-то выделяете в отрыве от всего остального? Вот чтобы ваша выделенная бизнес логика имела хоть какой-то смысл.

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

Если он универсален и не зависит от конкретных сценариев, и может использоватся в любом проекте - то это инструментарий. Удивительно, что для вас это вопрос.

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

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

Вы тоже не понимаете что такое "домен". Делаете вид что понимаете, нельзя понимать то, что оторвано от реальности.

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

Да нет, не слепое. И опять, TS и FSD вещи не сравнимы в данном контексте, TS == JS, именно "==". А FSD !== классике. Это диаметрально противоположная вещь.

во все нет. И там и там это некоторое усложнение чего-то, что бы потом получить профит. То что вы не можете этого осознать - ваша проблема. Примеры были даны.

Рассуждая "доменами" это не конкретные примеры. Это абстракции.

я дал вполне конкретный пример проекта. О чем вы говорите?

Разобрался давно, оно не работает во фронте без боли и страданий. А я не люблю боль и страдания, простая арифметика.

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

ctrl + click в помощь. Страница на которой находится "подопытный" в помощь. В ее коде все видно и названий никаких знать не нужно.

отлично и в итоге вам нужно или помнить все нужные имена или что бы они были сразу тут в редакторе кода. У меня же они все доступны и слева в дереве папок. То есть у меня уже больше инструментов для навигации чем у вас.

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

Плохо, при условии если это мешает разработке. В остальных случая по барабану.

ну так выходит, что закрытость методов плохо. Ведь там ровно те же аргументы хза и против) Выходит вы против и приватных методов.

И как же эти "идиоты" не использующие ддд живут, кошмар просто. Счастливые люди.

  1. как я уже сказал, не во всех проектах оно нужно

  2. некоторые люди не понимают как неудобно им писать код до того как они освоили новые подходы. Я таких адептов с отказом от тс видел не мало.

Так вы сами не понимаете, говорите что вокруг одни проблемы и всё сложно, при это используете "домены" и "молоток" ддд. А я использую классику и говорю что все легко и просто. Так где выигрыш?

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

С тем же успехом я бы мог объяснять как хорошо тс решает некоторые проблемы, и точно так же меня бы не слушали и говорили, что js - идеален и все типы это лишняя и бессмысленная сложность. Вообще 0 разницы.

Вообще бывают разные варианты. Но не суть - микрофронты часто используют как разбиение по доменам. И даже вы упоминали их в этом контексте. А теперь вдруг доменов нет.

"Домены" это лишь абстракция и иллюзия. А микрофронты разбивают по логическим частям приложения и они не независимы друг от друга, просто разделены но не независимы. Это для меня в порядке вещей, потому что так и должно быть. И не вижу проблем при использовании классики в данном случае.

так же как вы разделяете, что должно лежать в стейте, а что не должно. Использую логику.

Тогда бы вы не использовали FSD.

Если вот этот код имеет смысл в конктексте конкретного сценария в определенной предметной области. и больше нигде - это бизнес логика.

И в чем проблема при использовании классики?

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

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

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

Даже если они говорят, что понимают - они ошибаются

Они "видели" НЛО

во все нет. И там и там это некоторое усложнение чего-то, что бы потом получить профит. То что вы не можете этого осознать - ваша проблема. Примеры были даны.

Опять не верно. Потому что:
- В случае с TS да, ты немного усложняешь и получаешь реальный профит.
- В случае с FSD ты много усложняешь и не получаешь профит, а получаешь только геморрой, борьбу самим с собой, борьбу с папками, борьбу с этой "архитектурой" чтобы каждый раз делая элементарную вещь(но гордо называя её сложной) ты думал как же угадить этому франкенштейну и куче ограничений в довесок.

Более близкая аналогия классики и fsd ещё вот такая:
- Классика это когда ты начал заниматься спортом в меру, как физкультура и реально получаешь профит в виде пользы здоровья, хорошего самочувствия, профилактики сердечных заболеваний, диабета и т.д. и т.п.
- FSD это когда ты ушёл в жесткий бодибилдинг с кусами химии, запредельными весами и т.п. и умер не дожив до 30, и те годы пока ты жил были для тебя пыткой, потому что ты жил в зале, постоянные диеты, двигаться тяжело из-за огромной массы, всё тяжело. А ради чего?

я дал вполне конкретный пример проекта. О чем вы говорите?

Это где просто список папок?) Это даже в таком примере где специально все не сгруппировано и доведено до абсурда всё равно по факту проблем то нет.

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

Что?) Я писал вот это
ctrl + click в помощь. Страница на которой находится "подопытный" в помощь. В ее коде все видно и названий никаких знать не нужно.
Тут не надо ничего помнить и знать, зашли в код интересующей вас страницы нашли что надо. Допустим вам нужен компонент с раскрывающимся списком, он есть на странице X и идет после блока "Описание:", зашли в код этой страницы ctrl+f - "описание" и смотри ниже, там и будет нужный компонент. А если у вас SCSS + CSS modules то прямо в верстке в имени класса будет путь до компонента. Или же React Dev Toolks подскажет название) В общем вариантов масса и все крайне быстрые.

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

ну так выходит, что закрытость методов плохо. Ведь там ровно те же аргументы хза и против) Выходит вы против и приватных методов.

Если не мешает разработке, то по барабану, открыты или закрыты.

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

С тем же успехом я бы мог объяснять как хорошо тс решает некоторые проблемы, и точно так же меня бы не слушали и говорили, что js - идеален и все типы это лишняя и бессмысленная сложность. Вообще 0 разницы.

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

честно говоря думал ответить вам как обыно, так как у вас куча ошибок которые вы не осознаете, но вижу что это бесполезно. Укажу на 2 самых важных моментах:

Вы откровенно врете картинкой. У вас в папке компоненты 200 строк. и так же в hooks. Сделайте нормальную картинку и после этого попробуйте сюда залить и сказать что с этим удобно работать. (И после этого смеете что-то говорить про манипуляции?). У вас так же откровенная манипуляция про скорость разработки в фсд. Стоимость возрастает в разы? То есть вы 1 час пишите компонент, а потом 3 выбираете куда его сложить в фсд? Ухх в таком случае вам нельзя фсд пользоваться.



Вы не можете осознать термин домен и как с ним работать. Из этого вы раз за разом делаете не верные выводы. Более того это показывает вашу неспособность услышать собеседника. Что приводит меня к неутешительному выводу, дисскусия тут бесполезна.


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

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

Пожалуй, я вас на этом оставлю.

У вас в папке компоненты 200 строк. и так же в hooks.

Дык пожалуйста, пускай себе там лежат эти 200 общих компонентов в папке src/components, и даже без группировок. Вот такой у нас проект, много в нем общих компонентов. Что от этого меняется? Алгоритм нахождения нужного компонента/хука/чего угодно не зная названия неизменен, я описывал его выше. И это не имеет отношения к тому, классика или нет. Если в проекте 200 общих компонентов, то они просто будут лежать в папке shared если используется fsd.

Вы откровенно врете картинкой.

И после этого смеете что-то говорить про манипуляции?

Вы писали что по "моей" логике, ничего в папки складывать не надо, можно просто на плоском уровне все пихать и всё. А я просто показал(сотый раз) что я так не делаю и у меня есть папки под конкретные нужны проекта.

У вас так же откровенная манипуляция про скорость разработки в фсд. Стоимость возрастает в разы? То есть вы 1 час пишите компонент, а потом 3 выбираете куда его сложить в фсд? Ухх в таком случае вам нельзя фсд пользоваться.

Во время создания думаете куда что положить, вариантов то масса (features, enities, widgets, shared, pages) боретесь с ограничениями и подстраиваетесь под них, плодите лишние папки просто ради папок, потому что так заведено в fsd. Это всё в довесок даёт минус мораль, что тоже сильно снижает производительность.

Во время условных правок вы во первых ищете все по кусочками разбросанными по всевозможным features, enities, widgets, shared, pages, по бесконечным /ui/ui/ui/ui/ui/ui , опять беретесь с ограничениями, подстраиваетесь под жесткие правила. Этот сценарий всё так же в довесок даёт минус мораль, что тоже сильно снижает производительность.

И это только то, что прям на поверхности, без дополнительных нюансиков в виде код ревью у фанатика fsd, которое проходить каждый раз это целое испытание.

И вот по совокупности всего это bull shit'a да, скорость разработки серьезно страдает и да, минус мораль вносит огромную лепту в это, а не только сам факт убогости fsd.

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

Т.е. вы тот самый проповедник? Вы там самая истина в последней инстанции? Получается вы правы, я не прав, просто потому что вы так решили, лихо однако)

Ещё раз: у вас на картинке обман. Нарисуйте ее нормально и честно где у вас в каждой папке полный список файлов. Я вам даже ральный пример скинул для компонентов

 Если в проекте 200 общих компонентов, то они просто будут лежать в папке shared если используется fsd.

нет не будет. Вы не понимаете как пользоваться инструментом и опять пишите глословные утверждения.

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

Если у меня получается - вы признаете свою ошибку. Если вы не признаете - то мы понимаем что вы раз за разом используете обман и не умеете принимать противоречащие вам факты.

нет не будет. Вы не понимаете как пользоваться инструментом и опять пишите глословные утверждения.

Т.е. в shared не место для общих компонентах приложения которые используются разными его частями сколько угодно раз?) Интересненько

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

Да не вопрос, я в этом не сомневаюсь. Но это не дает профита. В классике их тоже можно легко сгруппировать по папкам. Более того, я их группирую по определённым признакам и у меня нет простыни из 200 компонентов. Не знаю откуда вы это взяли вообще.

Если у меня получается - вы признаете свою ошибку. Если вы не признаете - то мы понимаем что вы раз за разом используете обман и не умеете принимать противоречащие вам факты.

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

Если бы я говорил что классика запрещает группировки и нужно только все папки внутрь src/ засовывать, то да, конечно я бы безоговорочно проиграл.
Но в классике то есть группировка и она ничего не запрещает, какое тут может быть поражение? Хоть группируй сильнее, хочешь слабее, вообще ноу проблемос.

Т.е. в shared не место для общих компонентах приложения которые используются разными его частями сколько угодно раз?)

почему же нет? место. только их будет меньше 30

Да не вопрос, я в этом не сомневаюсь. Но это не дает профита.

погодите вас кудато не туда понесло. Еще раз вы сделали утвердждение:

 Если в проекте 200 общих компонентов, то они просто будут лежать в папке shared если используется fsd.

я вас за язык не тянул. Так выходит оно неверное? так как нет у меня не будет ни в одной папке проекта 30 файлов. Так как у нас получилось из проекта где всего 200 компонентов, вдруг 200 общих компонентов?

 Более того, я их группирую по определённым признакам и у меня нет простыни из 200 компонентов.

вот это поворот. Зачем же вы это делаете? Ведь нет никаких проблем и вы можете спойно прокликать позависомстям? Зачем вы тратите в РАЗЫ больше времни и поддерживаете какую-то структуру. Это же неудобно.

Но в классике то есть группировка и она ничего не запрещает, какое тут может быть поражение?

очередной обман. давай страницу положим в хуки. почему нет-то? или кто это может запретить?

почему же нет? место. только их будет меньше 30

Остальные 170 общих компонентов которые все части системы используют значит выкинули в мусору, умно. (Ниже выясняется что оказывается это были не общие компоненты, а вообще все компоненты в проекте в вашем примере со списком компонентов)

я вас за язык не тянул. Так выходит оно неверное? так как нет у меня не будет ни в одной папке проекта 30 файлов. Так как у нас получилось из проекта где всего 200 компонентов, вдруг 200 общих компонентов?

Так бы и сказали, что это не общие компоненты которые принято держать в папке src/components , а вообще все компоненты в проекте. Они буду распределены по папкам src/components/.., src/pages/.., src/pages/{pageName}/components/.., src/layouts/.. Вот прям как тут, давным давно показано:

вот это поворот. Зачем же вы это делаете? Ведь нет никаких проблем и вы можете спойно прокликать позависомстям? Зачем вы тратите в РАЗЫ больше времни и поддерживаете какую-то структуру. Это же неудобно.

Посмотрите дату где впервые скриншот появился. Какой "вот это" поворот? Это то, как я с 2017 года группирую файлы и папки.

очередной обман. давай страницу положим в хуки. почему нет-то? или кто это может запретить?

Ну если лично вы хотите, кладите, ваш проект, ваши правила) Я страницы кладу в pages) Самое название pages наверное о чем-то говорит да?)

Остальные 170 общих компонентов которые все части системы используют значит выкинули в мусору,  оке

окей, давайте допустим, что у нас 200 общих компонентов. На вскидку мне не приходит на ум никаких общих компонентов, кроме ui-kit. То есть у вас кит на 200 (что скорее всего указывает на его плохое проектирование). Если у вас такой только кит, то смело предположу, что весь проект содержит минимум 2000 компонентов.

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

у вас в компонентс лежит 2200 компонентов. половина из которых имеет смысл только в контексте других компонентов.

И вы говорите, что ваш шаред (ой простите, компонентс) лучше.

Вы наверное из любителей создавать классы на 100 методов?

Так бы и сказали, что это не общие компоненты которые принято держать в папке src/pages/{pageName}/components , а вообще все компоненты в проекте

тогда тем более не понятна ваша логика и спор. Как я и сказал - ваши страницы выступают в роли слабо сформированных доменов. С ростом проекта - когда станет понятно, что есть несколько страниц использующие одни и те же компоненты, то будет желание либо вынести эти компоненты в /components, либо создать домен, в котором будут лежать и эти страницы и компоненты.

Судя по вам вы предпочтете первое, и я показал на примере к чему это приводит.

) Я страницы кладу в pages

воот, а говорите правил и ограничений нет. Ведь на ревью вы запретите человеку класть страницы в хуки.

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

Так зачем вы тратите в разы больше времени на пооддержание этой структуры, и решаете проблемы которых нет? вы сами сказали что поиск компонента и зависимостей делаются через ctr.

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

И у меня, только в src/components

у вас в компонентс лежит 2200 компонентов. половина из которых имеет смысл только в контексте других компонентов.

Нет. Все они распределены и сгруппированы.

С ростом проекта - когда станет понятно, что есть несколько страниц использующие одни и те же компоненты, то будет желание либо вынести эти компоненты в /components, либо создать домен, в котором будут лежать и эти страницы и компоненты.

Судя по вам вы предпочтете первое, и я показал на примере к чему это приводит.

К чему? К фейковым мыслям что в src/components на одном уровне вложенности будет лежать 2200 компонентов из ваших фантазий? :D

Я не создаю "домены" и не вызываю пиковую даму и т.п. Я делаю группировку исходя из логики и здравого смысла.

воот, а говорите правил и ограничений нет. Ведь на ревью вы запретите человеку класть страницы в хуки.

Настолько банальные до абсурда вещи опускаются когда речь идёт о ограничениях. Разумеется никто не будет класть страницу в хуки или utils.

Так зачем вы тратите в разы больше времени на пооддержание этой структуры, и решаете проблемы которых нет?

Я не трачу на нее время. Мне НЕ надо думать а вот это, это что, "демон" или widget или feature или entity или shared или пиковая дама или /ui/ui/ui/ui/ui .. А вот точно ли это entity? а может все таки feature. Ну ладно, а потом бац и на код ревью fsd фанатик говорит, а не, это вообще widget и ещё ты не достаточно много /ui/ui/ui/ui/uiнасоздавал, нужно больше.

У меня всё элементарно:
Страницы сразу идут в src/pages
Общие компоненты сразу идут в src/components
Лейауты сразу идут в src/layouts
Вложенные компоненты сразу идут в ./components

Тут 0 дилем, 0 спорных моментов, 0 недопониманий. Поэтому умножаем на коэффициент 0 и получаем 0 extra time на ведение и поддержание архитектуры.

Нет. Все они распределены и сгруппированы.

ну как же? вот вы говорите вы сложили их в страницы. Браво. У нас 3 страницы используют один и тот же компонент. Вы его куда кладете? в общие компоненты, или каждая страница лезет в код страницы другой?

В первом случае у вас разбухает /components/
Во втором все еще веселее пространство потенциальных компонентов теперь лежит не только /components, но и во всех страницах.

То есть у вас в любом случае число компонентов лежащих на верхнем уровне выше чем у меня. И при росте проекта соотношение становится только хуже.

Настолько банальные до абсурда вещи опускаются когда речь идёт о ограничениях. Разумеется никто не будет класть страницу в хуки или utils.

но это тем не менее ограничение. Так зачем оно нужно? Вы сами сказали что ограничений нет.

Я не трачу на нее время. 

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

Более того вам еще нужно подумать куда его положить:
/components/chat/ или в /pages/chatHistory/components

так, что лукавите вы про отсуствие накладных расходов. Они есть.

Опять вопрос: зачем они нужны, если вы все равно не используете навигацию по папкам.

Более того вы сказали, что иногда объединяете компоненты внутри компонентов. Это тоже время:

  1. вы должны прийти к решению, что это изменение нужно

  2. вы должны создать папку и перенести файлы

  3. вы должны поправить пути (если иде не отработало)

  4. в идеале это должно идти отдельным коммитом, а то и пр что бы ревьюить было проще.

вот сколько дел, что бы поддерживать вашу группировку. Ненужно лукавить

ну как же? вот вы говорите вы сложили их в страницы. Браво. У нас 3 страницы используют один и тот же компонент. Вы его куда кладете? в общие компоненты, или каждая страница лезет в код страницы другой?

В src/components/.. , если он может быть сгруппирован по какому-то признаку, то в src/components/group_by/...

В первом случае у вас разбухает /components/

И что теперь?) Пускай.

То есть у вас в любом случае число компонентов лежащих на верхнем уровне выше чем у меня

Потому что я не прячу их туда, где сложно найти, они лежат там, где должны лежать общие компоненты. На то они и общие.

И при росте проекта соотношение становится только хуже.

Ну это лично у вас) У меня нет) У меня как и большинства не проблем с навигацией) Это примерно 0.1% времени)

 Так зачем оно нужно? Вы сами сказали что ограничений нет.

Если вам говорят что у нас в офисе дресс кода нет(т.е. вам не говорят что надо именно в рубашке с галстуком ходить) вы же не идёте туда в одних труханас и сланцах, потому что на улице +30. Вы же понимаете(надеюсь) что о настолько базовых ограничениях в явном виде просто специально не говорят и не берут их в расчет?

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

Для меня нет разницы) 1 секундой больше, одной секундой меньше) Мышку опустить чуть ниже или чуть выше)

Более того вам еще нужно подумать куда его положить:/components/chat/ или в /pages/chatHistory/components

Зачем? Если компонент используется больше чем на в одном месте, то он без раздумий идет в src/components , если я его создаю специально для этой страницы, то он без раздумий ложится в src/pages/my_page/components . Так что думать не нужно) Ну как, то что занимает подсознательно 1 секунду, я в расчет не беру) А скажете что нельзя не думать и при этом название папке давать например)

так, что лукавите вы про отсуствие накладных расходов. Они есть.

Да нет, нету.

Более того вы сказали, что иногда объединяете компоненты внутри компонентов. Это тоже время:

Ну да, время, только ничтожно малое в сравнении с накладными расходами fsd. Поэтому оно в расчет не берется.

вот сколько дел, что бы поддерживать вашу группировку. Ненужно лукавить

И даже эти дела в классике (0.1% времени это если прям преувеличить, а так 0.001% скорее), занимают ничтожно малую часть по сравнению с накладными расходами fsd.

Одни только споры с fsd фанатиками на код ревью по поводу widgets, features, entities, fetuares, shared, ui/ui/ui/ui/ui чего стоят и сколько времени и нервов съедают.

Вы писали что по "моей" логике, ничего в папки складывать не надо, можно просто на плоском уровне все пихать и всё. А я просто показал(сотый раз) что я так не делаю и у меня есть папки под конкретные нужны проекта.

все верно, вы сказали: что бы мне чтото найти я захожу на страницу и кликаю по нужной зависимости. Согласно таким рассуждениям - классическое разбиение избыточно, так как в не пользуетесь навигацией по папке кроме как найти нужную страницу. Вам вполне хватит только наличие папки pages. А вы городите что-то непонятное тратя В РЫЗЫ больше времени. зачем вам столько отдельных папкок? плодите всякие /components /hooks и т. п. (искользую ваши методы против вас)

Ну вы утрируете сильно и драматизируете) У вас просто фанатичное помешательство на FSD и папках, а я группирую все так, как диктует здравый смысл и логика) А не ограничения и правила которые силой мне решил навязать какой-то сайтик где хранится описание Freaky Sliced Design.

Ну вы утрируете сильно и драматизируете)

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

Так почему же мы не можем все сложить в общую папку (кроме страниц), а вдруг должны делать какое-то разбиение (использующее вашу логику). Давайте все сложим на верхнем уровне кроме страниц. Ведь вы сами сказали, что разбиение не важно, так как оно не решает никаких проблем. Так зачем оно вам нужно (ваше логичное и правильное разбиение), если вы все равно через ctr + клик навигируете? Зачем на его поддержку вы тратите в РАЗЫ больше времени, и героически превозмогаете проблемы которых нет? (интересно, а вы тут себя уже узнали, или нет?)

А не ограничения и правила которые силой мне решил навязать 

что-то вас совсем в манипуляции понесло.

Зачем на его поддержку вы тратите в РАЗЫ больше времени, и героически превозмогаете проблемы которых нет? 

Я не знаю о чем вы, у меня нет проблем, и не было) Я хоть говорил что у меня есть какие-то проблемы?) Я ничего не превозмогаю, потому что нет объекта превозмогания) У меня же архитектура здорового человека используется на проектах)

Так почему же мы не можем все сложить в общую папку (кроме страниц), а вдруг должны делать какое-то разбиение

Складывайте если хотите)

(использующее вашу логику).

У меня нет такой логики) Я сто раз показывал скриншот как я группирую файлы и папки) Ваши фантазии не знаю)

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

Моего разбиения хватает выше крыше) А всё сверх этого уже избыточно и ничего не решает, а только создает) См. скриншот которой я сто раз скидывал.

Так зачем оно вам нужно (ваше логичное и правильное разбиение), если вы все равно через ctr + клик навигируете?

Потому что в классике оно сюрприз логическое и интуитивное. А это мы одобряем и всю жизнь одобряли.

Я не знаю о чем вы, у меня нет проблем, и не было)

ну так вы же тратите время разпределяя файлы. Значит вы решаете какую-то проблему этим. Вы же реалист и не делали бы это просто так? Куда вы юлите - зачем вы делаете вашу архитектуру "здорового" человека? (кстати распределение папокй - это не архитектура)


Складывайте если хотите)

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

У меня нет такой логики) Я сто раз показывал скриншот как я группирую файлы и папки) Ваши фантазии не знаю)

погодите, вы сами сказали, что

ctrl + click в помощь. Страница на которой находится "подопытный" в помощь. В ее коде все видно и названий никаких знать не нужно.Тут не надо ничего помнить и знать, зашли в код интересующей вас страницы нашли что надо.

так согласно этой логике - нам ничего не нужно кроме как найти страницу. Или это не ваша логика? Если нам нужно найти только страницу, то вообще не важно где лежит остальное и как.

Так зачем вы тратите время, на ваше "здоровое" распределение?

Моего разбиения хватает выше крыше) 

так и ваше не нужно, так как оно не решает никаких проблем)

Потому что в классике оно сюрприз логическое и интуитивное.

Конечно, то что для вас не понятно - нелогично для вас. Только проблема не в том, что оно не логичное, а в том что вы не поняли и даже не хотите понимать

Так вы ответите зачем вы тратите в разы больше времени на вашу "архитектуру", если она не дает профитов и мы легко находим код и без такого распределения папок (согласно вашим собственным утверждениям)

ну так вы же тратите время разпределяя файлы. Значит вы решаете какую-то проблему этим. Вы же реалист и не делали бы это просто так? Куда вы юлите - зачем вы делаете вашу архитектуру "здорового" человека?

У меня все проблемы решены много много лет как)

(кстати распределение папокй - это не архитектура)

Знаю, просто для вас папки как мана небесная) Вы целую религию вокруг них построили)

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

Мне классика дает профит, я ни разу не говорил что она не дает профит. И я с её помощью экономлю много времени и нервов, иначе я бы ей не пользовался) Если захочу самобичевания и депрессии, то возьму FSD.

У меня все проблемы решены много много лет как)

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

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

отлично, как вы экономите ресурсы? уже наверное 10 раз спрашиваю, а вы все юлите. Ведь, по вашим словам вам главное найти папку со страницами, а все остальное не важно.

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

Проблем не было) Просто до этого другие вариации организации кода были, и в эти моменты тоже не было проблем, потому что в 2016 моей первый проект на реакте уже был фактически интуитивно построен на классической архитектуре) А до этого я на PHP писал, там своя организация кода была)

отлично, как вы экономите ресурсы?

Используя классику)

Ведь, по вашим словам вам главное найти папку со страницами, а все остальное не важно.

Когда я понятия не имею что за компонент мне нужен и где он лежит да, а ещё SCSS + CSS modules отлично помогают, React Dev Tools тоже) В остальных случая я просто знаю где лежит интересующий меня код и сразу открываю его)

все верно, вы сказали: что бы мне чтото найти я захожу на страницу и кликаю по нужной зависимости

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

Согласно таким рассуждениям - классическое разбиение избыточно

А мне не избыточно, мне нормально)

так как в не пользуетесь навигацией по папке кроме как найти нужную страницу

Конечно, и не пользуюсь IDE и не пользуюсь компьютером тоже.

Вам вполне хватит только наличие папки pages

Мне маловато будет)

Мне маловато будет)

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

Так зачем же? какую проблему решила ваша группировка?)

а что маловато? куда вы юлите? вы сказали, что вам главное найти страницу, а дальше вы прокликаете куда нужно

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

Но вы зачем-то тратите ресурсы на поддержание вашей структуры.

Я не трачу) Она не накладывает расходов, базовые в расчет неберем типо напечатать название файла/папки)

Так зачем же? какую проблему решила ваша группировка?)

У меня никогда не было проблем с организацией кода и навигацией, со времени 2012 года и php) Я сразу на интуитивном уровне создавал папки так, чтобы с ними было удобно работать)

Я не трачу) Она не накладывает расходов, базовые в расчет неберем типо напечатать название файла/папки)

погодите, это все равно расходы. Еще раз зачем вы их делаете если они не нужны? Почему вы внятно ответить на этот вопрос не можете? Если они нужны, то будет интересно услышать, аргументы.

более того вы слукавили когда сказали что думать совершенно не нужно. Я дал вам конкретный пример:

Более того вам еще нужно подумать куда его положить:
/components/chat/ или в /pages/chatHistory/components

Более того вы сказали, что иногда объединяете компоненты внутри компонентов. Это тоже время:

  1. вы должны прийти к решению, что это изменение нужно

  2. вы должны создать папку и перенести файлы

  3. вы должны поправить пути (если иде не отработало)

  4. в идеале это должно идти отдельным коммитом, а то и пр что бы ревьюить было проще.

Так что хватит юлить, вы тратите какое-то время на какое-то распределение. Но пока ни одного плюса этого распределения не назвали. Но почему-то вы другое распределение назвали плохим, хотя вы не понимаете как им пользоватся.

Логика ваших ответов потерялась. Вам задают вопрос -какие преемущества привносит классика, в сравнении с хаосом и папкой pages? какие проблемы она решает?

  • никаких проблем нет и не было.

отлично значит нет смысла ее использовать, раз она никакие проблемы не решает)

Что и как она ускоряет?

  • она ускоряет за счет использования класики!

Гениально!

- Ты где деньги берешь?

- В тумбочке.

- А откуда они там?

- Жена кладет.

- А у нее откуда?

- Я даю.

- Ну а ты-то где их берешь?

- В тумбочке...

более того вы слукавили когда сказали что думать совершенно не нужно. Я дал вам конкретный пример:

Более того вам еще нужно подумать куда его положить:/components/chat/ или в /pages/chatHistory/components

Уже ответ именно на это
Уже ответ именно на это

https://habr.com/ru/companies/doubletapp/articles/870236/comments/#comment_27831846

Более того вы сказали, что иногда объединяете компоненты внутри компонентов. Это тоже время:
И дальше по тексту

Тоже отвечал там же)

https://habr.com/ru/companies/doubletapp/articles/870236/comments/#comment_27831846

Но пока ни одного плюса этого распределения не назвали.

Сделайте ctrl+f по этой странице по слову "интуитивно", увидите все места где я называл плюсы классики.

Но почмеу-то вы другое распределение назвали плохим, хотя вы не понимаете как им пользоватся.

спасибо. Комментарии на хабре просто ужасны и сложно отлеживать, что к чему.

Погодите, мы сравниваем сейчас не fsd против классики, а классику против хаоса с выделенными pages, для простоты назовем ее хаоситное распределение. (у меня распределение по фсд так же почти не занимает времени, так как я понимаю как распределять файлы)

Ну так вы все равно думаете, и складываете, и еще переодически перераспределяете. Это все еще расходы.

Вот даже конкретный кейс: вы сказали, что иногда объединяете компоненты внутри компонентов. Это тоже время:

  1. вы должны прийти к решению, что это изменение нужно

  2. вы должны создать папку и перенести файлы

  3. вы должны поправить пути (если иде не отработало)

  4. в идеале это должно идти отдельным коммитом, а то и пр что бы ревьюить было проще.

Сделайте ctrl+f по этой странице по слову "интуитивно", увидите все места где я называл плюсы классики.

поискал.

 То, что классика все всём лучше, это да, тут всё однозначно

ну так и в хаоситном распределение все понятно, и вообще никак нельзя ошибиться: страница? кладем в страницы. Не страница? кладем в кучу. Все равно по кликам находим и посику находим. Более того даже перераспределение не нужно. Мне не нужно иногда объединять несколько компонентов в папку, или вытаскивать из страницы общий компонент в общие.

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

Погодите, мы сравниваем сейчас не fsd против классики, а классику против хаоса с выделенными pages

Мне не интересен хаос и сравнения с ним) Я использую классику. Тут речь про сравнению классики с Freaky Sliced Design.

Это мы еще не разобрались зачем мы вообще классику используем

Затем что она покрывает абсолютно все сценарии и размеры проектов. И не накладывает чрезмерных ограничений и т.п. Все остальные вариации на фронте против классики хуже. Вот почему мы ее так любим и используем.

Можно кейсы где видно облегчение жизни от ее использования?

Плюс отсутствие чрезмерных ограничений и запретов.
Плюс она интуитивно понятна всем и всегда.
Плюс сделайте ctrl+f по этой странице по слову "интуитивно", увидите все места где я называл плюсы классики.

Этого более чем достаточно.

Мне не интересен хаос и сравнения с ним)

не ну вы же рациональный человек. или уже нет? Вы сказали что не хотите тратить ресурсы поддержание структуры. И я вам предложил другое распределение, в котором явно будет меньше затрат на ее поддержаие (причем, я даже привел конктретные кейсы, когда у вас даже пул реквесты становится тяжелее из-за необходимости поддержки структуры). Так почему же как фанатик уцепились за менее экономически обоснованный инструмент? Или в нем есть какие либо обоснования?

Вы продолжаете юлить.

Затем что она покрывает абсолютно все сценарии и размеры проектов.

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

Я показал на простейшем примере как у вас папка components растет в разы быстрее моего shared, и это только один из примеров.

нет, она не удобна на действительно больших проектов

Нет, увы и ах. Удобна, более чем. И намного намного более приятна в использовании.

 на которых вы не хотите работать и судя по всему вы не умеете с ними работать.

Не хочу утопать в говнокоде, бюрократии, пул реквестах длящихся вечность, постоянный конфликтах в коде и т.д. и т.п.

Я показал на простейшем примере как у вас папка components растет в разы быстрее моего shared, и это только один из примеров.

Нет, не растет быстрее. Кол-во компонентов в src/components равно кол-ву общих компонентов. В вашем shared их будет ровно такое же количество. Это в вашей выдуманной хаос архитектуре растет, где все лежит в src =)

Удобна, более чем. И намного намного более приятна в использовании.

нет, не удобна.

Долго будем таким перекидываться? Более того откуда вам знать если для вас большие проекты не приятны, не удобны и работать вы с ними не хотите?

постоянный конфликтах в коде...

понимаю. Если с инструментом не уметь работать - то все так и будет. Правда тут проблема в том кто его использует.

Нет, не растет быстрее. Кол-во компонентов в src/components равно кол-ву общих компонентов.

вы опять не читаете и опять делаете утверждения не понимая на что вам указали. У меня есть общие компоненты для проекта - они действительно лежат в компонентах. И по сути это только ui-kit. У вас же любой компонент который используется больше чем в одном месте - там оказывается. То есть у вас в компонентс свалка растет прямо пропорционально росту проекта и зависимостей в функционале.

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

 Это в вашей выдуманной хаос архитектуре растет, где все лежит в src =)

Все верно, ведь по вашим сценариям и доводам в пользу классики - это не проблема. Соотвественно, я и предложил вам продолжить оптимизацию, ровно в соответствии с вашей аргументацией.

Ну и повторим:

Вы же рациональный человек. или уже нет? Вы сказали что не хотите тратить ресурсы поддержание структуры. И я вам предложил другое распределение, в котором явно будет меньше затрат на ее поддержаие (причем, я даже привел конктретные кейсы, когда у вас даже пул реквесты становится тяжелее из-за необходимости поддержки структуры). Так почему же как фанатик уцепились за менее экономически обоснованный инструмент? Или в нем есть какие либо обоснования?

Вы продолжаете юлить.

Более того откуда вам знать если для вас большие проекты не приятны, не удобны и работать вы с ними не хотите?

Я работал на таких, и там была классика и никаких проблем касаемо архитектуры не было и в помине.

вы опять не читаете и опять делаете утверждения не понимая на что вам указали. У меня есть общие компоненты для проекта - они действительно лежат в компонентах. И по сути это только ui-kit. У вас же любой компонент который используется больше чем в одном месте - там оказывается.

OMG что за бред опять. Вы называете компонентами всё на свете. Страницы, лейауты, реальные компоненты. Но я не удивлюсь если вы и функции с хуками компонентами называете. Группировка, слышали о таком? Уже тысячный раз

src/components/formComponentns/...
src/components/cartSpecific/...
src/components/whatEvenrYouWant/...

У меня же эти компоненты лежат в домене. Так что нет вы абсоютно не правы.

Бла бла бла. Что за "домен", что за компоненты, с какого перепуга в классике все на свете должно быть в src/components на верхнем уровне... У вас уже FSD головного мозга зашкаливает. Вы теряете связь с реальностью.

Ну и повторим:

Вы же рациональный человек. или уже нет? Вы сказали что не хотите тратить ресурсы поддержание структуры. И я вам предложил другое распределение, в котором явно будет меньше затрат на ее поддержаие (причем, я даже привел конктретные кейсы, когда у вас даже пул реквесты становится тяжелее из-за необходимости поддержки структуры). Так почему же как фанатик уцепились за менее экономически обоснованный инструмент? Или в нем есть какие либо обоснования?

Вы продолжаете юлить.

Это просто белая горячка. Я использую классику, точка. Именно ее структура и архитектура это идеальное сочетание. Всё остальное это перегиб. Поэтому ни какими хаос архитектурами из ваших фантазий я не пользуюсь и уж тем более fsd.

Я работал на таких, и там была классика и никаких проблем касаемо архитектуры не было и в помине.

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

Вы называете компонентами всё на свете. Страницы, лейауты, реальные компоненты.

небыло такого.

 Группировка, слышали о таком? Уже тысячный раз

конечно. И все это все еще лежит у вас в shared, и является "публичным апи" для вашего проекта.

А у меня это там не лежит, а распределено по доменам.

То есть у меня /components в разы уже ваших.

Бла бла бла. Что за "домен", что за компоненты,

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

 с какого перепуга в классике все на свете должно быть в src/components на верхнем уровне...

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

Я использую классику, точка. 

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

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

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

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

Вот поэтому больше и не работаю, т.к. не приятно. Уже поработал, хватит)

конечно. И все это все еще лежит у вас в shared, и является "публичным апи" для вашего проекта.

А у меня это там не лежит, а распределено по доменам.

То есть у меня /components в разы уже ваших.

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

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

микрофронты и все проблемы махом испаряются.

Поэтому в очередной раз повторяю вопрос: что привносит классика в виде улучшения на проект в соотношении с ее отсутствием?

Её структура, простота и никаких вредных ограничений.

Вот поэтому больше и не работаю, т.к. не приятно. 

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

микрофронты и все проблемы махом испаряются.

круто и микрофронты как и микросервисы зачастую все делят на домены. Но домены это зло и их не существует)

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

Вообще по барабану, 

странно, то вы жаловались что толстый шаред - это плохо. А как увидели что он на классике в три раза хуже - так сразу по барабану)

Её структура, простота и никаких вредных ограничений.

Она хорошая так как хорошая. Гениальная аргументация. Кейс хоть один будет? что она дарит в отношении с распределением хаоситов?

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

Нет)

круто и микрофронты как и микросервисы зачастую все делят на домены. Но домены это зло и их не существует)

Микрофронт, как и микросервис вещь совершенно конкретная.

Самое интересное, что распределение как микрофронтах можно получить и без них

Только без бонусов, которые дают микрофронты в виде отсутствия(или сведенного к минимуму) вот этого:

не получив в довесок кучу проблем

Эти "проблемы" с лихвой окупаются их преимуществами. Я выбираю перевес в преимуществах)

странно, то вы жаловались что толстый шаред - это плохо. А как увидели что он на классике в три раза хуже - так сразу по барабану)

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

Она хорошая так как хорошая. Гениальная аргументация

Учусь у проповедника и на 4 ставки фанатика fsd)

Кейс хоть один будет? что она дарит в отношении с распределением хаоситов?

Вот вам кейс и то как она выглядит. Дальше мысленный эксперимент и всё встает на свои места.

Нет)

Да. От того что что-то назвали хорошим, оно таковым не стало.

Микрофронт, как и микросервис вещь совершенно конкретная.

То есть с абстракциями и терминами вы не можете работать. Понимаю почему вы не смогли с доменом разобраться.

Эти "проблемы" с лихвой окупаются их преимуществами

Вы вообще знаете о чем говорите? Можно три главных плюса, и минуса микросервисы, а то не похоже что вы о чем говорите и что сравниваете.

Я   не жаловался

Странно. То есть не вы писали как не хотите работать на больших старых проектах с большой кодовой базой.

это вы жалуетесь что большой проект(много компонентов) это

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

Вот вам кейс и то как она выглядит

То есть с термином "кейс" вы не знакомы? Или каким образом у вас абстрактный недопример или схема стала кейсом.

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

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

Как юлили так и юлите

Вот поэтому больше и не работаю, т.к. не приятно.

Ну так у вас конфликты, долгие реквесты и говнокод вытекал из-за плохой архитектуры (и не только)

Что возвращает нас к тому, что вы не понимаете как эффективно настраивать и работать в больших проектах, но уверенно рассказываете другим - как нужно работать. Причем именно тем кто работал в больших проектах и решил те проблемы, которые вы не смогли. Это же насколько нужно быть самоуверенным в своей правоте и гнуть свою линию, не слушая собеседника?

"Главное ничего не надо изучать" - очень хорошо сказано, и в целом ёмко характеризует ваш посыл xD

Крутая статья!!! Только некоторые моменты смущают. Отпишу, чтобы показаться умным xD:

  1. «useMyComponent.ts (для компонентов с бизнес логикой)» - смутило то, что какая-то часть бизнес-логики пишется в хуках, хотя у вас уже есть для этого стейт-менеджер (zustand). Такую "бизнес-логику" сложно отдирать от юайной логики, особенно если кто-то напичкает в этот хук useEffect'ов

  2. То что можно делать папки components любой вложенности тоже не понравилось. Имхо, но лучше делать одну папку components для компонента и уже в ней создавать остальные компоненты. Проще понять какие самописные компоненты используются и не надо погружаться в ад из папок components

  3. «Пример — тип, описывающий HTML-форму, у которой набор полей на фронтенде не совпадает с моделью бэкенда» - звучит как несоблюдение контракта. Без единого источника истины возникают разного рода конфликты

  4. Написание своих моделей и клиента (функций для взаимодействия с бэком) очень геморный процесс. Можно генерировать по свагеру на фронте модели и клиента, что позволит мгновенно синхронизировать контракт с бэком. Также можно настроить мок-сервер и api-first, но это большая работа)

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

  2. Идея в том, чтобы инкапсулировать компоненты по тем зонам, к которым они относятся. По той же логике, условно, можно положить все компоненты приложения на один уровень /components. Но от этого мы и пытаемся уйти)

  3. Это не всегда так. Иногда бывает, что фронтовая форма имеет только клиентские поля. Например галочка "Я принимаю условия...", которая служит для валидации. В таком случае типы будут различаться.

  4. Это следующая проблема, о которой мы задумываемся, но пока что инструмента, который будет отвечать всем требованиям для нас мы не нашли. Возможно скоро мы это исправим)

То что можно делать папки components любой вложенности тоже не понравилось. 

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

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

Одно из главных отличий FSD от вашей архитектуры как раз то, что FSD старается оперировать бизнес сущностями, а все остальное лежит shared. Ну и как подметили ребята в комментариях FSD это больше методология, которая не может четко описать то, как все должно лежать

Но на практике, fsd это мертворожденная и вредная штука. Чего не скажешь о классической архитектуре.

Архитектура на реакте? А оно вам надо?

Если проект большой и надо реально думать над архитектурой, то надо брать точно не реакт.

Как начинаешь новый frontend проект, так начинается все сначала: какие папки, как назвать, что такое компонент, слой, фича и т.д. и т.п. В одном проекте это согласование заняло около месяца! Уже бэк успели сделать, а все шли дебаты.

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

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

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

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

Конкретный пример в студию, который может показать что эти слова похожи на истину, ибо я вообще не вижу проблемы, а вы пишете что все в ступоре.
Как так? Непонятно.
В чем проблема разработать новый дизайн? Берешь и делаешь новый дизайн.
Что конкретно вы имеете в виду под "разработать новый поход"?

такого никто не делал и интерфейса ещё в природе нет. В чем проблема опять же? Берешь и делаешь как обычно.

А плясать нужно от бизнеса, от природы вещей - сущностей.

Не вижу выгоды для разработки примерно нисколько. Просто вы так решили и всё.

А сущности могу не иметь UI отображения и тогда совсем беда...

И что? Почему беда? В чем проблема?
Например нужно в фоне отправить аналитику, да, тут нет отображения, но я не понимаю почему это вдруг стало бедой?

Про выгоду разработки от бизнесового домена. Легче менять какую-то бизнесовую логику и есть чёткое разграничение между ui и бизнес-логикой. Постановки чаще всего летят от аналитиков, а не от дизайнеров. Луковая архитектура, ddd - также предлагают бизнесовый домен делать независимым от всего, ядром архитектуры.

Про выгоду разработки от бизнесового домена. Легче менять какую-то бизнесовую логику и есть чёткое разграничение между ui и бизнес-логикой. Постановки чаще всего летят от аналитиков, а не от дизайнеров.

Так и не увидел никакой выгоды. Крайне не убедительные слова не подкрепленные ни одним конкретным примером который можно проверить/воспроизвести. Более того, даже не понятно с чем вы сравниваете? Почему вы решили, что объект вашего сравнения это какая-то мешанина где вся логика описана внутри div'a или как там вы себе представляете как обычно люди пишут код?

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

Всё равно не вижу плюсов, только минусы из-за введения лишних абстракций и ограничений. И строить архитектуру приложения вот так, без привязки к удобству/простоте/легкости/понятности написания кода это конечно жесть. Во главе угла должны быть KISS и YAGNI прежде всего.


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

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

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

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

Откуда вы взяли кучу? Откуда вы взяли свалку? Где тут куча? Где тут свалка?

Всё разбито на логические уровни.

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

Допустим хук получения списка товаров активного заказа вы как в этой схеме расположите?

Вот

src/
  globalState/
    orderState/
      index.ts

Где в упрощенном виде orderState:

import { makeAutoObservable } from 'mobx';

class OrderState {
  activeOrderFetching = false;
  activeOrder: IOrder = null;
  
  constructor() {
    makeAutoObservable(this);
  }

  fetchActiveOrder = async () => {
    this.activeOrderFetching = true;
    this.activeOrder = await apiRequest(`GET /api/active_order`);
    this.activeOrderFetching = false;
  }

  checkout = () => { //... }
  anyOtherMenthod = () => { //... }
}

// Глобальное состояние заказов, 
// к ним есть доступ у всех и из любого места
export const orderState = new OrderState();

отлично, то есть у вас оно в глобальное пространство уходит. И как я понимаю компоненты отвечающие за его отображение так же уходят в глобальную папку components?

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

И как я понимаю компоненты отвечающие за его отображение так же уходят в глобальную папку components?

Его могут использовать все кому надо.
Вcе страницы, лейауты, общие компоненты, локальные копоненты внутри страницы и т.п.
src/compoentns
src/layouts
src/pages
Вообще все кто захочет, ограничений и запретов нет и в этом огромный плюс и удобство.

import { orderState } from 'globalState/orderState';

И вперед

И строить архитектуру приложения вот так, без привязки к удобству/простоте/легкости/понятности написания кода это конечно жесть.

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

Так и не увидел никакой выгоды. Крайне не убедительные слова не подкрепленные ни одним конкретным примером который можно проверить/воспроизвести.

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

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

Вы усложняете все и накладываете оверхед по умолчанию на все сценарии и весь процесс разработки, ради того, чтобы потенциально выиграть 10-15% времени для одной задачи из ста и то не факт, что такой кейс настанет, а я выстраиваю архитектуру чтобы выигрывать в 99 реальных задачах из 100. Суммарно экономия времени, ресурсов и усилий на разработку в классической архитектуре намного больше, т.к. в ней нет нужны специально усложнять простые вещи. Вот и все. Keep It Simple и всё будет шикарно, каким бы сложным и большим не был бы проект. Тем более далеко далеко не все проекты реально настолько большие и сложные, это больше исключения, чем правила. Другой вопрос если их намеренно переусложнить введя кучу слоев абстракций, то да, простой проект станет сложным. Когда оперируешь конкретными вещами, а не абстрактными, то всё просто на самом деле.

Покажите мне проект с 5+ лет жизни и затронутый больше 10 разработчиками с классической архитектурой и кучей бизнес-логики, который легко поддерживать и масштабировать

Я работал на таких проектах, но их основная сложность не в том, что в них классическая архитектура или ddd или fsd или что угодно, а в том, что в них сложная и большая бизнес логика. А сложную и большую бизнес логику нельзя упростить если на то не будет согласие бизнеса. А следовательно, реальная сложность обуславливается не структурой файлов и папок и тем, мыслим мы доменами или конкретными вещами. Всё что мы можем, дополнительно не усложнять и не усугублять без того сложную бизнес логику дополнительными слоями абстракций. Тем самым выигрывая время и нервы.

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

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

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

Если вы рассматриваете микрофронты как адекватное решение которое приносит бенефиты на большой проект, то почему вы так сильно выступаете против разбиения не домены?

Микрофронт как относительно самодостаточное отдельное маленькое приложение это не тоже самое что огромный монолит который пытается это имитировать. У каждого микрофронта могут быть свои архитектурные особенности и подходы, что дает свободу, гибкость и развитие. Главное что каждый отдельный микрофронт может обслуживать только один разработчик, чем больше людей пишут в одну и ту же репу параллельно, тем хуже. Каждый человек ас на проекте пока он 100 процентный хозяин кода, и он работает максимально эффективно и комфортно, а когда это нарушается, то падает эффективность и комфорт. И я не то чтобы против разбиения не домены как таковые, просто это вводит дополнительные ограничения и неудобства, я как раз прежде всего против ограничений и неудобств.

В этом треде вы что-то в абстракции ушли) На деле оба за домены, просто в классической структуре домен это `pages/somePage`, а в фсд это сгруппированно в некую features или виджет или куда там еще. Конечно, в классической все удобнее - можно решить на уровне роутера. Допустим, некая страница разрослась до больших размеров и у нее десяток связанных подстраниц, решили выделить в отдельный проект - в этом случае выносится только папка страницы

const routes = createRouterConfig({ 
  maning: { 
    path: '/maning/*', 
    // loader: () => import('./pages/maning'), 
    loader: () => import('https://some-url/component.js'), 
    props: { globalComponents, globalApi, globalActions, globalStores } 
  } 
});

Вот и получился микрофронт. Внутрь переданы пропсы с глобальными слоями, которые микрофронтом кладутся в контекст и используются оттуда вместо es-импортов (ts-типы линкуются разными способами). При этом он внутри по той же самой "классической" структуре имеет те же самые папки, просто все его слои работают только внутри этого микрофронта.

Это прекрасно ложится на большие проекты.

Все верно вы говорите: действительно на многих проектах домены легко связываются со страницами. Но если она уже выросла до десятка подстраниц, верно ли ее всё ещё называть "страница"? Более того бывает функционал который вообще страниц не имеет, а только виджеты или компоненты.

Мы конечно можем выделить это в микрофронт, но какой в этом смысл? Его настройка сложнее и зачастую ведёт к накладным расходам. В то время как выделение домена в рамках монорепы - максимально простое, позволяет быстро обновлять связи интерфейсы и подключать новые через обычный импорт экспорт. И в том числе использовать общие библиотеки.

Я не против микрофронтов, они классные если нам нужно решить проблему с разделением релизов между командами. Но применять их только ради разбиения кода по доменам? Кажется все тоже самое можно сделать и без микрофронтендов, но проще.

Я попытаюсь разложить для себя и ответить.

  1. Проблема наименований в роутере и в проекте - в проекте 200 страниц, из них нужно сгруппировать 10, и это не ложится в термин "страница". Здесь ключевое - "нужно сгруппировать", то есть пришла некая задача от бизнеса или архитектора - эти страницы нужно куда-то выделить. Очевидное решение - в новый app, то есть приложение, содержащее эти страницы + всю необходимую для них логику. Термин "приложение" не противоречит классической структуре, и верно, что "страницей" его называть не правильно. Но в контексте роутера это - набор страниц, роутер не должен знать о структуре и фреймворках, используемых в отдельных "приложениях", из которых формируется единое "приложение". Роутер существует в едином контексте - это вкладка браузера и URL, а откуда берутся компоненты для страниц - это детали реализации. Поэтому я не вижу здесь логических ошибок - роутинг и структура проекта это разные вещи.

  2. Да, есть проекты из 1 страницы - лендинги или "виджеты", которые встраиваются в сторонние сайты и например отображают погоду. Они тоже хорошо ложатся на классическую структуру - будет 0 страниц (только корневой App) и набор компонентов, которые там отображаются, и не будет слоя роутинга.

  3. Про микрофронтенды я написал в контексте треда. Я согласен, что они по большей части неэффективны и избыточны, а для работы разных команд над одним проектом часто достаточно монорепы и организационных ограничений. По крайней мере до 5 команд на моем опыте комфортно уживались без существенных блоков для других команд в монорепе. А вот аналогичный опыт с разделением по микрофронтам был очень негативным, так что я тоже использовал бы их только в крайнем случае. Написал пример для микрофронтов в комменте выше только для того, чтобы показать, что классическая структура не мешает их выделить.

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

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

Человек выше, активно спорил с этим. Когда я перечислил какие проблемы решает разбиение на домены, он пытался парировать тем, что это все можно решить через микрофронты. Но микрофронты - это тоже самое разбиение на домены + ещё несколько плюсов и минусов, которые как могут быть нужны так и вредить.

По сути, не так важно, вынесли вы домен в отдельный микрофронт/модуль/приложение/пакет. Ключевой момент, что это позволяет снизить свалку в коде.

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

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

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

В классике есть домены - это страницы src/pages/somePage. Это понятная и хорошо структурированная система, синхронизированная с роутингом. Рефакторить очень просто, риск дубляжа сведен к минимуму за счет глобальных слоев, связи между слоями достаточно четкие.

Проблема "свалки в коде" существует в классике, это верно, но она возникает только когда проект перерастает продвинуто-средний размер (30+ страниц, 50+ компонентов, 70+ вызовов апи). И для решения этой проблемы масштабируемости есть ряд способов - микрофронты это один вариант, как описано выше, монорепа с выделением ряда страниц - другой вариант, здесь все зависит от архитектора. Возможен и вариант развития классики "в глубину" - сгруппировать страницы по папкам, выделив слои внутри них.

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

Такое ощущение будто вы не совсем понимаете про, что я говорю.

Я как раз и указываю что при определенном росте проекта проект превращается в свалку и "классическое" разбиение перестает эффективно справляться.

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

Поэтому меня откровенно удивляет, что клерик вначале строго выступал против разбиения по домены, но потом выступил за микрофронты - которые и производят разбиение на домены. Ваше разбиение "в глубину" когда вы помещаете все в страницу - ничем не отличается от выделения домена. Кроме одного странного аспекта: вы все ещё домен называете страницей, хотя в нем может быть их как и 0 так и 10. Вы уверены что называть это страницей всё ещё хорошая идея?

Если мы принимаем, что концепция разбиения кода по доменным областям жизнеспособна, и хорошо работает на определенных проектах, то не совсем понятно, почему фсд встречает такое большое сопротивление, ведь он сильно следует этой идее. Вот к примеру вы тоже говорите что есть "наиболее грамотный выбор структуры". Можно хотя бы два примера общеизвестной структуры решающей проблему разбиения кода на большом проекте (когда классика уже хуже работает)?

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

Принципиально вы будете скованны этим самым проектом и его архитектурой, глотки свежего воздуха закрыты. Тех долг растет в геометрической прогрессии из-за большого размера подопытного и из-за вечно надо побыстрее выкатить фичу.

Можно хотя бы два примера общеизвестной структуры решающей проблему разбиения кода на большом проекте (когда классика уже хуже работает)?

Классика работает отлично на любых размерах. Единственная проблема, это сам размер, а так же насколько извращенная и изощрённая бизнес логика. И эти факторы не компенсируется архитектурой.

Не совсем понимаю про скованность. Почему вы думаете, что тут разбиение будет мнение гибкое чем в микрофронтах? Так то фсд или ДДД разложить обратно в классику - дело одного скрипта.

>Классика работает отлично на любых размерах

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

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

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

Не совсем понимаю про скованность.  Почему вы думаете, что тут разбиение будет мнение гибкое чем в микрофронтах?

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

Так то фсд или ДДД разложить обратно в классику - дело одного скрипта.

Ого, я так скоро в единорогов поверю)

Странно зачем же ее тогда дробят?

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

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

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

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

Более того не совсем понятен страх перед монорепом. В большинстве своем это хорошо работает. Нужно дальнейшее разбиение? Браво при ддд это проще.

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

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

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

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

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

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

Но я противоположность, я люблю когда все легко и просто, и когда я сам себе не создаю преграды на ровном месте, поэтому я никогда в здравом уме не буду применять ддд/fsd на фронте. Потому что это заставит меня страдать. а я не хочу.

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

У вас нет опыта решения тех проблем которые решал я, и вы считаете что мои решения плохие.

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

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

А почему они менее интересны?

потом что на фронте все со всем переплетено по умолчанию, 

При плохом продумывании - да, именно так.

Нет, последние 8 лет я занимаюсь только фронтенд разработки ( а до этого на беке я был только на маленьких проектах, где ддд и не нужен был)

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

С тем же успехом я могу сказать это о вас. Ведь вы почему-то хотите видеть в папке по 40 файлов, хотя они никак не относятся к вашей задаче. Давайте прекратим с попытками задеть друг друга?

Потому что это заставит меня страдать. а я не хочу.

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

, и так образом завуалированно возвышать себя это манипуляции это прикол.

Так вы же первый начали с того, что "настоящие программисты" должны быть вот такими (как вы). Я лишь парировал в вашем стиле.

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

А почему они менее интересны?

Потому что в них меньше необходимость сильно продумывать архитектуру и декомпозицию. А я люблю ее продумывать и учитывать как это будет работать дальше - при развитии продукта, кода он будет только расти.

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

Нет никакой разницы монореп вы используете или нет, прова код овнера могут быть разбиты по папкам а не по репозиториям.

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

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

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

Вы усложняете все и накладываете оверхед по умолчанию на все сценарии и весь процесс разработки

Поэтому я и сказал, что спор бессмысленный. Мы говорим о разных проектах.

Это, похоже, вечный спор, который был ещё 10 лет назад. Нейминг и группировка на основе типов сущностей (components, services, hooks) и семантики. Первое просто и универсально, но с определенного момента начинает превращаться в свалку. Второе сложно, думать надо по-больше и единого универсального подхода нет, в одной статье описать сложно. И с первым и со вторым можно жить.

Есть ощущение, что с какого-то момента роста проекта первое начинает внутри прятать второе.

Как по мне, "components", "services", "hooks", "helpers", "utils" - это потенциальные свалки, особенно на верхнем уровне структуры каталогов. Нейминг слишком общий, слишком мало в нем семантики. И лучше бы подумать над более контекстными смысловыми названиями, как минимум, для каталогов верхнего уровня.

Первое просто и универсально, но с определенного момента начинает превращаться в свалку

Как по мне, "components", "services", "hooks", "helpers", "utils" - это потенциальные свалки

Большой проект, в смысле реально прям большой = свалка. Поэтому микрофронты и свалки нет.

Что за палочка-выручалочка "микрофронты"? Как она избавляет от свалок в директориях "components", "services", "hooks", "helpers", "utils"?

Для меня микрофронты - это в первую очередь про модульность, структуру и нейминг. Ровно то, о чём сейчас речь и идет. В монорепе с микрофронтами же поди на верхнем смысловом уровне "components", "services", "hooks", "helpers", "utils" не будет? Будет смысловая разбивка на микрофронты + какие-то нарезки шаренного кода? Кто же мешает так и делать сразу. Кто-то так и 10 лет назад делал, когда никаких "микрофронтов" ещё и не было.

Что за палочка-выручалочка "микрофронты"? Как она избавляет от свалок в директориях "components", "services", "hooks", "helpers", "utils"?

Большой проект = свалка
Небольшой проект = свалки быть не может.

В монорепе с микрофронтами

Это не микрофронты, это монорепа с костылями.
Микрофронты = 1 микрофронт - отдельный репозиторий

Микрофронты = 1 микрофронт - отдельный репозиторий

Это очень узкий взгляд на микрофронты. Только если нужен отдельный релиз-цикл, да и в этом случае совсем необязательно. В остальных случаях, прекрасно и даже проще живет в монорепе с workspace-ами.

Тогда какие претензии к "свалкам" если вы их сами создаете и поощряете?

Что-то обсуждение начинает сводиться к "А вы бросили пить коньяк по утрам? Да или нет?", но попробую последний раз :)

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

Понятно, сами выдумали понятие свалки и у вас разумеется всё идеально. У всех свалка, а у вас структура и нейминг и несвалочный шаренный код.

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

Действительно, была тысяча папок, стало 30 папок. Было 10тыс файлов, стало 100 файлов. Вообще тоже самая. Такая же свалка. Запуск проект был 5 минут, стал 4 секунды. Ты был заложником легаси архитектуры и легаси подхода, а теперь можно писать микрофронт по красоте. Но кому это всё нужно, даже не знаю.

Ничего не писал про идеальность :) Так что кто и что выдумывает - вопрос открытый.

Отдельный реп - это локально просто папка. Не запускайте всё, запускайте только то, что нужно - в чём проблема?
Водораздел проходит не там, а в отдельных релиз-циклах и изолированности команд. Если сильно надо, то почему нет. Но это немного про другое.

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

Сразу видно человека, который работает один над маленьким проектами.

Так и никто не говорит, что микрофронтендов не помогут против свалки. Но все тоже самое можно достичь и в монорепе и без микрофронтов.

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

Самый популярный пример — карточка товара. Мы передаем через props все характеристики товара, а также callback для кнопки «добавить в корзину». Тем самым получаем переиспользуемый компонент, к которому мы можем привязать любую необходимую бизнес-логику, которая может быть разной для одного и того же отображения.

Так как у вас бизнес-логика находится в hook, то как вы её собираетесь привязать, например, к карточке товара? Вы же не можете как-то добавить (передать карточке товара) ещё одну кнопку и бизнес логику к ней?

Не могли бы вы это пояснить?

(Конечно я не про тот случай, когда вы просто берете эту свою карточку товара и передаёте ей разные значения callback для кнопки на карточке товара, возможно передавая и разный текст этой кнопки. - Или ваша фраза "мы можем привязать любую необходимую бизнес-логику" именно об этой возможности передавать разное значение для callback? )

Или ваша фраза "мы можем привязать любую необходимую бизнес-логику" именно об этой возможности передавать разное значение для callback? )

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий