Не очень хороший пример в силу того, что при загрузке в полдня у тебя постоянные потери контекста и это сильно влияет на производительность. Более того, писать на своем каркасе, и на чужом - это небо и земля.
Не вижу причин почему приложение не может знать это автоматом. Точно так же, под капотом у него может крутиться бот, или любой другой механизм предсказаний. Но и как любой такой механизм - он может давать ошибки.
В то время как форма с запоминанием параметров и историей заказов дарит нам все тоже самое, но ещё и с контролем.
Если так хочется использовать бота - то под капотом всегда его можно держать, но в любом случае бот не может точно предсказать, где вы сегодня хотите получить заказ, или что именно вы хотите заказать.
Ну так у вас конфликты, долгие реквесты и говнокод вытекал из-за плохой архитектуры (и не только)
Что возвращает нас к тому, что вы не понимаете как эффективно настраивать и работать в больших проектах, но уверенно рассказываете другим - как нужно работать. Причем именно тем кто работал в больших проектах и решил те проблемы, которые вы не смогли. Это же насколько нужно быть самоуверенным в своей правоте и гнуть свою линию, не слушая собеседника?
Да. От того что что-то назвали хорошим, оно таковым не стало.
Микрофронт, как и микросервис вещь совершенно конкретная.
То есть с абстракциями и терминами вы не можете работать. Понимаю почему вы не смогли с доменом разобраться.
Эти "проблемы" с лихвой окупаются их преимуществами
Вы вообще знаете о чем говорите? Можно три главных плюса, и минуса микросервисы, а то не похоже что вы о чем говорите и что сравниваете.
Я не жаловался
Странно. То есть не вы писали как не хотите работать на больших старых проектах с большой кодовой базой.
это вы жалуетесь что большой проект(много компонентов) это
Я объясняю какие вызовы и проблемы стоят в больших проектах и как они решены. Вы же предлагаете их решать иначе, и я объясняю почему ваше решение не сработает.
Вот вам кейс и то как она выглядит
То есть с термином "кейс" вы не знакомы? Или каким образом у вас абстрактный недопример или схема стала кейсом.
Вы продолжаете юлить. Можно конкретный пример, где ваше распределение помогло в отношении с его отсутствием? Пока вы ни разу не смогли дать конкретный пример. Выходит у вас его и нет?
Вы же рациональный человек. Так покажите реальные кейсы где есть профит от этого распределения. Вы чёт там папки создаёте, перераспределяете, пути правите и т.д. . А профит так не написали, кроме лютой вкусовщины, реального сценария с пользой как нет так и нет.
а не приятно, как раз из-за того, что архитектура там была неудобная и с ней было тяжело и неприятно работать.
микрофронты и все проблемы махом испаряются.
круто и микрофронты как и микросервисы зачастую все делят на домены. Но домены это зло и их не существует)
Самое интересное, что распределение как микрофронтах можно получить и без них, не получив в довесок кучу проблем. Но почему-то вы тригеретись на этот вариант.
Вообще по барабану,
странно, то вы жаловались что толстый шаред - это плохо. А как увидели что он на классике в три раза хуже - так сразу по барабану)
Её структура, простота и никаких вредных ограничений.
Она хорошая так как хорошая. Гениальная аргументация. Кейс хоть один будет? что она дарит в отношении с распределением хаоситов?
Я работал на таких, и там была классика и никаких проблем касаемо архитектуры не было и в помине.
звучит недостоверно учитывая как вы выше писали о том как неприятно работать на таких проектах.
Вы называете компонентами всё на свете. Страницы, лейауты, реальные компоненты.
небыло такого.
Группировка, слышали о таком? Уже тысячный раз
конечно. И все это все еще лежит у вас в shared, и является "публичным апи" для вашего проекта.
А у меня это там не лежит, а распределено по доменам.
То есть у меня /components в разы уже ваших.
Бла бла бла. Что за "домен", что за компоненты,
понимаю вы не можете понять, что такое домен и из-за этого проблемы. Увы не могу понять вам, так как когда вам пытаются это объяснить вы выдумываете свое определение и на основе его делаете вывод о невозможности сущестования домена.
с какого перепуга в классике все на свете должно быть в src/components на верхнем уровне...
то что вы положили это в папку - это конечно хорошо (по сути все сводится к тому, что вы пытаетесь, сами того не осознавая выделетить домены), но в итоге у вас там все еще свалка, так как не все разбито в группы. То есть у вас в любом случае больше там компонентов
Я использую классику, точка.
Да. Но при этом если я использую ваши аргументы против фсд, уже по отношению к классике, то вы почему-то внятно не можете объяснить какие проблемы она решает. "удобно" и "логично" - это не описание кейсов, а обычная вкусовщина.
Поэтому в очередной раз повторяю вопрос: что привносит классика в виде улучшения на проект в соотношении с ее отсутствием? Учитывая, что на нее ее поддрержание тратятся ресурсы. ( например при добавлении групировки вам, нужно делать изменения во многих файлах, что пораждает конфликты на пр)
Похоже религиозное мышлению не у меня, а у вас, раз вас спрашивают о конкретных кейсах и пользе, а вы срываетесь на собеседника.
Удобна, более чем. И намного намного более приятна в использовании.
нет, не удобна.
Долго будем таким перекидываться? Более того откуда вам знать если для вас большие проекты не приятны, не удобны и работать вы с ними не хотите?
постоянный конфликтах в коде...
понимаю. Если с инструментом не уметь работать - то все так и будет. Правда тут проблема в том кто его использует.
Нет, не растет быстрее. Кол-во компонентов в src/components равно кол-ву общих компонентов.
вы опять не читаете и опять делаете утверждения не понимая на что вам указали. У меня есть общие компоненты для проекта - они действительно лежат в компонентах. И по сути это только ui-kit. У вас же любой компонент который используется больше чем в одном месте - там оказывается. То есть у вас в компонентс свалка растет прямо пропорционально росту проекта и зависимостей в функционале.
У меня же эти компоненты лежат в домене. Так что нет, вы абсоютно не правы.
Это в вашей выдуманной хаос архитектуре растет, где все лежит в src =)
Все верно, ведь по вашим сценариям и доводам в пользу классики - это не проблема. Соотвественно, я и предложил вам продолжить оптимизацию, ровно в соответствии с вашей аргументацией.
Ну и повторим:
Вы же рациональный человек. или уже нет? Вы сказали что не хотите тратить ресурсы поддержание структуры. И я вам предложил другое распределение, в котором явно будет меньше затрат на ее поддержаие (причем, я даже привел конктретные кейсы, когда у вас даже пул реквесты становится тяжелее из-за необходимости поддержки структуры). Так почему же как фанатик уцепились за менее экономически обоснованный инструмент? Или в нем есть какие либо обоснования?
не ну вы же рациональный человек. или уже нет? Вы сказали что не хотите тратить ресурсы поддержание структуры. И я вам предложил другое распределение, в котором явно будет меньше затрат на ее поддержаие (причем, я даже привел конктретные кейсы, когда у вас даже пул реквесты становится тяжелее из-за необходимости поддержки структуры). Так почему же как фанатик уцепились за менее экономически обоснованный инструмент? Или в нем есть какие либо обоснования?
Вы продолжаете юлить.
Затем что она покрывает абсолютно все сценарии и размеры проектов.
нет, она не удобна на действительно больших проектов на которых вы не хотите работать и судя по всему вы не умеете с ними работать. Возможно как раз из-за не понимания как классика плохо с ними справляется и что как работать с доменами.
Я показал на простейшем примере как у вас папка components растет в разы быстрее моего shared, и это только один из примеров.
спасибо. Комментарии на хабре просто ужасны и сложно отлеживать, что к чему.
Погодите, мы сравниваем сейчас не fsd против классики, а классику против хаоса с выделенными pages, для простоты назовем ее хаоситное распределение. (у меня распределение по фсд так же почти не занимает времени, так как я понимаю как распределять файлы)
Ну так вы все равно думаете, и складываете, и еще переодически перераспределяете. Это все еще расходы.
Вот даже конкретный кейс: вы сказали, что иногда объединяете компоненты внутри компонентов. Это тоже время:
вы должны прийти к решению, что это изменение нужно
вы должны создать папку и перенести файлы
вы должны поправить пути (если иде не отработало)
в идеале это должно идти отдельным коммитом, а то и пр что бы ревьюить было проще.
Сделайте ctrl+f по этой странице по слову "интуитивно", увидите все места где я называл плюсы классики.
поискал.
То, что классика все всём лучше, это да, тут всё однозначно
ну так и в хаоситном распределение все понятно, и вообще никак нельзя ошибиться: страница? кладем в страницы. Не страница? кладем в кучу. Все равно по кликам находим и посику находим. Более того даже перераспределение не нужно. Мне не нужно иногда объединять несколько компонентов в папку, или вытаскивать из страницы общий компонент в общие.
Остальные комменты не к чему, они больше связаны с тем что вы не разобрались с технологией и захейтили ее. С тем же успехом люди ts хейтят. Это мы еще не разобрались зачем мы вообще классику используем. Можно кейсы где видно облегчение жизни от ее использования?
Я не трачу) Она не накладывает расходов, базовые в расчет неберем типо напечатать название файла/папки)
погодите, это все равно расходы. Еще раз зачем вы их делаете если они не нужны? Почему вы внятно ответить на этот вопрос не можете? Если они нужны, то будет интересно услышать, аргументы.
более того вы слукавили когда сказали что думать совершенно не нужно. Я дал вам конкретный пример:
Более того вам еще нужно подумать куда его положить: /components/chat/ или в /pages/chatHistory/components
Более того вы сказали, что иногда объединяете компоненты внутри компонентов. Это тоже время:
вы должны прийти к решению, что это изменение нужно
вы должны создать папку и перенести файлы
вы должны поправить пути (если иде не отработало)
в идеале это должно идти отдельным коммитом, а то и пр что бы ревьюить было проще.
Так что хватит юлить, вы тратите какое-то время на какое-то распределение. Но пока ни одного плюса этого распределения не назвали. Но почему-то вы другое распределение назвали плохим, хотя вы не понимаете как им пользоватся.
Логика ваших ответов потерялась. Вам задают вопрос -какие преемущества привносит классика, в сравнении с хаосом и папкой pages? какие проблемы она решает?
никаких проблем нет и не было.
отлично значит нет смысла ее использовать, раз она никакие проблемы не решает)
а что маловато? куда вы юлите? вы сказали, что вам главное найти страницу, а дальше вы прокликаете куда нужно. Но вы зачем-то тратите ресурсы на поддержание вашей структуры.
Так зачем же? какую проблему решила ваша группировка?)
конечно - вашим распределением. Так какие же это были проблемы? пока их не видно, и следовательно зачем вам, ваше распределение?
Мне классика дает профит, я ни разу не говорил что она не дает профит. И я с её помощью экономлю много времени и нервов, иначе я бы ей не
отлично, как вы экономите ресурсы? уже наверное 10 раз спрашиваю, а вы все юлите. Ведь, по вашим словам вам главное найти папку со страницами, а все остальное не важно.
ну как же? вот вы говорите вы сложили их в страницы. Браво. У нас 3 страницы используют один и тот же компонент. Вы его куда кладете? в общие компоненты, или каждая страница лезет в код страницы другой?
В первом случае у вас разбухает /components/ Во втором все еще веселее пространство потенциальных компонентов теперь лежит не только /components, но и во всех страницах.
То есть у вас в любом случае число компонентов лежащих на верхнем уровне выше чем у меня. И при росте проекта соотношение становится только хуже.
Настолько банальные до абсурда вещи опускаются когда речь идёт о ограничениях. Разумеется никто не будет класть страницу в хуки или utils.
но это тем не менее ограничение. Так зачем оно нужно? Вы сами сказали что ограничений нет.
Я не трачу на нее время.
опять обман, положить файл в корень всегда быстрее чем его класть в любой другой путь.
Более того вам еще нужно подумать куда его положить: /components/chat/ или в /pages/chatHistory/components
так, что лукавите вы про отсуствие накладных расходов. Они есть.
Опять вопрос: зачем они нужны, если вы все равно не используете навигацию по папкам.
Более того вы сказали, что иногда объединяете компоненты внутри компонентов. Это тоже время:
вы должны прийти к решению, что это изменение нужно
вы должны создать папку и перенести файлы
вы должны поправить пути (если иде не отработало)
в идеале это должно идти отдельным коммитом, а то и пр что бы ревьюить было проще.
вот сколько дел, что бы поддерживать вашу группировку. Ненужно лукавить
Я не знаю о чем вы, у меня нет проблем, и не было)
ну так вы же тратите время разпределяя файлы. Значит вы решаете какую-то проблему этим. Вы же реалист и не делали бы это просто так? Куда вы юлите - зачем вы делаете вашу архитектуру "здорового" человека? (кстати распределение папокй - это не архитектура)
Складывайте если хотите)
Ну как же, вам вот такой реквест выставят в проекте - так вы его сразу зарубите. Значит какие-то правила у вас есть. А говорили никаких правил и ограничений.
У меня нет такой логики) Я сто раз показывал скриншот как я группирую файлы и папки) Ваши фантазии не знаю)
погодите, вы сами сказали, что
ctrl + click в помощь. Страница на которой находится "подопытный" в помощь. В ее коде все видно и названий никаких знать не нужно.Тут не надо ничего помнить и знать, зашли в код интересующей вас страницы нашли что надо.
так согласно этой логике - нам ничего не нужно кроме как найти страницу. Или это не ваша логика? Если нам нужно найти только страницу, то вообще не важно где лежит остальное и как.
Так зачем вы тратите время, на ваше "здоровое" распределение?
Моего разбиения хватает выше крыше)
так и ваше не нужно, так как оно не решает никаких проблем)
Потому что в классике оно сюрприз логическое и интуитивное.
Конечно, то что для вас не понятно - нелогично для вас. Только проблема не в том, что оно не логичное, а в том что вы не поняли и даже не хотите понимать
Так вы ответите зачем вы тратите в разы больше времени на вашу "архитектуру", если она не дает профитов и мы легко находим код и без такого распределения папок (согласно вашим собственным утверждениям)
Остальные 170 общих компонентов которые все части системы используют значит выкинули в мусору, оке
окей, давайте допустим, что у нас 200 общих компонентов. На вскидку мне не приходит на ум никаких общих компонентов, кроме ui-kit. То есть у вас кит на 200 (что скорее всего указывает на его плохое проектирование). Если у вас такой только кит, то смело предположу, что весь проект содержит минимум 2000 компонентов.
итого, у меня в шаред лежит кит на 200 файлов с разбитием по категориям. и строго понятно, что эти 200 и предполагают их переиспользование.
у вас в компонентс лежит 2200 компонентов. половина из которых имеет смысл только в контексте других компонентов.
И вы говорите, что ваш шаред (ой простите, компонентс) лучше.
Вы наверное из любителей создавать классы на 100 методов?
Так бы и сказали, что это не общие компоненты которые принято держать в папке src/pages/{pageName}/components , а вообще все компоненты в проекте
тогда тем более не понятна ваша логика и спор. Как я и сказал - ваши страницы выступают в роли слабо сформированных доменов. С ростом проекта - когда станет понятно, что есть несколько страниц использующие одни и те же компоненты, то будет желание либо вынести эти компоненты в /components, либо создать домен, в котором будут лежать и эти страницы и компоненты.
Судя по вам вы предпочтете первое, и я показал на примере к чему это приводит.
) Я страницы кладу в pages
воот, а говорите правил и ограничений нет. Ведь на ревью вы запретите человеку класть страницы в хуки.
Да более того у вас даже принцип закрытости скорее всего соблюдается и компоненты, которые лежат в папке одной страницы не импортируются в рамках другой.
Так зачем вы тратите в разы больше времени на пооддержание этой структуры, и решаете проблемы которых нет? вы сами сказали что поиск компонента и зависимостей делаются через ctr.
я всего лишь применяю вашу аргументацию против вас. просто теперь я занял ваше место, и теперь, так же как и вы, начинаю утверждать, что раз в системе есть какие-то правила и их кто-то не понял то она сложная и избыточная.
Так почему же мы не можем все сложить в общую папку (кроме страниц), а вдруг должны делать какое-то разбиение (использующее вашу логику). Давайте все сложим на верхнем уровне кроме страниц. Ведь вы сами сказали, что разбиение не важно, так как оно не решает никаких проблем. Так зачем оно вам нужно (ваше логичное и правильное разбиение), если вы все равно через ctr + клик навигируете? Зачем на его поддержку вы тратите в РАЗЫ больше времени, и героически превозмогаете проблемы которых нет? (интересно, а вы тут себя уже узнали, или нет?)
А не ограничения и правила которые силой мне решил навязать
Т.е. в shared не место для общих компонентах приложения которые используются разными его частями сколько угодно раз?)
почему же нет? место. только их будет меньше 30
Да не вопрос, я в этом не сомневаюсь. Но это не дает профита.
погодите вас кудато не туда понесло. Еще раз вы сделали утвердждение:
Если в проекте 200 общих компонентов, то они просто будут лежать в папке shared если используется fsd.
я вас за язык не тянул. Так выходит оно неверное? так как нет у меня не будет ни в одной папке проекта 30 файлов. Так как у нас получилось из проекта где всего 200 компонентов, вдруг 200 общих компонентов?
Более того, я их группирую по определённым признакам и у меня нет простыни из 200 компонентов.
вот это поворот. Зачем же вы это делаете? Ведь нет никаких проблем и вы можете спойно прокликать позависомстям? Зачем вы тратите в РАЗЫ больше времни и поддерживаете какую-то структуру. Это же неудобно.
Но в классике то есть группировка и она ничего не запрещает, какое тут может быть поражение?
очередной обман. давай страницу положим в хуки. почему нет-то? или кто это может запретить?
Вы писали что по "моей" логике, ничего в папки складывать не надо, можно просто на плоском уровне все пихать и всё. А я просто показал(сотый раз) что я так не делаю и у меня есть папки под конкретные нужны проекта.
все верно, вы сказали: что бы мне чтото найти я захожу на страницу и кликаю по нужной зависимости. Согласно таким рассуждениям - классическое разбиение избыточно, так как в не пользуетесь навигацией по папке кроме как найти нужную страницу. Вам вполне хватит только наличие папки pages. А вы городите что-то непонятное тратя В РЫЗЫ больше времени. зачем вам столько отдельных папкок? плодите всякие /components /hooks и т. п. (искользую ваши методы против вас)
Ещё раз: у вас на картинке обман. Нарисуйте ее нормально и честно где у вас в каждой папке полный список файлов. Я вам даже ральный пример скинул для компонентов
Если в проекте 200 общих компонентов, то они просто будут лежать в папке shared если используется fsd.
нет не будет. Вы не понимаете как пользоваться инструментом и опять пишите глословные утверждения.
Давайте проверим насколько вы способны к диалогу? вот у нас есть конкретный пример по ссылке. Я его расскладываю по ддд, и вы пытаетесь показать, где у меня хоть на одном уровне наберется хотя бы 30 файлов.
Если у меня получается - вы признаете свою ошибку. Если вы не признаете - то мы понимаем что вы раз за разом используете обман и не умеете принимать противоречащие вам факты.
Не очень хороший пример в силу того, что при загрузке в полдня у тебя постоянные потери контекста и это сильно влияет на производительность. Более того, писать на своем каркасе, и на чужом - это небо и земля.
Ни рефакторинг, ни ревью не дают таких гарантий. Чего уж там, даже мануальное тестирование и регресс продукта 100% гарантий не дают.
А ревьюить код за нейронкой может человек, а то и другая нейронка, это все же не писать с нуля
Не вижу причин почему приложение не может знать это автоматом. Точно так же, под капотом у него может крутиться бот, или любой другой механизм предсказаний. Но и как любой такой механизм - он может давать ошибки.
В то время как форма с запоминанием параметров и историей заказов дарит нам все тоже самое, но ещё и с контролем.
Если так хочется использовать бота - то под капотом всегда его можно держать, но в любом случае бот не может точно предсказать, где вы сегодня хотите получить заказ, или что именно вы хотите заказать.
Ну так у вас конфликты, долгие реквесты и говнокод вытекал из-за плохой архитектуры (и не только)
Что возвращает нас к тому, что вы не понимаете как эффективно настраивать и работать в больших проектах, но уверенно рассказываете другим - как нужно работать. Причем именно тем кто работал в больших проектах и решил те проблемы, которые вы не смогли. Это же насколько нужно быть самоуверенным в своей правоте и гнуть свою линию, не слушая собеседника?
Да. От того что что-то назвали хорошим, оно таковым не стало.
То есть с абстракциями и терминами вы не можете работать. Понимаю почему вы не смогли с доменом разобраться.
Вы вообще знаете о чем говорите? Можно три главных плюса, и минуса микросервисы, а то не похоже что вы о чем говорите и что сравниваете.
Странно. То есть не вы писали как не хотите работать на больших старых проектах с большой кодовой базой.
Я объясняю какие вызовы и проблемы стоят в больших проектах и как они решены. Вы же предлагаете их решать иначе, и я объясняю почему ваше решение не сработает.
То есть с термином "кейс" вы не знакомы? Или каким образом у вас абстрактный недопример или схема стала кейсом.
Вы продолжаете юлить. Можно конкретный пример, где ваше распределение помогло в отношении с его отсутствием? Пока вы ни разу не смогли дать конкретный пример. Выходит у вас его и нет?
Вы же рациональный человек. Так покажите реальные кейсы где есть профит от этого распределения. Вы чёт там папки создаёте, перераспределяете, пути правите и т.д. . А профит так не написали, кроме лютой вкусовщины, реального сценария с пользой как нет так и нет.
Как юлили так и юлите
а не приятно, как раз из-за того, что архитектура там была неудобная и с ней было тяжело и неприятно работать.
круто и микрофронты как и микросервисы зачастую все делят на домены. Но домены это зло и их не существует)
Самое интересное, что распределение как микрофронтах можно получить и без них, не получив в довесок кучу проблем. Но почему-то вы тригеретись на этот вариант.
странно, то вы жаловались что толстый шаред - это плохо. А как увидели что он на классике в три раза хуже - так сразу по барабану)
Она хорошая так как хорошая. Гениальная аргументация. Кейс хоть один будет? что она дарит в отношении с распределением хаоситов?
звучит недостоверно учитывая как вы выше писали о том как неприятно работать на таких проектах.
небыло такого.
конечно. И все это все еще лежит у вас в shared, и является "публичным апи" для вашего проекта.
А у меня это там не лежит, а распределено по доменам.
То есть у меня /components в разы уже ваших.
понимаю вы не можете понять, что такое домен и из-за этого проблемы. Увы не могу понять вам, так как когда вам пытаются это объяснить вы выдумываете свое определение и на основе его делаете вывод о невозможности сущестования домена.
то что вы положили это в папку - это конечно хорошо (по сути все сводится к тому, что вы пытаетесь, сами того не осознавая выделетить домены), но в итоге у вас там все еще свалка, так как не все разбито в группы. То есть у вас в любом случае больше там компонентов
Да. Но при этом если я использую ваши аргументы против фсд, уже по отношению к классике, то вы почему-то внятно не можете объяснить какие проблемы она решает. "удобно" и "логично" - это не описание кейсов, а обычная вкусовщина.
Поэтому в очередной раз повторяю вопрос: что привносит классика в виде улучшения на проект в соотношении с ее отсутствием? Учитывая, что на нее ее поддрержание тратятся ресурсы. ( например при добавлении групировки вам, нужно делать изменения во многих файлах, что пораждает конфликты на пр)
Похоже религиозное мышлению не у меня, а у вас, раз вас спрашивают о конкретных кейсах и пользе, а вы срываетесь на собеседника.
нет, не удобна.
Долго будем таким перекидываться? Более того откуда вам знать если для вас большие проекты не приятны, не удобны и работать вы с ними не хотите?
понимаю. Если с инструментом не уметь работать - то все так и будет. Правда тут проблема в том кто его использует.
вы опять не читаете и опять делаете утверждения не понимая на что вам указали. У меня есть общие компоненты для проекта - они действительно лежат в компонентах. И по сути это только ui-kit. У вас же любой компонент который используется больше чем в одном месте - там оказывается. То есть у вас в компонентс свалка растет прямо пропорционально росту проекта и зависимостей в функционале.
У меня же эти компоненты лежат в домене. Так что нет, вы абсоютно не правы.
Все верно, ведь по вашим сценариям и доводам в пользу классики - это не проблема. Соотвественно, я и предложил вам продолжить оптимизацию, ровно в соответствии с вашей аргументацией.
Ну и повторим:
Вы же рациональный человек. или уже нет? Вы сказали что не хотите тратить ресурсы поддержание структуры. И я вам предложил другое распределение, в котором явно будет меньше затрат на ее поддержаие (причем, я даже привел конктретные кейсы, когда у вас даже пул реквесты становится тяжелее из-за необходимости поддержки структуры). Так почему же как фанатик уцепились за менее экономически обоснованный инструмент? Или в нем есть какие либо обоснования?
Вы продолжаете юлить.
не ну вы же рациональный человек. или уже нет? Вы сказали что не хотите тратить ресурсы поддержание структуры. И я вам предложил другое распределение, в котором явно будет меньше затрат на ее поддержаие (причем, я даже привел конктретные кейсы, когда у вас даже пул реквесты становится тяжелее из-за необходимости поддержки структуры). Так почему же как фанатик уцепились за менее экономически обоснованный инструмент? Или в нем есть какие либо обоснования?
Вы продолжаете юлить.
нет, она не удобна на действительно больших проектов на которых вы не хотите работать и судя по всему вы не умеете с ними работать. Возможно как раз из-за не понимания как классика плохо с ними справляется и что как работать с доменами.
Я показал на простейшем примере как у вас папка components растет в разы быстрее моего shared, и это только один из примеров.
спасибо. Комментарии на хабре просто ужасны и сложно отлеживать, что к чему.
Погодите, мы сравниваем сейчас не fsd против классики, а классику против хаоса с выделенными pages, для простоты назовем ее хаоситное распределение. (у меня распределение по фсд так же почти не занимает времени, так как я понимаю как распределять файлы)
Ну так вы все равно думаете, и складываете, и еще переодически перераспределяете. Это все еще расходы.
Вот даже конкретный кейс: вы сказали, что иногда объединяете компоненты внутри компонентов. Это тоже время:
вы должны прийти к решению, что это изменение нужно
вы должны создать папку и перенести файлы
вы должны поправить пути (если иде не отработало)
в идеале это должно идти отдельным коммитом, а то и пр что бы ревьюить было проще.
поискал.
ну так и в хаоситном распределение все понятно, и вообще никак нельзя ошибиться: страница? кладем в страницы. Не страница? кладем в кучу. Все равно по кликам находим и посику находим. Более того даже перераспределение не нужно. Мне не нужно иногда объединять несколько компонентов в папку, или вытаскивать из страницы общий компонент в общие.
Остальные комменты не к чему, они больше связаны с тем что вы не разобрались с технологией и захейтили ее. С тем же успехом люди ts хейтят. Это мы еще не разобрались зачем мы вообще классику используем. Можно кейсы где видно облегчение жизни от ее использования?
погодите, это все равно расходы. Еще раз зачем вы их делаете если они не нужны? Почему вы внятно ответить на этот вопрос не можете? Если они нужны, то будет интересно услышать, аргументы.
более того вы слукавили когда сказали что думать совершенно не нужно. Я дал вам конкретный пример:
Более того вы сказали, что иногда объединяете компоненты внутри компонентов. Это тоже время:
вы должны прийти к решению, что это изменение нужно
вы должны создать папку и перенести файлы
вы должны поправить пути (если иде не отработало)
в идеале это должно идти отдельным коммитом, а то и пр что бы ревьюить было проще.
Так что хватит юлить, вы тратите какое-то время на какое-то распределение. Но пока ни одного плюса этого распределения не назвали. Но почему-то вы другое распределение назвали плохим, хотя вы не понимаете как им пользоватся.
Логика ваших ответов потерялась. Вам задают вопрос -какие преемущества привносит классика, в сравнении с хаосом и папкой pages? какие проблемы она решает?
никаких проблем нет и не было.
отлично значит нет смысла ее использовать, раз она никакие проблемы не решает)
Что и как она ускоряет?
она ускоряет за счет использования класики!
Гениально!
а что маловато? куда вы юлите? вы сказали, что вам главное найти страницу, а дальше вы прокликаете куда нужно. Но вы зачем-то тратите ресурсы на поддержание вашей структуры.
Так зачем же? какую проблему решила ваша группировка?)
конечно - вашим распределением. Так какие же это были проблемы? пока их не видно, и следовательно зачем вам, ваше распределение?
отлично, как вы экономите ресурсы? уже наверное 10 раз спрашиваю, а вы все юлите. Ведь, по вашим словам вам главное найти папку со страницами, а все остальное не важно.
ну как же? вот вы говорите вы сложили их в страницы. Браво. У нас 3 страницы используют один и тот же компонент. Вы его куда кладете? в общие компоненты, или каждая страница лезет в код страницы другой?
В первом случае у вас разбухает /components/
Во втором все еще веселее пространство потенциальных компонентов теперь лежит не только /components, но и во всех страницах.
То есть у вас в любом случае число компонентов лежащих на верхнем уровне выше чем у меня. И при росте проекта соотношение становится только хуже.
но это тем не менее ограничение. Так зачем оно нужно? Вы сами сказали что ограничений нет.
опять обман, положить файл в корень всегда быстрее чем его класть в любой другой путь.
Более того вам еще нужно подумать куда его положить:
/components/chat/ или в /pages/chatHistory/components
так, что лукавите вы про отсуствие накладных расходов. Они есть.
Опять вопрос: зачем они нужны, если вы все равно не используете навигацию по папкам.
Более того вы сказали, что иногда объединяете компоненты внутри компонентов. Это тоже время:
вы должны прийти к решению, что это изменение нужно
вы должны создать папку и перенести файлы
вы должны поправить пути (если иде не отработало)
в идеале это должно идти отдельным коммитом, а то и пр что бы ревьюить было проще.
вот сколько дел, что бы поддерживать вашу группировку. Ненужно лукавить
ну так вы же тратите время разпределяя файлы. Значит вы решаете какую-то проблему этим. Вы же реалист и не делали бы это просто так? Куда вы юлите - зачем вы делаете вашу архитектуру "здорового" человека? (кстати распределение папокй - это не архитектура)
Ну как же, вам вот такой реквест выставят в проекте - так вы его сразу зарубите. Значит какие-то правила у вас есть. А говорили никаких правил и ограничений.
погодите, вы сами сказали, что
так согласно этой логике - нам ничего не нужно кроме как найти страницу. Или это не ваша логика? Если нам нужно найти только страницу, то вообще не важно где лежит остальное и как.
Так зачем вы тратите время, на ваше "здоровое" распределение?
так и ваше не нужно, так как оно не решает никаких проблем)
Конечно, то что для вас не понятно - нелогично для вас. Только проблема не в том, что оно не логичное, а в том что вы не поняли и даже не хотите понимать
Так вы ответите зачем вы тратите в разы больше времени на вашу "архитектуру", если она не дает профитов и мы легко находим код и без такого распределения папок (согласно вашим собственным утверждениям)
окей, давайте допустим, что у нас 200 общих компонентов. На вскидку мне не приходит на ум никаких общих компонентов, кроме ui-kit. То есть у вас кит на 200 (что скорее всего указывает на его плохое проектирование). Если у вас такой только кит, то смело предположу, что весь проект содержит минимум 2000 компонентов.
итого, у меня в шаред лежит кит на 200 файлов с разбитием по категориям. и строго понятно, что эти 200 и предполагают их переиспользование.
у вас в компонентс лежит 2200 компонентов. половина из которых имеет смысл только в контексте других компонентов.
И вы говорите, что ваш шаред (ой простите, компонентс) лучше.
Вы наверное из любителей создавать классы на 100 методов?
тогда тем более не понятна ваша логика и спор. Как я и сказал - ваши страницы выступают в роли слабо сформированных доменов. С ростом проекта - когда станет понятно, что есть несколько страниц использующие одни и те же компоненты, то будет желание либо вынести эти компоненты в /components, либо создать домен, в котором будут лежать и эти страницы и компоненты.
Судя по вам вы предпочтете первое, и я показал на примере к чему это приводит.
воот, а говорите правил и ограничений нет. Ведь на ревью вы запретите человеку класть страницы в хуки.
Да более того у вас даже принцип закрытости скорее всего соблюдается и компоненты, которые лежат в папке одной страницы не импортируются в рамках другой.
Так зачем вы тратите в разы больше времени на пооддержание этой структуры, и решаете проблемы которых нет? вы сами сказали что поиск компонента и зависимостей делаются через ctr.
я всего лишь применяю вашу аргументацию против вас. просто теперь я занял ваше место, и теперь, так же как и вы, начинаю утверждать, что раз в системе есть какие-то правила и их кто-то не понял то она сложная и избыточная.
Так почему же мы не можем все сложить в общую папку (кроме страниц), а вдруг должны делать какое-то разбиение (использующее вашу логику). Давайте все сложим на верхнем уровне кроме страниц. Ведь вы сами сказали, что разбиение не важно, так как оно не решает никаких проблем. Так зачем оно вам нужно (ваше логичное и правильное разбиение), если вы все равно через ctr + клик навигируете? Зачем на его поддержку вы тратите в РАЗЫ больше времени, и героически превозмогаете проблемы которых нет? (интересно, а вы тут себя уже узнали, или нет?)
что-то вас совсем в манипуляции понесло.
почему же нет? место. только их будет меньше 30
погодите вас кудато не туда понесло. Еще раз вы сделали утвердждение:
я вас за язык не тянул. Так выходит оно неверное? так как нет у меня не будет ни в одной папке проекта 30 файлов. Так как у нас получилось из проекта где всего 200 компонентов, вдруг 200 общих компонентов?
вот это поворот. Зачем же вы это делаете? Ведь нет никаких проблем и вы можете спойно прокликать позависомстям? Зачем вы тратите в РАЗЫ больше времни и поддерживаете какую-то структуру. Это же неудобно.
очередной обман. давай страницу положим в хуки. почему нет-то? или кто это может запретить?
все верно, вы сказали: что бы мне чтото найти я захожу на страницу и кликаю по нужной зависимости. Согласно таким рассуждениям - классическое разбиение избыточно, так как в не пользуетесь навигацией по папке кроме как найти нужную страницу. Вам вполне хватит только наличие папки pages. А вы городите что-то непонятное тратя В РЫЗЫ больше времени. зачем вам столько отдельных папкок? плодите всякие /components /hooks и т. п. (искользую ваши методы против вас)
Ещё раз: у вас на картинке обман. Нарисуйте ее нормально и честно где у вас в каждой папке полный список файлов. Я вам даже ральный пример скинул для компонентов
нет не будет. Вы не понимаете как пользоваться инструментом и опять пишите глословные утверждения.
Давайте проверим насколько вы способны к диалогу? вот у нас есть конкретный пример по ссылке. Я его расскладываю по ддд, и вы пытаетесь показать, где у меня хоть на одном уровне наберется хотя бы 30 файлов.
Если у меня получается - вы признаете свою ошибку. Если вы не признаете - то мы понимаем что вы раз за разом используете обман и не умеете принимать противоречащие вам факты.