честно говоря думал ответить вам как обыно, так как у вас куча ошибок которые вы не осознаете, но вижу что это бесполезно. Укажу на 2 самых важных моментах:
Вы откровенно врете картинкой. У вас в папке компоненты 200 строк. и так же в hooks. Сделайте нормальную картинку и после этого попробуйте сюда залить и сказать что с этим удобно работать. (И после этого смеете что-то говорить про манипуляции?). У вас так же откровенная манипуляция про скорость разработки в фсд. Стоимость возрастает в разы? То есть вы 1 час пишите компонент, а потом 3 выбираете куда его сложить в фсд? Ухх в таком случае вам нельзя фсд пользоваться.
Вы не можете осознать термин домен и как с ним работать. Из этого вы раз за разом делаете не верные выводы. Более того это показывает вашу неспособность услышать собеседника. Что приводит меня к неутешительному выводу, дисскусия тут бесполезна.
Собственно, текущий разговор ничем не отличается от любого другого разговора с челоком, который что-то не понимает, не хочет понимать, но считает себя однозначно правым. Такие разговоры были у меня и с противниками ts, и с противниками реакта, и любой другой технологии или принципа. Они точно так же были на 100% уверены в свое правоте, точно так же не верно использовали инструмент, точно так же не хотели слушать собеседника.
Это довольно забавно как вы не понимаете, что такое допен, не хотите слушать, что это и как должно работать, и поэтому считаете, что это не работает.
Вообще бывают разные варианты. Но не суть - микрофронты часто используют как разбиение по доменам. И даже вы упоминали их в этом контексте. А теперь вдруг доменов нет.
И как именно вы что-то выделяете в отрыве от всего остального? Вот чтобы ваша выделенная бизнес логика имела хоть какой-то смысл.
так же как вы разделяете, что должно лежать в стейте, а что не должно. Использую логику. Если вот этот код имеет смысл в конктексте конкретного сценария в определенной предметной области. и больше нигде - это бизнес логика.
Если он универсален и не зависит от конкретных сценариев, и может использоватся в любом проекте - то это инструментарий. Удивительно, что для вас это вопрос.
Стейт это общая часть приложения, без него приложение бесполезно. Так как стейт бесполезен без других компонентов системы.
и что? раз он безполезен в отрыве от других частей приложения, то он должен быть обязательно объединен с ними! Вы ведь именно так приводите к мысли, что домен не может выделен, так как он без каких-то инструментов.
Вы тоже не понимаете что такое "домен". Делаете вид что понимаете, нельзя понимать то, что оторвано от реальности.
конечно никто не может понять того, что не можете понять вы. Это именно так и работает. Даже если они говорят, что понимают - они ошибаются, так как вы не смогли прислушаться к ним и понять о чем они говорят.
Да нет, не слепое. И опять, TS и FSD вещи не сравнимы в данном контексте, TS == JS, именно "==". А FSD !== классике. Это диаметрально противоположная вещь.
во все нет. И там и там это некоторое усложнение чего-то, что бы потом получить профит. То что вы не можете этого осознать - ваша проблема. Примеры были даны.
Рассуждая "доменами" это не конкретные примеры. Это абстракции.
я дал вполне конкретный пример проекта. О чем вы говорите?
Разобрался давно, оно не работает во фронте без боли и страданий. А я не люблю боль и страдания, простая арифметика.
понимаю. Действительно, забивать ручкой молотка гвозди - боль и страдания. Не делайте этого. Если вдруг сможете слушать собеседника, то может услышате, что его нужно держать за ручку. Но почему-то вы предпочитаете не слушать, а говорить как неудобно пользоваться молотком. Чтож тут ничем не могу вам помочь.
ctrl + click в помощь. Страница на которой находится "подопытный" в помощь. В ее коде все видно и названий никаких знать не нужно.
отлично и в итоге вам нужно или помнить все нужные имена или что бы они были сразу тут в редакторе кода. У меня же они все доступны и слева в дереве папок. То есть у меня уже больше инструментов для навигации чем у вас.
Но с вашей логикй - вам можно вообще разбить на разделение. Вам не нужно в том примере с 200 компонентами их разбивать по папкам. более того, с учетом ваших аргументов можно туда сложить и хуки, и стейты, и утилиты. Следуйте kiss - не усложняйте.
Плохо, при условии если это мешает разработке. В остальных случая по барабану.
ну так выходит, что закрытость методов плохо. Ведь там ровно те же аргументы хза и против) Выходит вы против и приватных методов.
И как же эти "идиоты" не использующие ддд живут, кошмар просто. Счастливые люди.
как я уже сказал, не во всех проектах оно нужно
некоторые люди не понимают как неудобно им писать код до того как они освоили новые подходы. Я таких адептов с отказом от тс видел не мало.
Так вы сами не понимаете, говорите что вокруг одни проблемы и всё сложно, при это используете "домены" и "молоток" ддд. А я использую классику и говорю что все легко и просто. Так где выигрыш?
Я перечисляю какие проблемы можно получить в классике, и как их решает ддд.
С тем же успехом я бы мог объяснять как хорошо тс решает некоторые проблемы, и точно так же меня бы не слушали и говорили, что js - идеален и все типы это лишняя и бессмысленная сложность. Вообще 0 разницы.
Это не обязательно, можно так же делать и через себя.
Разумеется, потому что они идут в паре с инструментарием, с помощью которого бизнес логика обретает смысл.
далеко не всегда. Вполне типичный кейс когда митрофронты используют один и тот же кит.
А сама по себе отдельно бизнес логика никуда не выделяется, ибо она сама по себе никому не нужна.
голословное не верное высказывание. Почему-то я выделяю и это удобно. Вы просто не понимаете, что такое выделение бизнес логики. И продолжаете говорить что чего-то нет, хотя вы просто не пнимаете, что это такое.
Согласно вашей логике - выделять стейт в отдельны класс в принципе не не нужно, так как сам по себе без других компонентов он ничего не дает. Браво! срочно объедените стейт и отображение.
Вижу реальные вещи,
собственно что и требовалось доказать - вы не понимаете, что такое домен и как его использовать, а потом пытаетесь доказать что они не могут существоать. Для начала разберитесь с этим а потом делайте утверждения.
Были бы они, я бы искал пути их решения, а не мучался)
увы, слепое отрицание - именно так и проявляется. Например некоторые люди так отрицали тс. Только спустя какое-то время они согласились с его удобством.
Нет не докажет, но укажет на дешевые манипуляции.
Я хотя бы указывал на конкретные примеры, где вы вдруг любовь к большим проектам сравнили с наркоманией. Вы же просто раз за разом этим бросаетесь
но это не несет прямой связи с "доменами" и бизнес логико
ухх. я так понимаю про с ддд не разобрались.
1) CTRL+F в IDE пофигу сколько там компонентов в пространстве.
конечно, если ты знаешь имя. Удачи искать код, когда ты не знаешь имя. Удачи между ним переключатся когда дерево файлов проекта стало практически бессмысленным.
С чего это вдруг?
вы сами сказали что все должно быть гибко, удобно, и использоваться отовсюду. Ведь вы так против выступили закрытости доменов. Так как это не гибко, не удобно, и это нельзя раз и влепитькуда хочешь.
Принцип ровно тот же: вы считаете что закрытость определенного кода это плохо - так что я лишь продолжил вашу логику.
заметьте, это у меня нет никаких проблем с архитектурой и с навигацией и т.п.,
конечно нет проблем, так как вы терпеть не можете больших проектов и максимально быстро с них устраняетесь.
Я то как раз бью по гвоздю молотком,
Молоток - это разбиение проекта по ддд. Я предлагаю вам понять, что такое домен и как его использовать. Вы выхватываете молоток и начинаете его неверно использовать - как вы не верно используете ддд. Я вам указываю на вашу ошибку - что вы не верно поняли его использование. Вы продолжаете мысль, что если это молоток - и им нужно забивать гвозди, то можно бить и ручкой. (причем, судя по вам вы не пользовались молотком и вам никогда не приходилось забивать гвозди, ну ии вы забивали их плоскогубцами и посчитали это удобным).
Ну чтож, такое случается. Не хотите понимать как пользоваться ддд (молотком) в силу того что это сложно/непривычно/непонятно - ваше право. Только в следующий раз вступая в полемику сразу укажите что вы не понимаете, что такое домены и не хотите понимать. Ну или в вашей интерпретации: я реалист и никаких доменнов не может существовать. Этого в принципе хватит людям, для понимания бессмысленности дискусиии.
Ох уж эта отсылка авторитету. Я реалист/прагматик/гений/филантроп - значит я прав, а вы нет)
Страница логина - это страница логина. Кто спорит? И она так же смело принадлежать домену, например авторизации, в котором будет десяток страниц и компонентов.
Вы не видите доменов, соответственно из этого вытекает ваша не способность эффективно с ними работать.
Вас ноль проблем касающихся разбиения папок? Верю, на определенных проектах их и не будет. Более того для вас не проблема искать (и терять компоненты) в списках на 100+ штук. (Кстати это продемонстрировано на реальном примере, с которого вы сразу ушли, так как на нем видно проблемы классики)
Бизнес логика вполне выделяется. Микрофронтенды и микросервисы этому подтверждение. Но согласно вашей логике все должны от них отказаться так как доменов нет, и их нельзя выделить. Пойду напишу ребятам, пусть обратно все сливают ведь классика так прекрасно работает./с
И главное не забыть побольше вставить про то как собеседник манипулирует, это точно докажет что вы правы.
Окей на том и завершаем? Доменов не существует, соответственно микрофронты и микросервисы невозможно выделить и нужно слить?
Так же вы утверждаете, что в пространстве на 300 компонентов проще искать чем в пространстве на 30 компонентов. Конечно это так, кто может подумать иначе?
Так же выходит, что мы должны отказаться от приватных методов и вложенных компонентов. Все должно быть открыто, удобно и гибко)
P.s. казалось бы просто осмыслить что такое домен и как его можно реализовать - и все обретёт смысл, но видимо нужно продолжать бить гвоздь деревянной ручкой и утверждать что молоток не работает
Весь код использует реакт. Вывод? Реакт должен лежать в каждом домене) срочно распаковываем и складываем исходники!
В чем разница, что это за код пока он не привязан к бизнесу?
Кстати, шаред может вообще отсутствовать и все будет лежать в нодмодулях. Но согласно вашей логике: нужно срочно их вытащить и сложить в домены)
Это у вас религия что все что касается "Домена" должно лежать в его папке. Только есть нюанс, ваш "домен" на самом деле это ничто, пустышка, пустой слово.
Оно пустое для вас так как вы не понимаете его. Ещё раз: код хранит бизнес логику? Нет? Тогда почему он должен лежать в домене?
Согласно вашей логике, так как стейт компонента не имеет смысла без его отображения - вывод? Нужно их срочно объединить.
Соответственно, вы делаете неверные выводы из этого. Вы готовы слышать собеседника или мы тут расходимся? А то меня уже напрягают ваши попытки задеть собеседника с учётом, что вы взяли молоток, пытаетесь забить его ручкой гвоздь, утверждая что так и нужно (ведь он должен забить гвоздь, следовательно и ручкой это можно сделать), и из этого делаете вывод что молоток плохой инструмент. И в упор не слышите объяснений.
Я не понимаю, вы так хотите доказать, что вы правы и не готовы увидеть все это с другой перспективы? Окей, могу не мешать.
С ваших слов все что касается "домена" chat лежит не только в папке chat
можно привести слова, где говорится, что-то относящееся к домену чатне лежит в нем?
Т.е. если вы не будете форматировать дату и показывать пользователю из России YYYY-MM-DD вместо DD.MM.YYYY , то это ничего страшного, это к бизнес логике отношения не имеет?
не совсем понимаю вопрос. Давайте разберем: у нас есть датты которые нужно показывать исходя из локали пользователя, или от его настроек. Выглядит, как обычный инструментарий, и должен лежать в shared.
Бизнес логика не имеет никакого смысла и не несет ни какой пользы без инструментария.
Абсолютно верное высказывание, которое мне никак не противоречит. Ваш компонент не имеет никакого смысла без реакта, следует ли из этого, что вы код реакта должны раместить в компоненте? Вот и кит пусть лежит отдельно, а кто хочет - пусть к нему обращается.
Так что, получается используя shared вы лицемерите говоря что у вас все разбито по "доменам" и всё что касается "домена" лежит в его попке
Все что касается бизнеслоки домена лежит в домене. А причем тут инструментарий так и не понятно. В кнопке из material-ui есть бизнеслогика или привязанность к домену? нет. Так почему она должна лежать в его рамках? И реакт тащить в домен?
Это так забавно, как вы неправильно используете инструмент, а потом обвиняете, что оно не работает)
привел не надуманный пример, а вполне реальный пример.
Проблемы нет в применении uikit. Как видите он и в fsd максимально открыт.
Другое дело с доменами: тут как и в классах у вас есть закрытый и открытый функционал. У вас же все открытое и каждый может использовать все. Согласно вашей логике - мы должны отказаться от приватных методов, так как это мешает писать проект "просто". И вот это просто приводит к тому, что происходит хаос и все дёргают все подряд, и ты не можешь ничего поменять.
В доменах также история: мало того что навигация становится проще, за счёт структурирования, так же мы явно обозначили, что из этого мы делаем публичным, и чьи изменения мы должны учитывать в других местах кода. С приватными - гораздо проще, так зона их влияния гораздо меньше.
в моем случае это не будет каким-то правилом, это будет продиктовано удобством.
Чем больше проект растет, чем важнее его структурированность и согласованность, и правила помогают этому следовать. Вы раз за разом говорите про удобство, но на примере легко упустили части функционала.
Потому что для избегания дублирования вы все кладете в shared.
почему все? я складываю туда только то, что не связано с бизнес логикой. Соотвсетственно, я не понимаю проблемы: у нас в shared лежит всякий инструментарий, и с тем же успехом он мог лежать в node_modules. Пока это никак мне не противоречит. Все что относится к домену - лежит все еще к домену.
Назовите конкретный пример кода, котоырй я буду вынужден продублировать.
Как упомяналось вами выше: говорить и быть это разные вещи.
Если вы одно тяжело принимали, может и сейчас такаяже проблема?
Но более корректная в данном случае аналогия из спорта будет такая:
и вы искажаете ее под себя. Я люблю бегать марафоны (большие долгие проекты), а вы любите сприны (свежие небольгшие проекты). Я говорю, что пластырь на соски (фсд) - полезная и важная штука в определенных случаях (если вы бежите далеко). Вы начинаете доказывать, что пластырь это плохо, а моя любовь к марафонам - специфические вкусы.
Но в данном контексте любой из вкусов можно назвать специфичным.
Кстати возник еще один вопрос: вот вы и сами выделяете домены, хотя считаете, что все из них должно быть открыто для использвания. Скажите, какая принципиальная разница будет между тем, что домен будет на первом уровне папок (как у меня), а не на втором(как у вас)?
И в этом огромный плюс, в виде удобства, гибкости, скорости и отсствия лишнего дублирования.
так и у меня дублирования нет. Если компонент предполагает свое использование в других местах - открываем его в явном виде.
А по поводу остального: с той же аргументацией можно все методы класса сделать публичными - это тоже даст гибкость, удобство и скорость. (но это привнесет еще и те проблемы про которые я пишу)
А связь всех ко всем во первых высосана из пальца и не реалистична от слова совсем, во вторых возможность связи между компонентами системы на практике и в реальном мире дает только плюсы.
Конечно, никто не организует связь буквально всех с буквально всеми. Точно так же как если вы забудете про приватность методов классов и сделаете их все публичными - никто не начнет их все использовать сразу. Это со временем породит не прозрачные связи и зависимости которых и не должно было быть.
В моем же арианте все работает по белому списку - понадобилось открыть функционал? открыли. Это приводит к меньшему числу связей, а чем связей меньше тем проще менять код, так как его изменения нужно согласовывать с меньшим числом соседей.
. Да есть люди у которых вкусы специфичны, да есть люди которые нюхают клей, и т.п.
эк вас понесло, теперь люди которые имеют другие вкусы отличные от вас похожи на наркоманов. Почему бы не взять пример из спорта: вот вы любите бегать на скорость, а я полумарафоны. Следует ли что одно хуже другого? вовсе нет.
что в вашем конкретном случае есть особые предпочтения, они не объективные, а просто вам так нравится и считаете что так хорошо
объективные показатели в скорости поиска нужного кода я демонстрирую на примере. Субъективные на то субъективные, но вы почему-то чужие вкусы и мнене о ситуации называете самообманом, хотя сами в такой ситуации не находитесь и скорее всего никогда не были.
Настоящий FSD как и настоящий DDD без дублирования невозможен,
Почему же фсд не возможен? можно пример кода который я буду вынужден продублировать?
достаточно просто взглянуть) FSD не исключение)
Я знаю не мало людей которые считали что-то плохим пока не разобрались. Более того, разве вы не писали что изначально тс вам не понравился?
Кстати возник еще один вопрос: вот вы и сами выделяете домены, хотя считаете, что все из них должно быть открыто для использвания. Скажите, какая принципиальная разница будет между тем, что домен будет на первом уровне папок (как у меня), а не на втором(как у вас)?
В этом и смысл я взял классическую структуру в чистом виде и мы тут решаем куда и как ее менять.
Отлично, но вы пропустили вы пропустили, что есть еще много 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 так и лежит. Подобные кейсы очень частые.
Если сравнить две эти структуры - то выходит еще интереснее: в вашей структуре, очень много открытых для использования компонентов и функций, так как они все доступны на глобальном уровне. У меня же обратная ситуация - ничего из того что я осознано пометил как открытое для использования- наружу и не торчит. соотвественно сложнее получить связь всех ко всем.
что-то у вас конструктивизм совсем потерялся. и пошли суждения из разряда - что-то плохое потому, что плохое.
Более того вы уже дошли до того, что с уверенностью говорите о том как чувствует себя человек в определенной ситуации в которой вы сами не находитесь, и при этом ваши вкусы могут сильно отличаться от его.
Ключевое - "не обязательно". Потому что дублирование происходит и много.
Вы не пишите на фсд, но утверждаете что дублирование есть. Я на нем пишу и утверждаю что на моем проекте дублирования вытекающего из фсд нет.
Это теоретически возможно, но шанс крайне низок, ибо вкусы у такого человека должны быть специфическими, выбирать такое вместо проекта с нуля) Отсюда и ваши предпочтения все на ровном месте усложнять и драматизировать банальные и простые вещи как проблемы)
Да нет, просто если не боятся больших проектов, то все выходит вполне естественно. Но вот вы уже скатываетесь к аргументу к личности.
Хорошо, попробуем с другой строны, раз вы не понимате на синтетических примерах. Я сейчас возьму один из проектов написанных на классике, и попрошу в них что-то найти. Вы попробуете или найти нужный код по предложенному мной домену, или предложить, что можно сделать для упрощения его поиска. https://playcode.io/2233829. Давайте, вот тут посмотрим, что у нас есть по чатам? Как быстро вы нейдете весь функционал связанный с ними.
Открою тайну, разные "домены" могут и используют общие utils, в противном случае у вас ANtI DRY и дублирование кода.
а в чем секрет, и как это мне противоречит? Более того причем тут DRY?
2) В чем проблема? Ну лежат там разные утилиты, и что теперь? Как это реально мешает?
в тмо что у вас забит экран не нужными файлами, соотвественно навигация в них хуже. Согласитесь: найти 1 файл среди 10 проще чем среди 50. Более того, если вы даже не знаете как называется файл, то найти подходящий код пролистав 10 файлов проще чем 50. Зачем мне код каждого домена, если я могу использовать код только нужного? С такой логикой, а что бы нам все файлы не объеденить в один)
Ну когда вам говорят я видел НЛО в небе вчера и это прям точно пришельцы. Вы поверите?
В отличии от нло, я говорю про вполне реальную технологию, которую использовали некоторые люди и довольны. Более того я привел несколько кейсов когда она работает лучше.
По какой-то причине вы не можете допустить, что кому-то нравятся большие проекты и называете это самообманом. Ну чтож, если вы не любите острое - то никто не любит.
Потому что каждый ваш "домен" должен быть изолирован и не зависеть от чего-то ещё сверху, ведь всё что ему нужно лежит в его папке. Ну это в вашей религии опять же. В моей картине мира это бред полный.
нет никакой религии, только прагматизм. Ваше желание доказать свою правоту называя слова собеседника либо бредом либо обманом - куда больше показывает вашу склонность к религии. Более того, домены вполне себе поставляют апи, соотвественно вовсе не обязательно происходит дублирование кода. Более того, если взять fsd то там с этим еще проще.
Она супер легко и быстро адаптируется под конкретную специфику любого проекта.
быстро? да. Так же быстро она превращается в свалку, где все использует все, что приводит к циклическим зависимостям, высокой связности, кучей файлов лежащих в общем пространстве и т.п. Но если вам ок с таким работать - искренне рад за вас.
Если бы FSD давала реальный профит, то я бы без задней мыслей ей пользовался.
ну как мы видим, вы не готовы критически подойти к вашему суждению о фсд. Вы с кейсов переходите на бессмысленную полемику и на попытки назвать слова собеседника ложью.
потом что на фронте все со всем переплетено по умолчанию,
При плохом продумывании - да, именно так.
Нет, последние 8 лет я занимаюсь только фронтенд разработки ( а до этого на беке я был только на маленьких проектах, где ддд и не нужен был)
Я понимаю что есть люди которым нравится когда им причиняют боль и они специально делают так, что бы им больно жилось по жизни.
С тем же успехом я могу сказать это о вас. Ведь вы почему-то хотите видеть в папке по 40 файлов, хотя они никак не относятся к вашей задаче. Давайте прекратим с попытками задеть друг друга?
Потому что это заставит меня страдать. а я не хочу.
У меня тоже иногда возникает проблема с новыми технологиями и парадигмами. Зачастую при их изучении они кажутся неудобными и даже вредными. Что вполне естесственно, пока их не научиться правильно готовить.
, и так образом завуалированно возвышать себя это манипуляции это прикол.
Так вы же первый начали с того, что "настоящие программисты" должны быть вот такими (как вы). Я лишь парировал в вашем стиле.
Не совсем понимаю ваших комплексов тут. Есть разные задачи, и в каждой есть разные сложности. Например: в свежих проектах среднего размера - нужнохорошо разбираться в первоначальной настройке их. В больших проектах: нужно понимать как не превратить его в неповоротливого монстра. Это не разделение лучше/хуже. Это разделение по тому какие вопросы нужно решать в их рамках.
А почему они менее интересны?
Потому что в них меньше необходимость сильно продумывать архитектуру и декомпозицию. А я люблю ее продумывать и учитывать как это будет работать дальше - при развитии продукта, кода он будет только расти.
Ах, ну раз вы говорите что реальный, значит поверим вам на слово.
Нет ы должны поверить вам, что поправде проект был мне не приятен, хотя ни проекта, ни меня вы толком не знаете. Что-то вас кудато не туда понесло. Вы настолько не готовы согласиться с собеседником, что хотите обвинить его во лжи? Тогда видимо дискуссию можно завершать.
Нет, ровно столько, сколько нужно. Тем более все зависимости явные и очевидные, всё на ладони.
Кажется вы не понимаете о чем я говорю. у вас в принципе такая ситуация не может быть. Вот я открываю utils - и у меня лежат там только утилиты по нужному домену. Вы открываете utils, и у вас там утилиты по всем доменам + еще и технические утилиты. Так что нет, у вас открыто не все что нужно а намного больше.
Плюс тонны повторяющегося кода, т.к. это архитектура не особо дружит с DRY.
Почему не дружит? Не вижу никакой разницы в этом отношении с классикой.
От же самый сценарий с ней займет в разы больше времени чем в классике из-за неповоротливости, ограничений.
В зазы больше времени? на планировании разбиения по доменам это действительно займет больше времени, только не в разы, а на 1-2%. Ровно так же как как и любые другие ограничения кода которые заставляют задуматься о том как писать код, что бы потом не получить проблем.
YASGNI
Отличный принцип. Бавают проекты где и классическое разбиение избыточно, а можно все сложить в 1 - 2 файла. Но когда ты понимаешь что тебе понадобится больше 10 файлов, ты понимаешь, что нужна уже система распределения файлов.
В моем случае речь идет о ситуации когда файлов намного больше и классика уже плохо справляется.
Почему безальтернативно? Вам нужны другие технологии? Выделяем домен в микрофронт. И с разделением по ддд это проще сделать чем по классике, так как в ддд ты сразу придумываешь что ты делаешь публичным, а в классике, у тебя почти все публичное.
Более того не совсем понятен страх перед монорепом. В большинстве своем это хорошо работает. Нужно дальнейшее разбиение? Браво при ддд это проще.
Почему вас так удивляет, что фсд легко раскладывается в классику. В отличии от обратного преобразования тут у нас в путях у вас есть вся достаточная информация.
Понимаю, не ваша специфика. Но не обязательно противопоставлять как будто одна специфика лучше другой. С тем же успехом я могу парировать, что вы просто не умеете работать со сложными проектами, хотя у настоящего программиста должно хватать когнитивных способностей на это. Но давайте не будем таким заниматься?
Почему же, я работал и с маленькими и свежими проектами. Как я и указал - для них классики достаточно. Но честно говоря, мне такие проекты кажутся менее интересными.
Но довольно интересно, что возможно ваше суждение в первую очередь относиться к вам самим. У вас нет опыта решения тех проблем которые решал я, и вы считаете что мои решения плохие. В то время как я не считаю классику плохим решением во всех случаях. Она подойдёт для некоторого класса проектов, но далеко не для всех.
Не совсем понимаю про скованность. Почему вы думаете, что тут разбиение будет мнение гибкое чем в микрофронтах? Так то фсд или ДДД разложить обратно в классику - дело одного скрипта.
>Классика работает отлично на любых размерах
Странно зачем же ее тогда дробят?) нет она не работает отлично. На каждом уровне копится огромное колличество файлов. В то время как при разбитии на домены - эти проблемы становятся минимальны.
Вы знаете у меня возникает ощущение как будто я пытаюсь вам объяснить как хорошо кататься на лыжах по снегу, а вы говорите, что ролики плохо катаются по снегу и с лыжами тоже так будет.
Но это не так. Я регулярно использовал ту или иную модель разбиения по предметным областям - это решало вышеуказанные проблемы и описанные мной кейсы.
честно говоря думал ответить вам как обыно, так как у вас куча ошибок которые вы не осознаете, но вижу что это бесполезно. Укажу на 2 самых важных моментах:
Вы откровенно врете картинкой. У вас в папке компоненты 200 строк. и так же в hooks. Сделайте нормальную картинку и после этого попробуйте сюда залить и сказать что с этим удобно работать. (И после этого смеете что-то говорить про манипуляции?). У вас так же откровенная манипуляция про скорость разработки в фсд. Стоимость возрастает в разы? То есть вы 1 час пишите компонент, а потом 3 выбираете куда его сложить в фсд? Ухх в таком случае вам нельзя фсд пользоваться.
Вы не можете осознать термин домен и как с ним работать. Из этого вы раз за разом делаете не верные выводы. Более того это показывает вашу неспособность услышать собеседника. Что приводит меня к неутешительному выводу, дисскусия тут бесполезна.
Собственно, текущий разговор ничем не отличается от любого другого разговора с челоком, который что-то не понимает, не хочет понимать, но считает себя однозначно правым. Такие разговоры были у меня и с противниками ts, и с противниками реакта, и любой другой технологии или принципа. Они точно так же были на 100% уверены в свое правоте, точно так же не верно использовали инструмент, точно так же не хотели слушать собеседника.
Это довольно забавно как вы не понимаете, что такое допен, не хотите слушать, что это и как должно работать, и поэтому считаете, что это не работает.
Пожалуй, я вас на этом оставлю.
Вообще бывают разные варианты. Но не суть - микрофронты часто используют как разбиение по доменам. И даже вы упоминали их в этом контексте. А теперь вдруг доменов нет.
так же как вы разделяете, что должно лежать в стейте, а что не должно. Использую логику. Если вот этот код имеет смысл в конктексте конкретного сценария в определенной предметной области. и больше нигде - это бизнес логика.
Если он универсален и не зависит от конкретных сценариев, и может использоватся в любом проекте - то это инструментарий. Удивительно, что для вас это вопрос.
и что? раз он безполезен в отрыве от других частей приложения, то он должен быть обязательно объединен с ними! Вы ведь именно так приводите к мысли, что домен не может выделен, так как он без каких-то инструментов.
конечно никто не может понять того, что не можете понять вы. Это именно так и работает. Даже если они говорят, что понимают - они ошибаются, так как вы не смогли прислушаться к ним и понять о чем они говорят.
во все нет. И там и там это некоторое усложнение чего-то, что бы потом получить профит. То что вы не можете этого осознать - ваша проблема. Примеры были даны.
я дал вполне конкретный пример проекта. О чем вы говорите?
понимаю. Действительно, забивать ручкой молотка гвозди - боль и страдания. Не делайте этого. Если вдруг сможете слушать собеседника, то может услышате, что его нужно держать за ручку. Но почему-то вы предпочитаете не слушать, а говорить как неудобно пользоваться молотком. Чтож тут ничем не могу вам помочь.
отлично и в итоге вам нужно или помнить все нужные имена или что бы они были сразу тут в редакторе кода. У меня же они все доступны и слева в дереве папок. То есть у меня уже больше инструментов для навигации чем у вас.
Но с вашей логикй - вам можно вообще разбить на разделение. Вам не нужно в том примере с 200 компонентами их разбивать по папкам. более того, с учетом ваших аргументов можно туда сложить и хуки, и стейты, и утилиты. Следуйте kiss - не усложняйте.
ну так выходит, что закрытость методов плохо. Ведь там ровно те же аргументы хза и против) Выходит вы против и приватных методов.
как я уже сказал, не во всех проектах оно нужно
некоторые люди не понимают как неудобно им писать код до того как они освоили новые подходы. Я таких адептов с отказом от тс видел не мало.
Я перечисляю какие проблемы можно получить в классике, и как их решает ддд.
С тем же успехом я бы мог объяснять как хорошо тс решает некоторые проблемы, и точно так же меня бы не слушали и говорили, что js - идеален и все типы это лишняя и бессмысленная сложность. Вообще 0 разницы.
Это не обязательно, можно так же делать и через себя.
далеко не всегда. Вполне типичный кейс когда митрофронты используют один и тот же кит.
голословное не верное высказывание. Почему-то я выделяю и это удобно. Вы просто не понимаете, что такое выделение бизнес логики. И продолжаете говорить что чего-то нет, хотя вы просто не пнимаете, что это такое.
Согласно вашей логике - выделять стейт в отдельны класс в принципе не не нужно, так как сам по себе без других компонентов он ничего не дает. Браво! срочно объедените стейт и отображение.
собственно что и требовалось доказать - вы не понимаете, что такое домен и как его использовать, а потом пытаетесь доказать что они не могут существоать. Для начала разберитесь с этим а потом делайте утверждения.
увы, слепое отрицание - именно так и проявляется. Например некоторые люди так отрицали тс. Только спустя какое-то время они согласились с его удобством.
Я хотя бы указывал на конкретные примеры, где вы вдруг любовь к большим проектам сравнили с наркоманией. Вы же просто раз за разом этим бросаетесь
ухх. я так понимаю про с ддд не разобрались.
конечно, если ты знаешь имя. Удачи искать код, когда ты не знаешь имя. Удачи между ним переключатся когда дерево файлов проекта стало практически бессмысленным.
вы сами сказали что все должно быть гибко, удобно, и использоваться отовсюду. Ведь вы так против выступили закрытости доменов. Так как это не гибко, не удобно, и это нельзя раз и влепитькуда хочешь.
Принцип ровно тот же: вы считаете что закрытость определенного кода это плохо - так что я лишь продолжил вашу логику.
конечно нет проблем, так как вы терпеть не можете больших проектов и максимально быстро с них устраняетесь.
Молоток - это разбиение проекта по ддд. Я предлагаю вам понять, что такое домен и как его использовать. Вы выхватываете молоток и начинаете его неверно использовать - как вы не верно используете ддд. Я вам указываю на вашу ошибку - что вы не верно поняли его использование. Вы продолжаете мысль, что если это молоток - и им нужно забивать гвозди, то можно бить и ручкой. (причем, судя по вам вы не пользовались молотком и вам никогда не приходилось забивать гвозди, ну ии вы забивали их плоскогубцами и посчитали это удобным).
Ну чтож, такое случается. Не хотите понимать как пользоваться ддд (молотком) в силу того что это сложно/непривычно/непонятно - ваше право. Только в следующий раз вступая в полемику сразу укажите что вы не понимаете, что такое домены и не хотите понимать. Ну или в вашей интерпретации: я реалист и никаких доменнов не может существовать. Этого в принципе хватит людям, для понимания бессмысленности дискусиии.
Ох уж эта отсылка авторитету. Я реалист/прагматик/гений/филантроп - значит я прав, а вы нет)
Страница логина - это страница логина. Кто спорит? И она так же смело принадлежать домену, например авторизации, в котором будет десяток страниц и компонентов.
Вы не видите доменов, соответственно из этого вытекает ваша не способность эффективно с ними работать.
Вас ноль проблем касающихся разбиения папок? Верю, на определенных проектах их и не будет. Более того для вас не проблема искать (и терять компоненты) в списках на 100+ штук. (Кстати это продемонстрировано на реальном примере, с которого вы сразу ушли, так как на нем видно проблемы классики)
Бизнес логика вполне выделяется. Микрофронтенды и микросервисы этому подтверждение. Но согласно вашей логике все должны от них отказаться так как доменов нет, и их нельзя выделить. Пойду напишу ребятам, пусть обратно все сливают ведь классика так прекрасно работает./с
И главное не забыть побольше вставить про то как собеседник манипулирует, это точно докажет что вы правы.
Окей на том и завершаем? Доменов не существует, соответственно микрофронты и микросервисы невозможно выделить и нужно слить?
Так же вы утверждаете, что в пространстве на 300 компонентов проще искать чем в пространстве на 30 компонентов. Конечно это так, кто может подумать иначе?
Так же выходит, что мы должны отказаться от приватных методов и вложенных компонентов. Все должно быть открыто, удобно и гибко)
P.s. казалось бы просто осмыслить что такое домен и как его можно реализовать - и все обретёт смысл, но видимо нужно продолжать бить гвоздь деревянной ручкой и утверждать что молоток не работает
Весь код использует реакт. Вывод? Реакт должен лежать в каждом домене) срочно распаковываем и складываем исходники!
В чем разница, что это за код пока он не привязан к бизнесу?
Кстати, шаред может вообще отсутствовать и все будет лежать в нодмодулях. Но согласно вашей логике: нужно срочно их вытащить и сложить в домены)
Оно пустое для вас так как вы не понимаете его. Ещё раз: код хранит бизнес логику? Нет? Тогда почему он должен лежать в домене?
Согласно вашей логике, так как стейт компонента не имеет смысла без его отображения - вывод? Нужно их срочно объединить.
Соответственно, вы делаете неверные выводы из этого. Вы готовы слышать собеседника или мы тут расходимся? А то меня уже напрягают ваши попытки задеть собеседника с учётом, что вы взяли молоток, пытаетесь забить его ручкой гвоздь, утверждая что так и нужно (ведь он должен забить гвоздь, следовательно и ручкой это можно сделать), и из этого делаете вывод что молоток плохой инструмент. И в упор не слышите объяснений.
Я не понимаю, вы так хотите доказать, что вы правы и не готовы увидеть все это с другой перспективы? Окей, могу не мешать.
можно привести слова, где говорится, что-то относящееся к домену чатне лежит в нем?
не совсем понимаю вопрос. Давайте разберем: у нас есть датты которые нужно показывать исходя из локали пользователя, или от его настроек. Выглядит, как обычный инструментарий, и должен лежать в shared.
Абсолютно верное высказывание, которое мне никак не противоречит. Ваш компонент не имеет никакого смысла без реакта, следует ли из этого, что вы код реакта должны раместить в компоненте? Вот и кит пусть лежит отдельно, а кто хочет - пусть к нему обращается.
Все что касается бизнеслоки домена лежит в домене. А причем тут инструментарий так и не понятно. В кнопке из material-ui есть бизнеслогика или привязанность к домену? нет. Так почему она должна лежать в его рамках? И реакт тащить в домен?
Это так забавно, как вы неправильно используете инструмент, а потом обвиняете, что оно не работает)
привел не надуманный пример, а вполне реальный пример.
Проблемы нет в применении uikit. Как видите он и в fsd максимально открыт.
Другое дело с доменами: тут как и в классах у вас есть закрытый и открытый функционал. У вас же все открытое и каждый может использовать все. Согласно вашей логике - мы должны отказаться от приватных методов, так как это мешает писать проект "просто". И вот это просто приводит к тому, что происходит хаос и все дёргают все подряд, и ты не можешь ничего поменять.
В доменах также история: мало того что навигация становится проще, за счёт структурирования, так же мы явно обозначили, что из этого мы делаем публичным, и чьи изменения мы должны учитывать в других местах кода. С приватными - гораздо проще, так зона их влияния гораздо меньше.
Чем больше проект растет, чем важнее его структурированность и согласованность, и правила помогают этому следовать. Вы раз за разом говорите про удобство, но на примере легко упустили части функционала.
почему все? я складываю туда только то, что не связано с бизнес логикой. Соотвсетственно, я не понимаю проблемы: у нас в shared лежит всякий инструментарий, и с тем же успехом он мог лежать в node_modules. Пока это никак мне не противоречит. Все что относится к домену - лежит все еще к домену.
Назовите конкретный пример кода, котоырй я буду вынужден продублировать.
Как упомяналось вами выше: говорить и быть это разные вещи.
Если вы одно тяжело принимали, может и сейчас такаяже проблема?
и вы искажаете ее под себя. Я люблю бегать марафоны (большие долгие проекты), а вы любите сприны (свежие небольгшие проекты). Я говорю, что пластырь на соски (фсд) - полезная и важная штука в определенных случаях (если вы бежите далеко). Вы начинаете доказывать, что пластырь это плохо, а моя любовь к марафонам - специфические вкусы.
Но в данном контексте любой из вкусов можно назвать специфичным.
Кстати возник еще один вопрос: вот вы и сами выделяете домены, хотя считаете, что все из них должно быть открыто для использвания. Скажите, какая принципиальная разница будет между тем, что домен будет на первом уровне папок (как у меня), а не на втором(как у вас)?
так и у меня дублирования нет. Если компонент предполагает свое использование в других местах - открываем его в явном виде.
А по поводу остального: с той же аргументацией можно все методы класса сделать публичными - это тоже даст гибкость, удобство и скорость. (но это привнесет еще и те проблемы про которые я пишу)
Конечно, никто не организует связь буквально всех с буквально всеми. Точно так же как если вы забудете про приватность методов классов и сделаете их все публичными - никто не начнет их все использовать сразу. Это со временем породит не прозрачные связи и зависимости которых и не должно было быть.
В моем же арианте все работает по белому списку - понадобилось открыть функционал? открыли. Это приводит к меньшему числу связей, а чем связей меньше тем проще менять код, так как его изменения нужно согласовывать с меньшим числом соседей.
эк вас понесло, теперь люди которые имеют другие вкусы отличные от вас похожи на наркоманов.
Почему бы не взять пример из спорта: вот вы любите бегать на скорость, а я полумарафоны. Следует ли что одно хуже другого? вовсе нет.
объективные показатели в скорости поиска нужного кода я демонстрирую на примере. Субъективные на то субъективные, но вы почему-то чужие вкусы и мнене о ситуации называете самообманом, хотя сами в такой ситуации не находитесь и скорее всего никогда не были.
Почему же фсд не возможен? можно пример кода который я буду вынужден продублировать?
Я знаю не мало людей которые считали что-то плохим пока не разобрались. Более того, разве вы не писали что изначально тс вам не понравился?
Кстати возник еще один вопрос: вот вы и сами выделяете домены, хотя считаете, что все из них должно быть открыто для использвания. Скажите, какая принципиальная разница будет между тем, что домен будет на первом уровне папок (как у меня), а не на втором(как у вас)?
В этом и смысл я взял классическую структуру в чистом виде и мы тут решаем куда и как ее менять.
Отлично, но вы пропустили вы пропустили, что есть еще много 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 так и лежит. Подобные кейсы очень частые.
Если сравнить две эти структуры - то выходит еще интереснее:
в вашей структуре, очень много открытых для использования компонентов и функций, так как они все доступны на глобальном уровне. У меня же обратная ситуация - ничего из того что я осознано пометил как открытое для использования- наружу и не торчит. соотвественно сложнее получить связь всех ко всем.
что-то у вас конструктивизм совсем потерялся. и пошли суждения из разряда - что-то плохое потому, что плохое.
Более того вы уже дошли до того, что с уверенностью говорите о том как чувствует себя человек в определенной ситуации в которой вы сами не находитесь, и при этом ваши вкусы могут сильно отличаться от его.
Вы не пишите на фсд, но утверждаете что дублирование есть. Я на нем пишу и утверждаю что на моем проекте дублирования вытекающего из фсд нет.
Да нет, просто если не боятся больших проектов, то все выходит вполне естественно. Но вот вы уже скатываетесь к аргументу к личности.
Хорошо, попробуем с другой строны, раз вы не понимате на синтетических примерах. Я сейчас возьму один из проектов написанных на классике, и попрошу в них что-то найти. Вы попробуете или найти нужный код по предложенному мной домену, или предложить, что можно сделать для упрощения его поиска. https://playcode.io/2233829.
Давайте, вот тут посмотрим, что у нас есть по чатам? Как быстро вы нейдете весь функционал связанный с ними.
а в чем секрет, и как это мне противоречит? Более того причем тут DRY?
в тмо что у вас забит экран не нужными файлами, соотвественно навигация в них хуже. Согласитесь: найти 1 файл среди 10 проще чем среди 50.
Более того, если вы даже не знаете как называется файл, то найти подходящий код пролистав 10 файлов проще чем 50.
Зачем мне код каждого домена, если я могу использовать код только нужного?
С такой логикой, а что бы нам все файлы не объеденить в один)
В отличии от нло, я говорю про вполне реальную технологию, которую использовали некоторые люди и довольны. Более того я привел несколько кейсов когда она работает лучше.
По какой-то причине вы не можете допустить, что кому-то нравятся большие проекты и называете это самообманом. Ну чтож, если вы не любите острое - то никто не любит.
нет никакой религии, только прагматизм. Ваше желание доказать свою правоту называя слова собеседника либо бредом либо обманом - куда больше показывает вашу склонность к религии.
Более того, домены вполне себе поставляют апи, соотвественно вовсе не обязательно происходит дублирование кода. Более того, если взять fsd то там с этим еще проще.
быстро? да. Так же быстро она превращается в свалку, где все использует все, что приводит к циклическим зависимостям, высокой связности, кучей файлов лежащих в общем пространстве и т.п.
Но если вам ок с таким работать - искренне рад за вас.
ну как мы видим, вы не готовы критически подойти к вашему суждению о фсд. Вы с кейсов переходите на бессмысленную полемику и на попытки назвать слова собеседника ложью.
При плохом продумывании - да, именно так.
Нет, последние 8 лет я занимаюсь только фронтенд разработки ( а до этого на беке я был только на маленьких проектах, где ддд и не нужен был)
С тем же успехом я могу сказать это о вас. Ведь вы почему-то хотите видеть в папке по 40 файлов, хотя они никак не относятся к вашей задаче. Давайте прекратим с попытками задеть друг друга?
У меня тоже иногда возникает проблема с новыми технологиями и парадигмами. Зачастую при их изучении они кажутся неудобными и даже вредными. Что вполне естесственно, пока их не научиться правильно готовить.
Так вы же первый начали с того, что "настоящие программисты" должны быть вот такими (как вы). Я лишь парировал в вашем стиле.
Не совсем понимаю ваших комплексов тут. Есть разные задачи, и в каждой есть разные сложности. Например: в свежих проектах среднего размера - нужнохорошо разбираться в первоначальной настройке их. В больших проектах: нужно понимать как не превратить его в неповоротливого монстра. Это не разделение лучше/хуже. Это разделение по тому какие вопросы нужно решать в их рамках.
Потому что в них меньше необходимость сильно продумывать архитектуру и декомпозицию. А я люблю ее продумывать и учитывать как это будет работать дальше - при развитии продукта, кода он будет только расти.
Нет ы должны поверить вам, что поправде проект был мне не приятен, хотя ни проекта, ни меня вы толком не знаете. Что-то вас кудато не туда понесло. Вы настолько не готовы согласиться с собеседником, что хотите обвинить его во лжи? Тогда видимо дискуссию можно завершать.
Кажется вы не понимаете о чем я говорю. у вас в принципе такая ситуация не может быть. Вот я открываю utils - и у меня лежат там только утилиты по нужному домену. Вы открываете utils, и у вас там утилиты по всем доменам + еще и технические утилиты. Так что нет, у вас открыто не все что нужно а намного больше.
Почему не дружит? Не вижу никакой разницы в этом отношении с классикой.
В зазы больше времени? на планировании разбиения по доменам это действительно займет больше времени, только не в разы, а на 1-2%. Ровно так же как как и любые другие ограничения кода которые заставляют задуматься о том как писать код, что бы потом не получить проблем.
Отличный принцип. Бавают проекты где и классическое разбиение избыточно, а можно все сложить в 1 - 2 файла. Но когда ты понимаешь что тебе понадобится больше 10 файлов, ты понимаешь, что нужна уже система распределения файлов.
В моем случае речь идет о ситуации когда файлов намного больше и классика уже плохо справляется.
В чем самообман? Это вполне реальный кейс из моего опыта работы.
У вас есть глобал стор
У вас есть локальный стор
У вас есть страница
У вас есть кастомые хуки
У вас есть утилитарные функции
У вас есть компоненты (а в них сколько угодно уровней)
В итоге работая с одним сценарием - у вас открыто пол проекта в дереве файлов.
В ддд у меня будет открыта одна папка, внутри которой будут большинство нужных мне файлов.
Почему безальтернативно? Вам нужны другие технологии? Выделяем домен в микрофронт. И с разделением по ддд это проще сделать чем по классике, так как в ддд ты сразу придумываешь что ты делаешь публичным, а в классике, у тебя почти все публичное.
Более того не совсем понятен страх перед монорепом. В большинстве своем это хорошо работает. Нужно дальнейшее разбиение? Браво при ддд это проще.
Почему вас так удивляет, что фсд легко раскладывается в классику. В отличии от обратного преобразования тут у нас в путях у вас есть вся достаточная информация.
Понимаю, не ваша специфика. Но не обязательно противопоставлять как будто одна специфика лучше другой. С тем же успехом я могу парировать, что вы просто не умеете работать со сложными проектами, хотя у настоящего программиста должно хватать когнитивных способностей на это. Но давайте не будем таким заниматься?
Почему же, я работал и с маленькими и свежими проектами. Как я и указал - для них классики достаточно. Но честно говоря, мне такие проекты кажутся менее интересными.
Но довольно интересно, что возможно ваше суждение в первую очередь относиться к вам самим. У вас нет опыта решения тех проблем которые решал я, и вы считаете что мои решения плохие. В то время как я не считаю классику плохим решением во всех случаях. Она подойдёт для некоторого класса проектов, но далеко не для всех.
Не совсем понимаю про скованность. Почему вы думаете, что тут разбиение будет мнение гибкое чем в микрофронтах? Так то фсд или ДДД разложить обратно в классику - дело одного скрипта.
>Классика работает отлично на любых размерах
Странно зачем же ее тогда дробят?) нет она не работает отлично. На каждом уровне копится огромное колличество файлов. В то время как при разбитии на домены - эти проблемы становятся минимальны.
Вы знаете у меня возникает ощущение как будто я пытаюсь вам объяснить как хорошо кататься на лыжах по снегу, а вы говорите, что ролики плохо катаются по снегу и с лыжами тоже так будет.
Но это не так. Я регулярно использовал ту или иную модель разбиения по предметным областям - это решало вышеуказанные проблемы и описанные мной кейсы.