с которыми мы сталкивались на протяжении многих лет работы, и которые с большой долей вероятности будут стрелять в "классической" архитектуре.
Какие конкретно боли? И почему это боли? Каким образом они стреляют?
Говоря о классической архитектуре, каждый будет понимать свое и делать все по своему.
Один раз зайдя на проект и увидел структуру файлов и папок в классике сразу всем становится все понятно. Что, как, зачем и почему. Ключевые слова: интуитивно понятная и логичная. Что конкретно тут может быть не понятно?
каждый будет понимать свое и делать все по своему
С чего вы это решили? И каким это образом имея такую структуру кто-то вдруг будет ее понимать как-то по особенному и делать по своему, вопрос как именно остается открытым. Тут все названо не абстрактно, а вполне конкретно. Компоненты, страницы, глобальной состояние, маршруты, конфиг и т.п. Как можно трактовать страницы по разному? Как можно трактовать компоненты по разному? С таким же успехом можно сказать: Архитектура которую вы предлагаете плохая. И далее пояснение вашей логики Почему плохая? А просто потому что я так написал, мне так кажется. Или стандартный фейковых аргумент, а исходя из моего опыта такие архитектуры превращаются в помойку и т.п.
Так почему бы не зайти с другой стороны и первым уровнем сделать разбиение по сущностям, а уже потом по типу используемого кода?
Потому что это не удобно и не применимо в реальности. На реальном проекте не только черное и белое, а все градации серого. А если проект сложный, то и вся цветовая палитра может быть. И не все привязано к "сущностям", и не все "сущности" изолированы друг от друга, в реальной жизни все сложение, с ветвлениями где многое зависит от многого, в том числе одна "сущность" зависит от другой или сразу от нескольких, более того эти "сущности" могут зависеть от сторонней логики, не связанной напрямую с какой-то "сущностью". И вообще проект это далеко не только набор "сущностей". Поэтому ваш вариант не подходит и может быть лучшей заменой классики. И вообще мыслить "сущностями", а не конкретными вещами - это путь в никуда.
И так же у вас разбиты utils, hooks, helpers, state. Причем структура разбиения зачастую совпадает. {{И дальше ваша мысль про "сущности"}}
Так же? Это как? Как образом например: hooks/useOutsideClick hooks/useBoolean hooks/useSwite И т.д. и т.п. имеют отношения с сущностям?
Как образом например: utils/formValidator utils/asyncHelpers И т.д. и т.п. имеют отношения с сущностям?
Аналогично и касаемо всего остального. Опять же, все просто, сущности просто тут не нужны и не применимы, страница логина это просто страница логина, не больше не меньше. Фильтр списка товаров, это просто фильтр списка товаров, не больше не меньше. Сам по себе список товаров, это просто список товаров, не больше не меньше. Карточка товара, это просто карточка товара, не больше не меньше. Все это по сути просто детали реализации проекта, например интернет магазина. Вот всё, всего лишь на всего. А вы начинаете всё переусложнять, вводить дополнительные слои абстракций, какую-то чудоковатую структуру файлов и папок придумывать. Зачем? Рад чего? Я понимаю если бы это реально упрощало и ускоряло разработку, делала бы ее приятной и интуитивно понятной. Но нет, этот подход делать все ровно наоборот. Вместо того, что элементарную вещь типа страницы входа или фильтра реализовать так же элементарно, ты вынужден перешагивать через 100500 ограничений и дополнительных абстракций.
Сколько я не работал на разных проектах, классическое разбиение скатывались в помойку с трудно отслеживаемых и зависимостями.
Это просто слова, которые ничего не значат. Любой может использовать этот трюк.
"Сколько я не работал на разных проектах, проекты где был применен fsd банкротились на следующий день"
"Сколько я не работал на разных проектах, сова прилетала к моему окну ровно в 12:44"
"Сколько я не работал на разных проектах, только использование $mol делало проект идеальным"
И получается, если нужно сделать принципиально новый дизайн и разработать новый поход, компоненты и прочее, то все в ступоре, т.к. такого никто не делал и интерфейса ещё в природе нет.
Конкретный пример в студию, который может показать что эти слова похожи на истину, ибо я вообще не вижу проблемы, а вы пишете что все в ступоре. Как так? Непонятно. В чем проблема разработать новый дизайн? Берешь и делаешь новый дизайн. Что конкретно вы имеете в виду под "разработать новый поход"?
такого никто не делал и интерфейса ещё в природе нет. В чем проблема опять же? Берешь и делаешь как обычно.
А плясать нужно от бизнеса, от природы вещей - сущностей.
Не вижу выгоды для разработки примерно нисколько. Просто вы так решили и всё.
А сущности могу не иметь UI отображения и тогда совсем беда...
И что? Почему беда? В чем проблема? Например нужно в фоне отправить аналитику, да, тут нет отображения, но я не понимаю почему это вдруг стало бедой?
Перечитайте свой коммент и осознайте, что это абсурд, вы пытаетесь ответить на вопрос почему компонент LoginForm нужно положить в features, а не в widgets или в entities, а почему бы и не в shared? Сама эта ситуация уже маразм.
В классической архитектуре такого в принципе быть не может. Если компонент будет использовать в разных местах, то это src/components, в остальных случаях он находится в локальной папке components например страницы, которая для удобства может быть разбита на компоненты. Если ты добавляешь глобальное состояние, оно без вариантов идет в src/globalState, если локально, то оно лежит рядом с компонентом и называется state.ts .
Разницу улавливаете, в одном случае все предельно просто и интуитивно понятно, для всех и всегда. А в другом случае взрыв мозга
Форма заставляет пользователя что то сделатьentity и feature это как существительное и глаголИ вся форма будет feature вместе с jsx стилями и тд.
И да, это не ответ на вопрос. Луна в Сатурне потому что небо зеленое, чай уплыл, а пыль погасла.
слой widget обычно используют как композиционный слой для feature и entity. К примеру в widget посте лайк будет feature и через prop прокидываться в слот в сам компонент поста который entity
Омг, ну это же просто дичь. FSD доводит элементарные вещи до абсурда.
Называть вещи своими именами и принять тот факт, что реально сложные вещи буду при любом раскладе сложными, никакая fsd/классика и т.п. этого не облегчит. И не надо тут пытаться умножать сложность простых вещей в разы, называя их абстрактными сущностями. Таким образом якобы только у вас(тех кто манипулирует на этом) такие сложности что ппц, а все остальные максимум это цвет кнопок меняют и не понимают истинных "проблем".
Если у всех остальных нет никаких проблем с архитектурой многие годы, ибо для фронтенда на реакте уже десять раз придуман стандартный подход, он же классический. То это говорит лишь о том, что он удачный, а люди которые его используют понимают что они делают и зачем. Да и мыслят они конкретикой, поэтому все что для вас(мыслящий абстрактными сущностями) сложно, для нас(мыслящих конкретными вещами) - легко и очевидно.
Я не понимаю вас. Вам пример из жизни привести? У меня нет кода который я бы мог скинуть в общий доступ) Есть много примеров в документации fsd. Я ничего не избегаю. У меня нет цели вас обмануть. С fsd правда может быть удобней делать проект.
Классика. Типичная "удобная" отмазка. Я не могу, я не я, посмотрите на примеры. Эти примеры не дают никакого ответа на вопрос, почему конкретно fsd будет лучше классики. А знаете почему? По тому что же, почему и вы не можете конкретного примера предоставить.
Ну если вы встречали таких проектов где хотелось бы добавить правил на архитектуру то видимо вам правда не нужен fsd сейчас)
Вы прикалываетесь? Вы опять сравниваете fsd с какой-то выдуманной плохой архитектурой, на фоне которой fsd якобы лучше. Речь идёт о совершенно конкретной архитектуре здорового человека(пример базовой структуры есть в комментах) и FSD. Вы понимаете что у вас нет ровно ни одного реального аргумента, подтвержденного кодом и/или структурой папок и файлов. Всё на что вас хватает это фантазии каких-то мнимых кейсах где якобы FSD лучше.
Может уже пора снять розовые очки наконец? В реальных проектах всегда есть сложные компоненты/сущности/суслики/кролики/называйте как угодно, которые зависят от других, в этом весь смысл компонентного подхода. Вы прикрываетесь абстрактными сущностями, избегая конкретики, потому что как только дело доходит до конкретных примеров, то сразу все становится элементарно и вся мифическая сложность сразу улетучивается.
Прям конкретный пример приведите, со структурам папок и файлов, с кодом. Чтобы мы видели что тут бардак, а тут все классно и все чрезмерные усложнения не напрасны, а необходимы.
Пока все ваши мифические доводы крутятся в парадигме из разряда: земля плоская, потому что я стою в поле, смотрю вперед и не вижу что это шар. А вот если бы вы использовали fsd, то тогда вы бы всё увидели)
Если сможете скинуть документацию вашей архитектуры можем с ней сравнивать
У нее нет документации, она интуитивно понятная. Если вам не понятно назначение файлов и папок из этих примеров, то у меня для вас плохие новости. Я скинул вам конкретные примеры структуры, пожалуйста. сравнивайте. Просто пройдитесь комментам тут полно примеров структуры файлов и папок. Они говорят сами за себя.
Вам "кажется" лучше всей командой делать проекты по принципу "я так чуствую"?)
Нет. По принципу здравого смысла. Один из них это делать жизнь проще, а не делать жизнь сложнее.
Features Этот слой предназначен для основных взаимодействий в вашем приложении, действий, которые важны вашим пользователям. Эти взаимодействия часто затрагивают бизнес-сущности, поскольку сущности — это то, о чём ваше приложение
Аххах. Я читал эти "определения" ко всем "слоям". Это просто маразм. И ваш комментарий не раскрыл, почему LoginForm должен лежать именно в features, а не в widgets или в entites. Более того, у вас не найдется утвердительного ответа, ибо этого не знает никто.
Привыкать к новому?) Вы так говорите как будто речь про переход с кнопочного телефона на смартфон идет) Привыкать к ущербной структуре файлов и папок и к ограничениям?) Нет, спасибо) Зачем, если я человек вольный и не люблю вставлять себе палки в колеса и портить жизнь.
выдаете желаемое за действительное!
Я привожу конкретные примеры с конкретной структурой папок и файлов. Их может любой сторонний наблюдатель посмотреть и сравнить с тем, что предлагает fsd. А вы говорите о каком-то якобы опыте и о том, что якобы этот опыт показал что fsd это якобы удобно. Т.е. то, что нельзя проверить и объективно оценить.
Описанные вами папки это не слои в понимании fsd
Ахахах. Оперировать такими понятиями как "в понимании fsd" это абсурд высшей степени. Типо это эталон, по которому мы сверяемся, что в его понимании подпадает по ту или иную трактовку, а что нет.
С таким же успехом вы можете говорить что земля не шар, потому что это не вписывается в концепцию плоской земли.
А что по вашему описанные мною файлы и папки такое? Набор рандомных букв? Наверное не понятно что в них должно лежать да?)
Ну и если вы считаете что слои имеют столько же смысла что правило добавлять в папку 4 папки то я не знаю что ответить)
Вы его увидели первый раз в FSD и у вас все ассоциации с этим словом только завязаны на fsd?) Поэтому вы не понимаете что такое components, pages, layouts, globalState и т.п.
про public API. да!
Ясно, понятно)))) С import и export мы работать не умеем)
Да будет много папок, но зато удобней переиспользовать и опять же fsd не говорит сколько нам кода в папке писать. Ну есть у нас форма авторизации в 4 разных вариантах просто ложим в одну фитчу и через public API отдаём
Удобнее? Это как? Удобнее чем это?) Вы просто прочитайте что что вы написали) Ложим в фичу, через public api отдаем, джину лампу трем. Как будто реактивный двигатель для Союз-1 разрабатываете. И да, а с чего это вдруг в фичу? Почему не в widgets? :D Вопрос смешной да?) Такого вопроса вообще априори не должно возникать.
import { LoginForm } from 'components/LoginForm';
Даже не знаю, удобнее можно разве что, чтобы силой мысли код выполнялся.
Мне кажется классическая архитектура проектов ещё менее масштабируема.
Вы правы, вам кажется. К ней не применимы термины "менее удобна" и "менее масштабируема". Она основана на этих принципах. Просто, очевидно, интуитивно понятно, наглядно, быстро, это все про нее.
и сразу понятно что за что отвечает и что с чем связанно
А так что, не понятно?))
src/
components/
SmartForm/
index.tsx // Сам компонент
state.ts // Локальное состояние компонента (если нужно)
styles.module.scss // Стили компонента
Вот смотрю и вообще не понимаю что тут к чему)) Вообще не понятно)) Если бы не подсказки в виде комментариев никогда бы не догадался с первого раза)
если ввести слои будет удобней
Правда?)) pages, layouts, components, globalState и т.д. и т.п. это так, шутка какая-то. А если добавить правило - каждый файл не более 10 строк, то будет ещё удобнее, а если добавить правило что в каждой папке должно быть не менее 4х папок, то будет ещё удобнее. Мы уже почти достигли идеала, круто. Везде есть мера и здравый смысл, не надо выходить за их пределы.
Опять же, если эти правила только добавят сложности, то оно и не надо
Именно, они только добавят сложности. И да, не надо этого. Только для прям сложных компонентов можно добавлять дополнительные деления, ибо для них это логично и интуитивно понятно.
Добавить public api из fsd ещё удобней
Эмммм, нет)
а там уже пару шагов до самого fsd)
Упаси)
но я из личного опыта вижу, что на больших проектах эти правила помогут ориентироваться в проекте
Это называется выдавать желаемое за действительное.
Можно сказать так(это не мои мысли, а выдумка для иллюстрации манипуляции через слова об опыте):
Из личного опыта я вижу, что писать аналог Figma на голом языке brainfuck с транспиляцией в JS это приятно, удобно и помогает легко и быстро ориентироваться.
Из личного опыта я вижу, что чем короче мы называем переменные, тем проще и быстрее писать код, да и с поддержкой у нас в команде нет проблем. Идеально это если имена переменных состоят из одного символа.
Это я уже видел. Да, оно стало лучше чем было. Это факт.
Но это всё равно полумера и все равно FSD кривая мертворожденная история. Он сливает по всем фронтам классике. Хоть убей, не понимаю стремление некоторых людей собственноручно заставлять себя страдать.
С 3 проекта научился и стало прям удобно и понятно.
На счет удобно и понятно это вы конечно преувеличиваете и лукавите))) Такие тезисы не применимы к fsd.
А вот ключевое тут: с 3его проекта. В стандартной классической архитектуре вам бы сразу, сходу все было понятно, ведь ее фишка в том что она интуитивно понятна и максимально логичная. всегда и для всех. А не только для тех, кто посветил ей пару тысяч часов и пару десятков проектов, участвовал в паре десятков созвонов где обсуждали что есть wdgets, что есть features, что есть shared (спойлер: и в итоге все равно никто не понял что есть что).
То что можно делать папки components любой вложенности тоже не понравилось.
Тут всё индивидуально, компоненты могут быть сгруппированы по какому-то признаку. Просто в тупую ставить ограничения на то, что нет нельзя создать ещё одну папку это как минимум странно.
Если вникнуть глубже или того хуже попробовать ее в реальном проекте, то это будет первый и последний раз когда у тебя возникала мысль использовать fsd. Это настолько контр продуктивно и контр интуитивно, что аж страшно, почему не все это видят с первого взгляда. Достаточно провести мысленный эксперимент, или посмотреть примеры у них на сайте или попробовать создать тестовый проект и начать накидывать код, то кровь сразу из глаз пойдет и ты поймешь, что-то ты делать что-то очень не хорошее, остановись, это не правильно.
Но часто, когда люди говорят "не хочу поднимать глобальный стейт-менеджер", они имеют в виду "не хочу тащить дополнительную библиотеку и выделять под неё архитектурные паттерны".
Иными словами они говорят - я намеренно буду писать грязный и неудобный код, сталкиваться с ограничениями, вместо того, чтобы писать чистый, интуитивно понятный код. Молодцы эти люди, ничего не скажешь.
В React-проектах нередко принцип "взял хук и быстро сделал" срабатывает быстрее и понятнее (особенно если разработчики внутри команды не все знают/любят MobX).
Проектах? "Проекты" с таким подходом знаете кто пишет? Думаю и сами догадываетесь. Тем более MobX не надо знать, достаточно уделить 30 минут и всё станет предельно понятно для 99% случаев, в остальных 1% можно ещё 30 минут минут времени уделить и всё, вы знаток MobX. Чтобы писать makeAutoObservable в конструкторе класса и заворачивать компоненты в observer много ума и изучения не надо. 30 минут это прям с запасом. В остальных случая нужны только reaction , autorun , when ну и configure чтобы сделать автобатчинг по умолчанию и сделать enforceActions: "never".
Всё до безобразия просто, кинув тому, кто первый раз видит MobX этот пример, он через 5-10 минут уже может вполне клепать проекты используя его.
Server Components не только про SEO. Их суть - не столько в том, чтобы «прокачать» SEO (хотя это полезный бонус), сколько в разделении кода между клиентом и сервером, чтобы ускорять загрузку и держать часть логики на сервере (даже если контент защищён авторизацией). В Next.js 13+, например, часто используют серверные роуты и "серверные экшены", чтобы разгрузить клиентский бандл и эффективнее кешировать данные.
Да, все эти громкие заявления я 100 раз видел и видел все это многократно на практике, и практика показывает что никакого ускорения для пользователя нет, в лучшем случае скорость та же. А вот геморроя в разработке и ограничений это добавляет знатно. Итого, использовать это можно только в острой необходимости, а именно если нужно SEO. И то, есть механизмы лучше.
Но не все команды хотят или могут его использовать (например, из-за политики компании, из-за незнания инструмента, или просто потому что устраивает natively встроенная механика хуков).
Ну это абсурд. Взгляните на пример выше. 5-10 минут и вы знаете MobX. Ещё час и вы мастер, а просто разработав 1 проект с ним вы уже ас.
В статье про useActionState речь шла о сугубо реактовом решении, которое встроено в официальный API. Для многих команд это решающий аргумент - они предпочитают официоз, чтобы не плодить разные библиотеки.
Так оно кривое, как и все что связано с управлением состоянием встроенными в реакт способами. Если вы используете реакт и т.п., вы уже как вы говорите плодите библиотеки. Поэтому какая разница одной больше или одной меньше?
Преднамеренно стрелять себе в ноги, это конечно удел "великих" команд и компаний. Да, такие существуют(к сожалению), я знаю. Обязательно "берем" с них пример. Есть люди которые питаются исключительно энергией солнца, они не хотят в своем желудки плодить еду, тем более разную. Их тоже будем рассматривать как аргументы в пользу того чтобы не есть?)
Реакт можно писать как классовыми компонентами, так и функциональными. И так и так норм. Тут разговор про то, как управлять состоянием, и используя MobX и классы это максимально удобно, чисто и наглядно.
Какие конкретно боли? И почему это боли? Каким образом они стреляют?
Один раз зайдя на проект и увидел структуру файлов и папок в классике сразу всем становится все понятно. Что, как, зачем и почему. Ключевые слова: интуитивно понятная и логичная. Что конкретно тут может быть не понятно?
С чего вы это решили? И каким это образом имея такую структуру кто-то вдруг будет ее понимать как-то по особенному и делать по своему, вопрос как именно остается открытым. Тут все названо не абстрактно, а вполне конкретно. Компоненты, страницы, глобальной состояние, маршруты, конфиг и т.п. Как можно трактовать страницы по разному? Как можно трактовать компоненты по разному?
С таким же успехом можно сказать: Архитектура которую вы предлагаете плохая. И далее пояснение вашей логики Почему плохая? А просто потому что я так написал, мне так кажется. Или стандартный фейковых аргумент, а исходя из моего опыта такие архитектуры превращаются в помойку и т.п.
Потому что это не удобно и не применимо в реальности. На реальном проекте не только черное и белое, а все градации серого. А если проект сложный, то и вся цветовая палитра может быть.
И не все привязано к "сущностям", и не все "сущности" изолированы друг от друга, в реальной жизни все сложение, с ветвлениями где многое зависит от многого, в том числе одна "сущность" зависит от другой или сразу от нескольких, более того эти "сущности" могут зависеть от сторонней логики, не связанной напрямую с какой-то "сущностью". И вообще проект это далеко не только набор "сущностей". Поэтому ваш вариант не подходит и может быть лучшей заменой классики.
И вообще мыслить "сущностями", а не конкретными вещами - это путь в никуда.
Так же? Это как?
Как образом например:
hooks/useOutsideClickhooks/useBooleanhooks/useSwiteИ т.д. и т.п. имеют отношения с сущностям?
Как образом например:
utils/formValidatorutils/asyncHelpersИ т.д. и т.п. имеют отношения с сущностям?
Аналогично и касаемо всего остального. Опять же, все просто, сущности просто тут не нужны и не применимы, страница логина это просто страница логина, не больше не меньше. Фильтр списка товаров, это просто фильтр списка товаров, не больше не меньше. Сам по себе список товаров, это просто список товаров, не больше не меньше. Карточка товара, это просто карточка товара, не больше не меньше. Все это по сути просто детали реализации проекта, например интернет магазина. Вот всё, всего лишь на всего.
А вы начинаете всё переусложнять, вводить дополнительные слои абстракций, какую-то чудоковатую структуру файлов и папок придумывать. Зачем? Рад чего? Я понимаю если бы это реально упрощало и ускоряло разработку, делала бы ее приятной и интуитивно понятной. Но нет, этот подход делать все ровно наоборот. Вместо того, что элементарную вещь типа страницы входа или фильтра реализовать так же элементарно, ты вынужден перешагивать через 100500 ограничений и дополнительных абстракций.
Это просто слова, которые ничего не значат. Любой может использовать этот трюк.
"Сколько я не работал на разных проектах, проекты где был применен fsd банкротились на следующий день"
"Сколько я не работал на разных проектах, сова прилетала к моему окну ровно в 12:44"
"Сколько я не работал на разных проектах, только использование $mol делало проект идеальным"
Конкретный пример в студию, который может показать что эти слова похожи на истину, ибо я вообще не вижу проблемы, а вы пишете что все в ступоре.
Как так? Непонятно.
В чем проблема разработать новый дизайн? Берешь и делаешь новый дизайн.
Что конкретно вы имеете в виду под "разработать новый поход"?
такого никто не делал и интерфейса ещё в природе нет.В чем проблема опять же? Берешь и делаешь как обычно.Не вижу выгоды для разработки примерно нисколько. Просто вы так решили и всё.
И что? Почему беда? В чем проблема?
Например нужно в фоне отправить аналитику, да, тут нет отображения, но я не понимаю почему это вдруг стало бедой?
Перечитайте свой коммент и осознайте, что это абсурд, вы пытаетесь ответить на вопрос почему компонент
LoginFormнужно положить в features, а не в widgets или в entities, а почему бы и не в shared? Сама эта ситуация уже маразм.В классической архитектуре такого в принципе быть не может. Если компонент будет использовать в разных местах, то это
src/components, в остальных случаях он находится в локальной папке components например страницы, которая для удобства может быть разбита на компоненты. Если ты добавляешь глобальное состояние, оно без вариантов идет вsrc/globalState, если локально, то оно лежит рядом с компонентом и называетсяstate.ts.Разницу улавливаете, в одном случае все предельно просто и интуитивно понятно, для всех и всегда. А в другом случае взрыв мозга
И да, это не ответ на вопрос. Луна в Сатурне потому что небо зеленое, чай уплыл, а пыль погасла.
Омг, ну это же просто дичь. FSD доводит элементарные вещи до абсурда.
Называть вещи своими именами и принять тот факт, что реально сложные вещи буду при любом раскладе сложными, никакая fsd/классика и т.п. этого не облегчит.
И не надо тут пытаться умножать сложность простых вещей в разы, называя их абстрактными сущностями. Таким образом якобы только у вас(тех кто манипулирует на этом) такие сложности что ппц, а все остальные максимум это цвет кнопок меняют и не понимают истинных "проблем".
Если у всех остальных нет никаких проблем с архитектурой многие годы, ибо для фронтенда на реакте уже десять раз придуман стандартный подход, он же классический. То это говорит лишь о том, что он удачный, а люди которые его используют понимают что они делают и зачем. Да и мыслят они конкретикой, поэтому все что для вас(мыслящий абстрактными сущностями) сложно, для нас(мыслящих конкретными вещами) - легко и очевидно.
Классика. Типичная "удобная" отмазка. Я не могу, я не я, посмотрите на примеры. Эти примеры не дают никакого ответа на вопрос, почему конкретно fsd будет лучше классики. А знаете почему? По тому что же, почему и вы не можете конкретного примера предоставить.
Вы прикалываетесь? Вы опять сравниваете fsd с какой-то выдуманной плохой архитектурой, на фоне которой fsd якобы лучше. Речь идёт о совершенно конкретной архитектуре здорового человека(пример базовой структуры есть в комментах) и FSD. Вы понимаете что у вас нет ровно ни одного реального аргумента, подтвержденного кодом и/или структурой папок и файлов. Всё на что вас хватает это фантазии каких-то мнимых кейсах где якобы FSD лучше.
Может уже пора снять розовые очки наконец? В реальных проектах всегда есть сложные компоненты/сущности/суслики/кролики/называйте как угодно, которые зависят от других, в этом весь смысл компонентного подхода. Вы прикрываетесь абстрактными сущностями, избегая конкретики, потому что как только дело доходит до конкретных примеров, то сразу все становится элементарно и вся мифическая сложность сразу улетучивается.
Прям конкретный пример приведите, со структурам папок и файлов, с кодом. Чтобы мы видели что тут бардак, а тут все классно и все чрезмерные усложнения не напрасны, а необходимы.
Пока все ваши мифические доводы крутятся в парадигме из разряда: земля плоская, потому что я стою в поле, смотрю вперед и не вижу что это шар. А вот если бы вы использовали fsd, то тогда вы бы всё увидели)
А как классика этому мешает?
Это здравая мысль, учиться никогда не поздно
Т.е. форма не отображает данные?) Submit формы это не действие?) А поля формы, это что, не данные которые улетят на сервер?)
Что?)))
Ну, скажем так, ваши вкусы специфичны)
Да нет, много кто знает как надо) Просто вам скучно использовать простые принципы и решения и вам создаете себе проблемы, а потом пытаетесь их решать)
???
У нее нет документации, она интуитивно понятная. Если вам не понятно назначение файлов и папок из этих примеров, то у меня для вас плохие новости. Я скинул вам конкретные примеры структуры, пожалуйста. сравнивайте. Просто пройдитесь комментам тут полно примеров структуры файлов и папок. Они говорят сами за себя.
Нет. По принципу здравого смысла. Один из них это делать жизнь проще, а не делать жизнь сложнее.
Аххах. Я читал эти "определения" ко всем "слоям". Это просто маразм. И ваш комментарий не раскрыл, почему
LoginFormдолжен лежать именно в features, а не в widgets или в entites. Более того, у вас не найдется утвердительного ответа, ибо этого не знает никто.Привыкать к новому?) Вы так говорите как будто речь про переход с кнопочного телефона на смартфон идет) Привыкать к ущербной структуре файлов и папок и к ограничениям?) Нет, спасибо) Зачем, если я человек вольный и не люблю вставлять себе палки в колеса и портить жизнь.
Я привожу конкретные примеры с конкретной структурой папок и файлов. Их может любой сторонний наблюдатель посмотреть и сравнить с тем, что предлагает fsd.
А вы говорите о каком-то якобы опыте и о том, что якобы этот опыт показал что fsd это якобы удобно. Т.е. то, что нельзя проверить и объективно оценить.
Ахахах. Оперировать такими понятиями как "в понимании fsd" это абсурд высшей степени. Типо это эталон, по которому мы сверяемся, что в его понимании подпадает по ту или иную трактовку, а что нет.
С таким же успехом вы можете говорить что земля не шар, потому что это не вписывается в концепцию плоской земли.
А что по вашему описанные мною файлы и папки такое? Набор рандомных букв? Наверное не понятно что в них должно лежать да?)
Вы его увидели первый раз в FSD и у вас все ассоциации с этим словом только завязаны на fsd?) Поэтому вы не понимаете что такое components, pages, layouts, globalState и т.п.
Ясно, понятно)))) С import и export мы работать не умеем)
Удобнее? Это как? Удобнее чем это?) Вы просто прочитайте что что вы написали) Ложим в фичу, через public api отдаем, джину лампу трем. Как будто реактивный двигатель для Союз-1 разрабатываете. И да, а с чего это вдруг в фичу? Почему не в widgets? :D Вопрос смешной да?) Такого вопроса вообще априори не должно возникать.
Даже не знаю, удобнее можно разве что, чтобы силой мысли код выполнялся.
Вы правы, вам кажется. К ней не применимы термины "менее удобна" и "менее масштабируема". Она основана на этих принципах. Просто, очевидно, интуитивно понятно, наглядно, быстро, это все про нее.
А так что, не понятно?))
Вот смотрю и вообще не понимаю что тут к чему)) Вообще не понятно)) Если бы не подсказки в виде комментариев никогда бы не догадался с первого раза)
Правда?)) pages, layouts, components, globalState и т.д. и т.п. это так, шутка какая-то. А если добавить правило - каждый файл не более 10 строк, то будет ещё удобнее, а если добавить правило что в каждой папке должно быть не менее 4х папок, то будет ещё удобнее. Мы уже почти достигли идеала, круто. Везде есть мера и здравый смысл, не надо выходить за их пределы.
Именно, они только добавят сложности. И да, не надо этого. Только для прям сложных компонентов можно добавлять дополнительные деления, ибо для них это логично и интуитивно понятно.
Эмммм, нет)
Упаси)
Это называется выдавать желаемое за действительное.
Можно сказать так(это не мои мысли, а выдумка для иллюстрации манипуляции через слова об опыте):
Из личного опыта я вижу, что писать аналог Figma на голом языке brainfuck с транспиляцией в JS это приятно, удобно и помогает легко и быстро ориентироваться.
Из личного опыта я вижу, что чем короче мы называем переменные, тем проще и быстрее писать код, да и с поддержкой у нас в команде нет проблем. Идеально это если имена переменных состоят из одного символа.
Ну и так далее.
Это я уже видел. Да, оно стало лучше чем было. Это факт.
Но это всё равно полумера и все равно FSD кривая мертворожденная история. Он сливает по всем фронтам классике. Хоть убей, не понимаю стремление некоторых людей собственноручно заставлять себя страдать.
На счет удобно и понятно это вы конечно преувеличиваете и лукавите))) Такие тезисы не применимы к fsd.
А вот ключевое тут:
с 3его проекта.В стандартной классической архитектуре вам бы сразу, сходу все было понятно, ведь ее фишка в том что она интуитивно понятна и максимально логичная. всегда и для всех. А не только для тех, кто посветил ей пару тысяч часов и пару десятков проектов, участвовал в паре десятков созвонов где обсуждали что есть wdgets, что есть features, что есть shared (спойлер: и в итоге все равно никто не понял что есть что).
src/componentsразумеетсяЕсли компонентов полно, то да(если делать всё в тупую). И нет разницы, будет ли она называться shared или widgets или animals.
Открою секрет, например папка
componentsможет быть дополнительно структурирована по типу/назначению компонентов. Например:Уже не похоже на помойку да? И это касается любых папок, это все и так очевидно и интуитивно понятно, ограничений нет, от слова никаких.
Вообще нет разницы какой размер, он работает шикарно на всех.
Но на практике, fsd это мертворожденная и вредная штука. Чего не скажешь о классической архитектуре.
Тут всё индивидуально, компоненты могут быть сгруппированы по какому-то признаку. Просто в тупую ставить ограничения на то, что нет нельзя создать ещё одну папку это как минимум странно.
Если вникнуть глубже или того хуже попробовать ее в реальном проекте, то это будет первый и последний раз когда у тебя возникала мысль использовать fsd.
Это настолько контр продуктивно и контр интуитивно, что аж страшно, почему не все это видят с первого взгляда. Достаточно провести мысленный эксперимент, или посмотреть примеры у них на сайте или попробовать создать тестовый проект и начать накидывать код, то кровь сразу из глаз пойдет и ты поймешь, что-то ты делать что-то очень не хорошее, остановись, это не правильно.
Иными словами они говорят - я намеренно буду писать грязный и неудобный код, сталкиваться с ограничениями, вместо того, чтобы писать чистый, интуитивно понятный код. Молодцы эти люди, ничего не скажешь.
Проектах? "Проекты" с таким подходом знаете кто пишет? Думаю и сами догадываетесь. Тем более MobX не надо знать, достаточно уделить 30 минут и всё станет предельно понятно для 99% случаев, в остальных 1% можно ещё 30 минут минут времени уделить и всё, вы знаток MobX. Чтобы писать
makeAutoObservableв конструкторе класса и заворачивать компоненты вobserverмного ума и изучения не надо. 30 минут это прям с запасом. В остальных случая нужны толькоreaction,autorun,whenну иconfigureчтобы сделать автобатчинг по умолчанию и сделатьenforceActions: "never".Вот:
https://stackblitz.com/edit/vitejs-vite-dspjoj?file=src%2FApp.tsx&terminal=dev
Всё до безобразия просто, кинув тому, кто первый раз видит MobX этот пример, он через 5-10 минут уже может вполне клепать проекты используя его.
Да, все эти громкие заявления я 100 раз видел и видел все это многократно на практике, и практика показывает что никакого ускорения для пользователя нет, в лучшем случае скорость та же. А вот геморроя в разработке и ограничений это добавляет знатно. Итого, использовать это можно только в острой необходимости, а именно если нужно SEO. И то, есть механизмы лучше.
Ну это абсурд. Взгляните на пример выше. 5-10 минут и вы знаете MobX. Ещё час и вы мастер, а просто разработав 1 проект с ним вы уже ас.
Так оно кривое, как и все что связано с управлением состоянием встроенными в реакт способами. Если вы используете реакт и т.п., вы уже как вы говорите плодите библиотеки. Поэтому какая разница одной больше или одной меньше?
Преднамеренно стрелять себе в ноги, это конечно удел "великих" команд и компаний. Да, такие существуют(к сожалению), я знаю. Обязательно "берем" с них пример.
Есть люди которые питаются исключительно энергией солнца, они не хотят в своем желудки плодить еду, тем более разную. Их тоже будем рассматривать как аргументы в пользу того чтобы не есть?)
Реакт можно писать как классовыми компонентами, так и функциональными. И так и так норм. Тут разговор про то, как управлять состоянием, и используя MobX и классы это максимально удобно, чисто и наглядно.