Вот я открываю utils - и у меня лежат там только утилиты по нужному домену.
в тмо что у вас забит экран не нужными файлами, соотвественно навигация в них хуже.
Забит?) Прям ненужными?) У меня проблем с навигацией нет и так понятно где что лежит, а если не понятно, то CTRL+Click по нужной функции/классу/компоненту в том месте где он применяется и вуаля. Плюс есть такая штука как ctrl+f. В общем видите, у вас какие-то проблемы с навигацией, что вы их выделяете, а у меня их нет и не было никогда, поэтому я их даже не выделяю как преимущества, т.к. это вещь сама собой разумеющиеся.
В отличии от нло, я говорю про вполне реальную технологию, которую использовали некоторые люди и довольны.
Очевидцы НЛО так же говорят. Что вы что вы, вот я точно видел НЛО, а остальные нет.
Более того я привел несколько кейсов когда она работает лучше.
Я ни одного реального кейса не увидел. Только вымышленные и абстрактные. А цену, за так называемое решение этих кейсов вы платите каждый день. У вас все крутится вокруг вымышленных "помоек" и "сложной навигации". А когда мы возвращаемся в реальность, то никаких проблем с навигацией на самом деле нет в классике и "помоек" тоже, любой проект где больше 3х папок и файлов тогда можно называть помойкой)
По какой-то причине вы не можете допустить, что кому-то нравятся большие проекты и называете это самообманом.
Это теоретически возможно, но шанс крайне низок, ибо вкусы у такого человека должны быть специфическими, выбирать такое вместо проекта с нуля) Отсюда и ваши предпочтения все на ровном месте усложнять и драматизировать банальные и простые вещи как проблемы)
соотвественно вовсе не обязательно происходит дублирование кода
Ключевое - "не обязательно". Потому что дублирование происходит и много. На бэке конечно в этом плане проще намного и там меньше дублирования, а на фронте чтобы уложиться в вашу религию, то без дублирования не вариант.
Так же быстро она превращается в свалку, где все использует все, что приводит к циклическим зависимостям, высокой связности, кучей файлов лежащих в общем пространстве и т.п. Но если вам ок с таким работать - искренне рад за вас.
Ни одной реальной проблемы тут не увидел опять. С этим работать легко, быстро и проблем нет. В противном случае я был бы религиозным фанатиком FSD. Я же не мученик и специально себя не мучаю.
ну как мы видим, вы не готовы критически подойти к вашему суждению о фсд.
Суждение просто, FSD - усложняет всё на ровном месте и накладывает ненужные ограничения. Всё это делает работу с проектом неприятной и неудобной. А зачем это, когда можно гораздо приятней и эффективнее без него, поэтому FSD изначально был мертворожден, ибо на фронте такие фокусы это только головная боль и не более.
Вы открываете utils, и у вас там утилиты по всем доменам + еще и технические утилиты
1) Открою тайну, разные "домены" могут и используют общие utils, в противном случае у вас ANtI DRY и дублирование кода. 2) В чем проблема? Ну лежат там разные утилиты, и что теперь? Как это реально мешает?
Нет ы должны поверить вам, что поправде проект был мне не приятен, хотя ни проекта, ни меня вы толком не знаете.
Ну когда вам говорят я видел НЛО в небе вчера и это прям точно пришельцы. Вы поверите? Вот вы же не знаете этого человека и что он видел, но вот он вам это сказал. What you gonna do with that?
Почему не дружит? Не вижу никакой разницы в этом отношении с классикой.
Потому что каждый ваш "домен" должен быть изолирован и не зависеть от чего-то ещё сверху, ведь всё что ему нужно лежит в его папке. Ну это в вашей религии опять же. В моей картине мира это бред полный.
только не в разы, а на 1-2%. Ровно так же как как и любые другие ограничения кода которые заставляют задуматься о том как писать код, что бы потом не получить проблем.
Я например и так проблем не получаю, вообще никаких и никогда не получал, т.к. у меня классика. Там просто это исключено физически ибо нет жестких ограничений. Она супер легко и быстро адаптируется под конкретную специфику любого проекта.
В моем случае речь идет о ситуации когда файлов намного больше и классика уже плохо справляется.
Она отлично справляется. А вы просто говорите, что она плохо справляется. Тут есть огромная разница. Вы хотите выдавать желаемое за действительное, и даже верите в это реально. А мне пофиг на конкретные убеждения, для меня важен реальный профит, если MobX дает мне этот реальный профит по сравнению с остальным, разумеется я использую его, если классика дает мне реальный профит по сравнению с остальным, разумеется я использую ее. Я с 2016 до 2021 использовал Webpack, казалось бы, а потом попробовал Vite и он реально для меня лучше, т.к. при прочих равных он быстрее, поэтому теперь я двигаюсь с Vite'ом. Если бы FSD давала реальный профит, то я бы без задней мыслей ей пользовался. Но увы и ах, лучше классики для фронта пока ничего не придумано.
Походу вы на самом деле бэкенд разработкой занимаетесь, как раз-то там ваше фанатичное ддд работать может, а вот на фронте оно не может работать и изначально мертворожденное для него, потом что на фронте все со всем переплетено по умолчанию, точка.
Я понимаю что есть люди которым нравится когда им причиняют боль и они специально делают так, что бы им больно жилось по жизни.
Но я противоположность, я люблю когда все легко и просто, и когда я сам себе не создаю преграды на ровном месте, поэтому я никогда в здравом уме не буду применять ддд/fsd на фронте. Потому что это заставит меня страдать. а я не хочу.
Я не из тех, кто страдает и потом говорит всем какой я мученик, решаю такие сложны проблемы(которые сам себе создал), и какое решение(которое привело меня к этим страданиям) хорошее, а ваше(которое не заставляет вас страдать) плохое.
У вас нет опыта решения тех проблем которые решал я, и вы считаете что мои решения плохие.
А прикрываться якобы сложными проектами(по вашему мнению разумеется) просто из-за того что они древние и большие, и так образом завуалированно возвышать себя это манипуляции это прикол.
Почему же, я работал и с маленькими и свежими проектами. Как я и указал - для них классики достаточно. Но честно говоря, мне такие проекты кажутся менее интересными.
В чем самообман? Это вполне реальный кейс из моего опыта работы.
Ах, ну раз вы говорите что реальный, значит поверим вам на слово.
В итоге работая с одним сценарием - у вас открыто пол проекта в дереве файлов.
Нет, ровно столько, сколько нужно. Тем более все зависимости явные и очевидные, всё на ладони.
В ддд у меня будет открыта одна папка, внутри которой будут большинство нужных мне файлов.
Ага, и ещё тонна говнокода с тонной ограничений вызванной этой архитектурой, плюс тонны повторяющегося кода, т.к. это архитектура не особо дружит с DRY. Тот же самый сценарий с ней займет в разы больше времени чем в классике из-за неповоротливости, ограничений. отсутствия KISS и YASGNI.
Не совсем понимаю про скованность. Почему вы думаете, что тут разбиение будет мнение гибкое чем в микрофронтах?
Один огромный монореп, один набор библиотек/инструментов, один набор ограничений и правил, и т.п. один, один, один. Видите? Когда вас безальтернативно сажают на ладу гранту, потому что так решили, то увы и ах, на мерсе вам уже не поездить, даже если очень хочется.
Так то фсд или ДДД разложить обратно в классику - дело одного скрипта.
Ого, я так скоро в единорогов поверю)
Странно зачем же ее тогда дробят?
Дробят не ее, а огромные проекты, которые уже морально устали и стоят на коленях. Желающих работать с такими мамонтами не так много, но есть конечно и исключения, в виде вас например) Дай любому уважающему себя программисту проект с нуля, он тут же бросит всё и возьмется за него.
Я регулярно использовал ту или иную модель разбиения по предметным областям - это решало вышеуказанные проблемы и описанные мной кейсы.
Это единственное что вы видели и пробовали, поэтому вам и чуждо как это работать на проектах где нет проблем и не надо бороться с папками и т.п.
Почему же безальтернативно? Они вполне приятны после определенного рефакторинга и осмысления.
К чему этот самообман?
В нем стоят интересные задачи и меньше свалки чем в растущем проекте на классической структуре. Поэтому я скорее сочувствую тем кто вынужден работать в ее рамках.
А да, ну ясно тогда.
Проблема в том, что в итоге у вас все теже десять слоев,
Эммм нет, откуда бы? Любой компонент/страница/и т.п. напрямую общается с локальным/глобальным состоянием и/или через контекст с состоянием родительского компонента если есть такая потребность.
Ничего принципиально не поменяется для вас в плане разбиения, если вы вместо микрофронтендов начнёте использовать тоже самое разбиение на домены но на уровне одного проекта.
Принципиально вы будете скованны этим самым проектом и его архитектурой, глотки свежего воздуха закрыты. Тех долг растет в геометрической прогрессии из-за большого размера подопытного и из-за вечно надо побыстрее выкатить фичу.
Можно хотя бы два примера общеизвестной структуры решающей проблему разбиения кода на большом проекте (когда классика уже хуже работает)?
Классика работает отлично на любых размерах. Единственная проблема, это сам размер, а так же насколько извращенная и изощрённая бизнес логика. И эти факторы не компенсируется архитектурой.
Проблема в моем опыте: я обычно прихожу на большие проекты на которые люди потратили десятки или сотни тысяч часов.
Это всё объясняет, такие проекты безальтернативно обречены быть крайне неприятными в работе. У вас судя по всему опыта на на приятных проектах нет, либо вы завидуете тем, у кто на них работает)
Все модалки, компоненты и утилиты лежат на верхних уровнях components/ utils/ hooks/. Могу смело сказать, что при наличии 10+ таких сущностей навигация в проекте становится возможной только по прямым ссылкам в файлы.
И в чем проблема? Всё на ладони, максимально доступно и понятно, без промежуточной логики в десяти слоях.
Потому что главная задача архитектуры реализовать Low Coupling (низкая связанность) и High Cohesion (высокое зацепление)
И в чем собственно проблема? Реальная, а не выдуманная и высосанная из пальца? Я вот вообще никаких проблем не испытываю и не испытывал на проектах любого размера.
Попытайтесь реализовать даже стандартную авторизацию в рамках приведенного вами примера. После чего оцените связанность и зацепление полученного решения.
И что? Вообще ноль проблем. Предлагаете DRY и здравый смысл в мусорку выкинуть? Мешать не буду) Но это не мой вариант)
На данный момент под стандартной архитектурой как раз и понимают FSD, так как она задокументирована и хоть на сколько то повторяется от компании к компании.
Смотря что за код, пока вы просто выдумали ситуацию и сгустили краски. В реальности никогда, от слова совсем проблем не было, ну даже если где-то надо ещё поправить, окей, просто взял и поправил, в чем проблема?
Плюс, по вашей логике DRY до свидания, копипаст всего и вся привет.
как ваша "классическая" архитектура помогает избежать высокого зацепления?
А в чем реальная практическая проблема? Сколько реально раз это доставляло вам проблем в реальной жизни? Я в этом вообще не вижу никаких проблем т.к. в реальности это их не приносит. Опять же, всё зависит только от того, как вы захотите написать код, реализовать тот или иной функционал.
Я не знаю почему у вас так бомбит от fsd, но мне кажется профессионал всегда понимает, что нет ничего идеального, есть что-то, что подходит под конкретную ситуацию.
Меня бомбит когда я прихожу на проект, а там полная жесть, простые вещи превращены в сложные и задачи которые делаются 1час, на таких проектах делаются 8 часов или больше и не факт что попутно ничего не сломается. FSD это то, что переусложняет элементарные вещи на ровном месте и не приносит реального профита.
Ясно, через пару-тройку лет fsd всё будет идеально, и говнокода не будет. Вот он святой Грааль. Вот мы дураки столько лет мучались, десятилетиями, а тут вот же оно, fsd и всё в шоколаде, рецепт от говнокода и проекту может быть хоть 10 лет, хоть 20, features и entites спасут мир.
Да, есть ощущение, что в методологии есть что ещё добавить, улучшить, но она вполне рабочая, что доказано не одной командой и продуктом.
Улучшать? В идеальной методологии у которой через пару-тройку лет не будет говнокода нет ничего что можно улучишь, она уже достигла совершенства.
что доказано не одной командой и продуктом.
Ага, понятно, "доказано" железобетонно. Против таких "аргументов" не попрешь.
в пассажи безработных ноунеймов с синдромом утенка
Ноунеймов?) Безработных?)) Аххаха. Опять апелляция к "авторитетам", ну это уже за гранью нелепости. А вы как вообще, сами решаете что сегодня поесть или смотрите как один из ваших кумиров запостит то, что он сегодня ел и вы едите тоже самое? Судя по всему сами вы вообще решения не принимаете, только обязательно должен кто-то что-то сказать, написать.
боящихся не дай бог что-то новое узнать/попробовать
Да вы что? А чего же я пишу на реакте, а не PHP как в 2012 году? А чего же я пишу на typescript'e вместо javascript'a как писал до 2017 примерно? А чего это я использую MobX вместо redux который использовал раньше в связке с реактом? А что же я использую Vite, а не Webpack который юзал в периоде с 2016 по 2021 год? И т.д. и т.п.
Вы типичный фанатик, а я человек практичный, и не страдаю там, где можно не страдать. Я всегда смотрю на все новое и если вижу что это стоящая вещь, то обязательно ее пробую. И если она лучше того, что есть сейчас, то разумеется без всяких зазрений совести заменю то, что есть сейчас, на то, что лучше и удобнее.
Зайдите на npm и посмотрите, тонны мертворожденных стейт менеджеров и т.д. и т.п.
Как функциональные компоненты в Реакте, которые тоже всех по началу пугали?
Нет, они ни в какое сравнение с fsd не идут. В функциональный компонентах реакта сразу явно выделялась очень удобная фича это useEffect, я его сразу же и имплементировал в текущий проект на классовых компонентах. Это был ещё далекий 2018 что-ли, уже даже не помню.
Вы в FSD разбираетесь и на FSD работали?
Да, работал на 2х проектах с ним. Плюс видел примеры. Плюс мне достаточно провести мысленный эксперимент чтобы увидеть сразу к чему приведет использование FSD или использование Effector и т.п. Чтобы понять, оно будет лучше чем Х или нет. Я же не извращенец или фанатик, я ленивый человек и если что-то добавляет удобства, я обязательно это использую. Если бы 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 с удовольствием.
Про ограничения - почитайте, зачем в целом архитектура нужна.
Я больше 13 лет в коммерческой разработке и уже кучу проектов с нуля реализовал, пересмотрел и перепробовал всё что можно и нельзя.
Я видел судьбу проектов "без всяких ограничений", когда время на поддержку растет пропорционально времени существования проекта и объему кода. Код без ограничений неизбежно превращается в бесформенную массу, какой бы талантливой не была команда.
Вы видели проекты написанные джунами либо отвратительным разработчиками и теперь судите так про все проекты, которые не используют fsd. Вот и всё что вы видели.
Только в ру-сегменте десятки топовых компаний (посмотрите на HH статистику по количеству требований знания/опыта fsd, посмотрите доклады Яндекса, Самоката и т.п.) применяют эту "мертворожденную фигню", видимо, чтобы страдать побольше.
И что? В каждом из этих холдингов сотни проекты, и если на единицах они попробовали это недоразумение, это не значит что всё ппц, надо делать так. Более того, то как пишут в яндексе. сбере, самокате и т.п. это вообще даже не близко нельзя использовать как пример для подражания, там работают обычные разрабы, обычного уровня, не выдающегося. А вы опять апеллируете к авторитетам. это прям невежество. Если самокат и яндекс начнет писать на angular, что будете делать? Побежите писать на angular? А если они начнут на кнопки нажимать левой ногой и сделают доклад о том, как это хорошо, вы тоже будете левой ногой на клавиши нажимать?
Голословные утверждения про "просто для всех" конечно хорошо, но опять же, в статье приведены реальные цифры и реальные итоги, опять же, сравнение с другими не-fsd проектами перед глазами.
А у вас не голословные утверждения? Вы говорите что якобы у вас все стало лучше и быстрее. Но это просто слова, которые нельзя проверить. Поэтому написать можно все что угодно в ваших выводах. "реальные цифры и реальные итоги" что?)) Вот вам реальные цифры и итоги, скорость разработки с fsd падает в 10 раз, удобство падает в 20 раз. Как вам такие реальные цифры и итоги?
почитайте какого-нибудь Дядюшку Бо, он в каждой своей книге про это пишет практически.
А если он скажет с крыши прыгать? Прыгните? Апелляция к "авторитетам" это смешно. Вы просто решили с какого-то перепугу, что Х говорит дельные вещи, буду слушать то, что говорит Х. Без разницы что я сам думаю, что говорят остальные, только Х это истина.
"Традиционной" архитектурой обычно является ее отсутствие, что приводит к адской неразберихе в корневых папках компонентов/хуков и т.д.
И где на этом скриншоте отсутствие архитектуры? Где там ад, неразбериха и т.п.?
А вы проекты кроме тех, что писали джуны видели?
Наш FSD-проект безоговорочно лидирует по скорости погружения, поддержки и остальным плюсам, указанным в статье.
Ахахах, вот это прикол... Наш сыр безоговорочно лидирует над сырами конкурентов. Наши машины безоговорочно лидирует над машинами конкурентов.
Ваш fsd-проект безоговорочно проигрывает по всем фронтам классическому проекту с архитектурой здорового человека.
1. Сущности и есть обобщенные модели, которые предназначены для использования в разных фичах. Это ни в коем случае не "свойства фичи", а скорее компонент, репрезентирующий ту или иную бизнес сущность.
Иными словами, просто компонент. Но вы зачем-то просто компонент обсыпали кучей лишних слов.
2. Экран/страница в FSD - page (в нашем случае route). Рут не может "принадлежать" фичам, наоборот, разные фичи включаются в рут. Иерархия в FSD вертикальная и однонаправленная. Горизонтальные взаимоотношения тоже возможны, но про них стоит поговорить отдельно.
Захотим добавить на страницу авторизацию? Добавляем в рут/пейджу фичу авторизации.
Причем тут fsd? Это на уровне детского сада понятно. src/page/SomePage/index.tsx может в себе содержать все что угодно, но понятное дело что src/components/AnyCompoent не может содержать в себе страницу. Ведь она то и страница, что это на ней содержатся элементы.
3. Тут всегда немного путает нейминг. Мне сильно проще воспринимать и выделять фичи помог совет из одного из докладов по FSD: фича = юзер процесс.
Пример про аналитику не совсем понял. Блок аналитики в малом представлении может быть сущностью, если это полноценная страница - пейдж, либо виджет, тут уже нужно смотреть на конкретный пример. Фича для примера, упоминавшегося выше - это например "оплата", или "добавление в корзину", или "удаление из корзины". В фиче может быть работа с апи и, например, оптимистичная мутация данных на фронте.
Столько проблем на ровном месте, нет чтобы просто по классике все делать, где все просто и понятно. Но нет, надо создать себе кучу геморроя, чтобы на каждый чих 2 часа думать, то ли это feature, то ли это widget, то ли это entity. Ну бред же. И ещё в довесок навешать на себя оков виде всяких ограничений. Никогда не понимал у людей тягу специально страдать.
Не прозрачный намек, кому-то заменяется на "дуракам". Кавычки не спроста.
А кто-то видит необходимость и поглубже в DDD погрузиться
Ещё не прозрачный намек, кто-то заменяется на "умный". Кавычки не спроста.
Фронтовые приложения растут в масштабах и лучшие практики проектирования тоже постепенно заходят во фронт.
Смешно, "лучшие" практики, ага. Превращать простые вещи в переусложненный ад, это конечно "лучшая" практика. А потом плакаться и "решать проблемы", которые сами себе создали и ещё сверху навесили кучу правил и ограничений на каждый чих. Зато потом они называют свою проекты большими, или сложными. Но мы то знаем, что их проекты на самом деле не сложные, просто они их уничтожили сами.
Для фронта уже очень давно сформированы лучшие практики. Для любых масштабов.
Когда рядом лежит Button и ButtonGetUser
В чем проблема? Там черным по белому написано "Кнопка"(Button), "Кнопка получить пользователя"(ButtonGetUser). Исходя из названия назначения этих компонентов понятны. Там же не ASdqwe и Yerqw, где не понятно что это, пока не зайдешь внутрь.
Ну так где свалка в итоге, если у нас микрофронты в отдельных репах со всеми вытекающими бонусами, которые сильно перекрывают небольшое неудобство на этапе разбиения на микрофронты и их организацию?)
Вот цитата ваша
Вот я открываю utils - и у меня лежат там только утилиты по нужному домену.Забит?) Прям ненужными?) У меня проблем с навигацией нет и так понятно где что лежит, а если не понятно, то CTRL+Click по нужной функции/классу/компоненту в том месте где он применяется и вуаля. Плюс есть такая штука как ctrl+f. В общем видите, у вас какие-то проблемы с навигацией, что вы их выделяете, а у меня их нет и не было никогда, поэтому я их даже не выделяю как преимущества, т.к. это вещь сама собой разумеющиеся.
Очевидцы НЛО так же говорят. Что вы что вы, вот я точно видел НЛО, а остальные нет.
Я ни одного реального кейса не увидел. Только вымышленные и абстрактные. А цену, за так называемое решение этих кейсов вы платите каждый день. У вас все крутится вокруг вымышленных "помоек" и "сложной навигации". А когда мы возвращаемся в реальность, то никаких проблем с навигацией на самом деле нет в классике и "помоек" тоже, любой проект где больше 3х папок и файлов тогда можно называть помойкой)
Это теоретически возможно, но шанс крайне низок, ибо вкусы у такого человека должны быть специфическими, выбирать такое вместо проекта с нуля) Отсюда и ваши предпочтения все на ровном месте усложнять и драматизировать банальные и простые вещи как проблемы)
Ключевое - "не обязательно". Потому что дублирование происходит и много. На бэке конечно в этом плане проще намного и там меньше дублирования, а на фронте чтобы уложиться в вашу религию, то без дублирования не вариант.
Ни одной реальной проблемы тут не увидел опять. С этим работать легко, быстро и проблем нет. В противном случае я был бы религиозным фанатиком FSD. Я же не мученик и специально себя не мучаю.
Суждение просто, FSD - усложняет всё на ровном месте и накладывает ненужные ограничения. Всё это делает работу с проектом неприятной и неудобной. А зачем это, когда можно гораздо приятней и эффективнее без него, поэтому FSD изначально был мертворожден, ибо на фронте такие фокусы это только головная боль и не более.
1) Открою тайну, разные "домены" могут и используют общие utils, в противном случае у вас ANtI DRY и дублирование кода.
2) В чем проблема? Ну лежат там разные утилиты, и что теперь? Как это реально мешает?
Ну когда вам говорят я видел НЛО в небе вчера и это прям точно пришельцы. Вы поверите? Вот вы же не знаете этого человека и что он видел, но вот он вам это сказал. What you gonna do with that?
Потому что каждый ваш "домен" должен быть изолирован и не зависеть от чего-то ещё сверху, ведь всё что ему нужно лежит в его папке. Ну это в вашей религии опять же. В моей картине мира это бред полный.
Я например и так проблем не получаю, вообще никаких и никогда не получал, т.к. у меня классика. Там просто это исключено физически ибо нет жестких ограничений. Она супер легко и быстро адаптируется под конкретную специфику любого проекта.
Она отлично справляется. А вы просто говорите, что она плохо справляется. Тут есть огромная разница. Вы хотите выдавать желаемое за действительное, и даже верите в это реально. А мне пофиг на конкретные убеждения, для меня важен реальный профит, если MobX дает мне этот реальный профит по сравнению с остальным, разумеется я использую его, если классика дает мне реальный профит по сравнению с остальным, разумеется я использую ее. Я с 2016 до 2021 использовал Webpack, казалось бы, а потом попробовал Vite и он реально для меня лучше, т.к. при прочих равных он быстрее, поэтому теперь я двигаюсь с Vite'ом. Если бы FSD давала реальный профит, то я бы без задней мыслей ей пользовался. Но увы и ах, лучше классики для фронта пока ничего не придумано.
Походу вы на самом деле бэкенд разработкой занимаетесь, как раз-то там ваше фанатичное ддд работать может, а вот на фронте оно не может работать и изначально мертворожденное для него, потом что на фронте все со всем переплетено по умолчанию, точка.
Я понимаю что есть люди которым нравится когда им причиняют боль и они специально делают так, что бы им больно жилось по жизни.
Но я противоположность, я люблю когда все легко и просто, и когда я сам себе не создаю преграды на ровном месте, поэтому я никогда в здравом уме не буду применять ддд/fsd на фронте. Потому что это заставит меня страдать. а я не хочу.
Я не из тех, кто страдает и потом говорит всем какой я мученик, решаю такие сложны проблемы(которые сам себе создал), и какое решение(которое привело меня к этим страданиям) хорошее, а ваше(которое не заставляет вас страдать) плохое.
А прикрываться якобы сложными проектами(по вашему мнению разумеется) просто из-за того что они древние и большие, и так образом завуалированно возвышать себя это манипуляции это прикол.
А почему они менее интересны?
Ах, ну раз вы говорите что реальный, значит поверим вам на слово.
Нет, ровно столько, сколько нужно. Тем более все зависимости явные и очевидные, всё на ладони.
Ага, и ещё тонна говнокода с тонной ограничений вызванной этой архитектурой, плюс тонны повторяющегося кода, т.к. это архитектура не особо дружит с DRY. Тот же самый сценарий с ней займет в разы больше времени чем в классике из-за неповоротливости, ограничений. отсутствия KISS и YASGNI.
Один огромный монореп, один набор библиотек/инструментов, один набор ограничений и правил, и т.п. один, один, один. Видите? Когда вас безальтернативно сажают на ладу гранту, потому что так решили, то увы и ах, на мерсе вам уже не поездить, даже если очень хочется.
Ого, я так скоро в единорогов поверю)
Дробят не ее, а огромные проекты, которые уже морально устали и стоят на коленях. Желающих работать с такими мамонтами не так много, но есть конечно и исключения, в виде вас например) Дай любому уважающему себя программисту проект с нуля, он тут же бросит всё и возьмется за него.
Это единственное что вы видели и пробовали, поэтому вам и чуждо как это работать на проектах где нет проблем и не надо бороться с папками и т.п.
К чему этот самообман?
А да, ну ясно тогда.
Эммм нет, откуда бы? Любой компонент/страница/и т.п. напрямую общается с локальным/глобальным состоянием и/или через контекст с состоянием родительского компонента если есть такая потребность.
Принципиально вы будете скованны этим самым проектом и его архитектурой, глотки свежего воздуха закрыты. Тех долг растет в геометрической прогрессии из-за большого размера подопытного и из-за вечно надо побыстрее выкатить фичу.
Классика работает отлично на любых размерах. Единственная проблема, это сам размер, а так же насколько извращенная и изощрённая бизнес логика. И эти факторы не компенсируется архитектурой.
Это всё объясняет, такие проекты безальтернативно обречены быть крайне неприятными в работе. У вас судя по всему опыта на на приятных проектах нет, либо вы завидуете тем, у кто на них работает)
И в чем проблема? Всё на ладони, максимально доступно и понятно, без промежуточной логики в десяти слоях.
И в чем собственно проблема? Реальная, а не выдуманная и высосанная из пальца? Я вот вообще никаких проблем не испытываю и не испытывал на проектах любого размера.
И что? Вообще ноль проблем. Предлагаете DRY и здравый смысл в мусорку выкинуть? Мешать не буду) Но это не мой вариант)
Смешно)
Но только не в случае с fsd, он только отжирает время и нервы, а на дистанции не перестает этого делать, а только усугубляет процесс.
Смотря что за код, пока вы просто выдумали ситуацию и сгустили краски. В реальности никогда, от слова совсем проблем не было, ну даже если где-то надо ещё поправить, окей, просто взял и поправил, в чем проблема?
Плюс, по вашей логике DRY до свидания, копипаст всего и вся привет.
А в чем реальная практическая проблема? Сколько реально раз это доставляло вам проблем в реальной жизни? Я в этом вообще не вижу никаких проблем т.к. в реальности это их не приносит. Опять же, всё зависит только от того, как вы захотите написать код, реализовать тот или иной функционал.
Меня бомбит когда я прихожу на проект, а там полная жесть, простые вещи превращены в сложные и задачи которые делаются 1час, на таких проектах делаются 8 часов или больше и не факт что попутно ничего не сломается. FSD это то, что переусложняет элементарные вещи на ровном месте и не приносит реального профита.
Ясно, через пару-тройку лет fsd всё будет идеально, и говнокода не будет. Вот он святой Грааль. Вот мы дураки столько лет мучались, десятилетиями, а тут вот же оно, fsd и всё в шоколаде, рецепт от говнокода и проекту может быть хоть 10 лет, хоть 20, features и entites спасут мир.
Улучшать? В идеальной методологии у которой через пару-тройку лет не будет говнокода нет ничего что можно улучишь, она уже достигла совершенства.
Ага, понятно, "доказано" железобетонно. Против таких "аргументов" не попрешь.
Ноунеймов?) Безработных?)) Аххаха. Опять апелляция к "авторитетам", ну это уже за гранью нелепости. А вы как вообще, сами решаете что сегодня поесть или смотрите как один из ваших кумиров запостит то, что он сегодня ел и вы едите тоже самое? Судя по всему сами вы вообще решения не принимаете, только обязательно должен кто-то что-то сказать, написать.
Да вы что?
А чего же я пишу на реакте, а не PHP как в 2012 году?
А чего же я пишу на typescript'e вместо javascript'a как писал до 2017 примерно?
А чего это я использую MobX вместо redux который использовал раньше в связке с реактом?
А что же я использую Vite, а не Webpack который юзал в периоде с 2016 по 2021 год?
И т.д. и т.п.
Вы типичный фанатик, а я человек практичный, и не страдаю там, где можно не страдать. Я всегда смотрю на все новое и если вижу что это стоящая вещь, то обязательно ее пробую. И если она лучше того, что есть сейчас, то разумеется без всяких зазрений совести заменю то, что есть сейчас, на то, что лучше и удобнее.
Зайдите на npm и посмотрите, тонны мертворожденных стейт менеджеров и т.д. и т.п.
Нет, они ни в какое сравнение с fsd не идут. В функциональный компонентах реакта сразу явно выделялась очень удобная фича это useEffect, я его сразу же и имплементировал в текущий проект на классовых компонентах. Это был ещё далекий 2018 что-ли, уже даже не помню.
Да, работал на 2х проектах с ним. Плюс видел примеры. Плюс мне достаточно провести мысленный эксперимент чтобы увидеть сразу к чему приведет использование FSD или использование Effector и т.п. Чтобы понять, оно будет лучше чем Х или нет.
Я же не извращенец или фанатик, я ленивый человек и если что-то добавляет удобства, я обязательно это использую. Если бы 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 с удовольствием.
Я больше 13 лет в коммерческой разработке и уже кучу проектов с нуля реализовал, пересмотрел и перепробовал всё что можно и нельзя.
Вы видели проекты написанные джунами либо отвратительным разработчиками и теперь судите так про все проекты, которые не используют fsd. Вот и всё что вы видели.
И что? В каждом из этих холдингов сотни проекты, и если на единицах они попробовали это недоразумение, это не значит что всё ппц, надо делать так. Более того, то как пишут в яндексе. сбере, самокате и т.п. это вообще даже не близко нельзя использовать как пример для подражания, там работают обычные разрабы, обычного уровня, не выдающегося. А вы опять апеллируете к авторитетам. это прям невежество. Если самокат и яндекс начнет писать на angular, что будете делать? Побежите писать на angular? А если они начнут на кнопки нажимать левой ногой и сделают доклад о том, как это хорошо, вы тоже будете левой ногой на клавиши нажимать?
А у вас не голословные утверждения? Вы говорите что якобы у вас все стало лучше и быстрее. Но это просто слова, которые нельзя проверить. Поэтому написать можно все что угодно в ваших выводах.
"реальные цифры и реальные итоги" что?))
Вот вам реальные цифры и итоги, скорость разработки с fsd падает в 10 раз, удобство падает в 20 раз.
Как вам такие реальные цифры и итоги?
А если он скажет с крыши прыгать? Прыгните?
Апелляция к "авторитетам" это смешно. Вы просто решили с какого-то перепугу, что Х говорит дельные вещи, буду слушать то, что говорит Х. Без разницы что я сам думаю, что говорят остальные, только Х это истина.
И где на этом скриншоте отсутствие архитектуры? Где там ад, неразбериха и т.п.?
А вы проекты кроме тех, что писали джуны видели?
Ахахах, вот это прикол... Наш сыр безоговорочно лидирует над сырами конкурентов. Наши машины безоговорочно лидирует над машинами конкурентов.
Ваш fsd-проект безоговорочно проигрывает по всем фронтам классическому проекту с архитектурой здорового человека.
Иными словами, просто компонент. Но вы зачем-то просто компонент обсыпали кучей лишних слов.
Причем тут fsd? Это на уровне детского сада понятно.
src/page/SomePage/index.tsxможет в себе содержать все что угодно, но понятное дело чтоsrc/components/AnyCompoentне может содержать в себе страницу. Ведь она то и страница, что это на ней содержатся элементы.Столько проблем на ровном месте, нет чтобы просто по классике все делать, где все просто и понятно. Но нет, надо создать себе кучу геморроя, чтобы на каждый чих 2 часа думать, то ли это feature, то ли это widget, то ли это entity. Ну бред же. И ещё в довесок навешать на себя оков виде всяких ограничений. Никогда не понимал у людей тягу специально страдать.
Вы всё правильно не понимаете, fsd никак и не соотносится с реальным миром. Это очередная мертворожденная фигня.
Не прозрачный намек, кому-то заменяется на "дуракам". Кавычки не спроста.
Ещё не прозрачный намек, кто-то заменяется на "умный". Кавычки не спроста.
Смешно, "лучшие" практики, ага. Превращать простые вещи в переусложненный ад, это конечно "лучшая" практика. А потом плакаться и "решать проблемы", которые сами себе создали и ещё сверху навесили кучу правил и ограничений на каждый чих. Зато потом они называют свою проекты большими, или сложными. Но мы то знаем, что их проекты на самом деле не сложные, просто они их уничтожили сами.
Для фронта уже очень давно сформированы лучшие практики. Для любых масштабов.
В чем проблема? Там черным по белому написано "Кнопка"(Button), "Кнопка получить пользователя"(ButtonGetUser). Исходя из названия назначения этих компонентов понятны. Там же не ASdqwe и Yerqw, где не понятно что это, пока не зайдешь внутрь.
Ну так где свалка в итоге, если у нас микрофронты в отдельных репах со всеми вытекающими бонусами, которые сильно перекрывают небольшое неудобство на этапе разбиения на микрофронты и их организацию?)