Эммм, ну вообще то MobX конкретно спасает от проблем реакта. Если вам всё ещё не очевидно как, с учётом того что я скидывал конкретные примеры кода, то у меня для вас плохие новости.
Вы просто посмотрите на код, который вы в комментарии своем привели. И ещё раз подумайте)
как и, возможно, не нужен какой-либо другой стейт менеджер.
Нужен, ибо реакт ни в каком виде не способен обеспечить адекватное управление состоянием, из-за того же, что я указал ниже, единственный вариант это MobX.
Не до конца понял прямую связь redux и ререндеров
Без костылей как у вас, она прямая, ибо иммутабильность и отсутствие умного и незаметного для разработчика React.memo
И какой тогда вам смысл думать лишних рендерах и т.п? Когда берешь redux, то сознательно пишешь максимально плохой код, и с этим ничего нельзя поделать, так изначально задумано.
А теперь пытаетесь бороться с проблемами, которые сами себе специально и сознательно создали. Спрашивается зачем их было создавать?
Добавление новых элементов к делу(лишние перерендеры компонентов, которые не должны перерендериваться) не относится.
а на второй прислал какую-то демку с состоянием в глобальной переменной и без пропсов.. вы кого пытаетесь обмануть?
1) Пропсы к делу не относятся, т.к. при изменении пропса компонент и так должен перерендериваться, в этом весь смысл. 2) Там есть глобальный стейт и локальный. Тем более для React + MobX, нет разницы MobX стор подключен как глобальное состояние или локальное конкретного компонента. 3) Вот пробросил метод через прос в дочерние компоненты, чтобы они его вызывали и меняли состояние у компонента родителя: https://stackblitz.com/edit/stackblitz-starters-k5jbjqqv?file=src%2FApp.tsx
Разумеется ничего не поменялось и никаких лишних рендеров не добавилось.
Он вообще даже близко не стоит с MobX'ом по удобству использования, и в zustand много boilerplate кода надо писать, поменьше чем в redux конечно, но все равно много по сравнению с MobX, где его нет вообще. А ещё zustand иммутабильный и это тоже минус.
Солидарен, мне тоже первый вариант кода ближе, плюс он нативный, в этом большой плюс. Интересно было что же киллер фича такая типизированных ошибок, а это оказалось тем же самым по сути, только в профиль)
А в чем принципиальная разница тогда с instanceof о котором вы негативно отзывались? Вот полностью типизированная обработка ошибок у промиса:
try {
const response = await apiRequest(...);
} catch (e) {
if (e instanceof TimeoutException) console.log("timed out")
if (e instanceof ResponseError) console.log(`response error. status = ${e.response.status}`)
if (e instanceof RequestError) console.log(`request error. url = ${e.request.url}`)
}
Выглядит по сути точно так же как у вас.
Effect.catchTags({ // это отработает когда эффект с ошибкой завершился, даже retry не помог
TimeoutException: () => Effect.succeed("timed out"),
ResponseError: (error) => Effect.succeed(`response error. status = ${error.response.status}`),
RequestError: (error) => Effect.succeed(`request error. url = ${error.request.url}`)
})
но из из такого стрима можно выйти с типизированной ошибкой в любой момент
А покажите как конкретно вы обработаете ошибки вот в таком коде, который вы показывали, сейчас он вообще без отлова и обработки ошибок. Прям полноценный код чтобы был. Т.е. прям обработка если httpClient отвалился и если таймаут вышел. С учетом вызова этой функции и получении из нее данных.
а не приятно, как раз из-за того, что архитектура там была неудобная и с ней было тяжело и неприятно работать.
Нет)
круто и микрофронты как и микросервисы зачастую все делят на домены. Но домены это зло и их не существует)
Микрофронт, как и микросервис вещь совершенно конкретная.
Самое интересное, что распределение как микрофронтах можно получить и без них
Только без бонусов, которые дают микрофронты в виде отсутствия(или сведенного к минимуму) вот этого:
не получив в довесок кучу проблем
Эти "проблемы" с лихвой окупаются их преимуществами. Я выбираю перевес в преимуществах)
странно, то вы жаловались что толстый шаред - это плохо. А как увидели что он на классике в три раза хуже - так сразу по барабану)
Я не жаловался, это вы жалуетесь что большой проект(много компонентов) это плохо, и одновременно говорите что любите такие проекты) А в классике не хуже, а лучше) Но учитывая то, что меня в целом не парит, что кол-во компонентов в папке больше, чем в ваших идеалах, по этому мне это количество в целом по барабану) Как только оно начнет раздражать, вжух, микрофронты и как все как рукой сняло)
Она хорошая так как хорошая. Гениальная аргументация
Учусь у проповедника и на 4 ставки фанатика fsd)
Кейс хоть один будет? что она дарит в отношении с распределением хаоситов?
Вот вам кейс и то как она выглядит. Дальше мысленный эксперимент и всё встает на свои места.
звучит недостоверно учитывая как вы выше писали о том как неприятно работать на таких проектах.
Вот поэтому больше и не работаю, т.к. не приятно. Уже поработал, хватит)
конечно. И все это все еще лежит у вас в shared, и является "публичным апи" для вашего проекта.
А у меня это там не лежит, а распределено по доменам.
То есть у меня /components в разы уже ваших.
Вообще по барабану, никаких проблем н вижу, а если вдруг вижу, то микрофронты и все проблемы махом испаряются.
то что вы положили это в папку - это конечно хорошо (по сути все сводится к тому, что вы пытаетесь, сами того не осознавая выделетить домены), но в итоге у вас там все еще свалка, так как не все разбито в группы.
микрофронты и все проблемы махом испаряются.
Поэтому в очередной раз повторяю вопрос: что привносит классика в виде улучшения на проект в соотношении с ее отсутствием?
Её структура, простота и никаких вредных ограничений.
Более того откуда вам знать если для вас большие проекты не приятны, не удобны и работать вы с ними не хотите?
Я работал на таких, и там была классика и никаких проблем касаемо архитектуры не было и в помине.
вы опять не читаете и опять делаете утверждения не понимая на что вам указали. У меня есть общие компоненты для проекта - они действительно лежат в компонентах. И по сути это только ui-kit. У вас же любой компонент который используется больше чем в одном месте - там оказывается.
OMG что за бред опять. Вы называете компонентами всё на свете. Страницы, лейауты, реальные компоненты. Но я не удивлюсь если вы и функции с хуками компонентами называете. Группировка, слышали о таком? Уже тысячный раз
У меня же эти компоненты лежат в домене. Так что нет вы абсоютно не правы.
Бла бла бла. Что за "домен", что за компоненты, с какого перепуга в классике все на свете должно быть в src/components на верхнем уровне... У вас уже FSD головного мозга зашкаливает. Вы теряете связь с реальностью.
Ну и повторим:
Вы же рациональный человек. или уже нет? Вы сказали что не хотите тратить ресурсы поддержание структуры. И я вам предложил другое распределение, в котором явно будет меньше затрат на ее поддержаие (причем, я даже привел конктретные кейсы, когда у вас даже пул реквесты становится тяжелее из-за необходимости поддержки структуры). Так почему же как фанатик уцепились за менее экономически обоснованный инструмент? Или в нем есть какие либо обоснования?
Вы продолжаете юлить.
Это просто белая горячка. Я использую классику, точка. Именно ее структура и архитектура это идеальное сочетание. Всё остальное это перегиб. Поэтому ни какими хаос архитектурами из ваших фантазий я не пользуюсь и уж тем более fsd.
нет, она не удобна на действительно больших проектов
Нет, увы и ах. Удобна, более чем. И намного намного более приятна в использовании.
на которых вы не хотите работать и судя по всему вы не умеете с ними работать.
Не хочу утопать в говнокоде, бюрократии, пул реквестах длящихся вечность, постоянный конфликтах в коде и т.д. и т.п.
Я показал на простейшем примере как у вас папка components растет в разы быстрее моего shared, и это только один из примеров.
Нет, не растет быстрее. Кол-во компонентов в src/components равно кол-ву общих компонентов. В вашем shared их будет ровно такое же количество. Это в вашей выдуманной хаос архитектуре растет, где все лежит в src =)
Погодите, мы сравниваем сейчас не fsd против классики, а классику против хаоса с выделенными pages
Мне не интересен хаос и сравнения с ним) Я использую классику. Тут речь про сравнению классики с Freaky Sliced Design.
Это мы еще не разобрались зачем мы вообще классику используем
Затем что она покрывает абсолютно все сценарии и размеры проектов. И не накладывает чрезмерных ограничений и т.п. Все остальные вариации на фронте против классики хуже. Вот почему мы ее так любим и используем.
Можно кейсы где видно облегчение жизни от ее использования?
Плюс отсутствие чрезмерных ограничений и запретов. Плюс она интуитивно понятна всем и всегда. Плюс сделайте ctrl+f по этой странице по слову "интуитивно", увидите все места где я называл плюсы классики.
а что маловато? куда вы юлите? вы сказали, что вам главное найти страницу, а дальше вы прокликаете куда нужно
Когда я понятия не имею что за компонент мне нужен и где он лежит да, нашел страницу - нашел все остальное.
Но вы зачем-то тратите ресурсы на поддержание вашей структуры.
Я не трачу) Она не накладывает расходов, базовые в расчет неберем типо напечатать название файла/папки)
Так зачем же? какую проблему решила ваша группировка?)
У меня никогда не было проблем с организацией кода и навигацией, со времени 2012 года и php) Я сразу на интуитивном уровне создавал папки так, чтобы с ними было удобно работать)
конечно - вашим распределением. Так какие же это были проблемы? пока их не видно, и следовательно зачем вам, ваше распределение?
Проблем не было) Просто до этого другие вариации организации кода были, и в эти моменты тоже не было проблем, потому что в 2016 моей первый проект на реакте уже был фактически интуитивно построен на классической архитектуре) А до этого я на PHP писал, там своя организация кода была)
отлично, как вы экономите ресурсы?
Используя классику)
Ведь, по вашим словам вам главное найти папку со страницами, а все остальное не важно.
Когда я понятия не имею что за компонент мне нужен и где он лежит да, а ещё SCSS + CSS modules отлично помогают, React Dev Tools тоже) В остальных случая я просто знаю где лежит интересующий меня код и сразу открываю его)
ну как же? вот вы говорите вы сложили их в страницы. Браво. У нас 3 страницы используют один и тот же компонент. Вы его куда кладете? в общие компоненты, или каждая страница лезет в код страницы другой?
В src/components/.. , если он может быть сгруппирован по какому-то признаку, то в src/components/group_by/...
В первом случае у вас разбухает /components/
И что теперь?) Пускай.
То есть у вас в любом случае число компонентов лежащих на верхнем уровне выше чем у меня
Потому что я не прячу их туда, где сложно найти, они лежат там, где должны лежать общие компоненты. На то они и общие.
И при росте проекта соотношение становится только хуже.
Ну это лично у вас) У меня нет) У меня как и большинства не проблем с навигацией) Это примерно 0.1% времени)
Так зачем оно нужно? Вы сами сказали что ограничений нет.
Если вам говорят что у нас в офисе дресс кода нет(т.е. вам не говорят что надо именно в рубашке с галстуком ходить) вы же не идёте туда в одних труханас и сланцах, потому что на улице +30. Вы же понимаете(надеюсь) что о настолько базовых ограничениях в явном виде просто специально не говорят и не берут их в расчет?
опять обман, положить файл в корень всегда быстрее чем его класть в любой другой путь.
Для меня нет разницы) 1 секундой больше, одной секундой меньше) Мышку опустить чуть ниже или чуть выше)
Более того вам еще нужно подумать куда его положить:/components/chat/ или в /pages/chatHistory/components
Зачем? Если компонент используется больше чем на в одном месте, то он без раздумий идет в src/components , если я его создаю специально для этой страницы, то он без раздумий ложится в src/pages/my_page/components . Так что думать не нужно) Ну как, то что занимает подсознательно 1 секунду, я в расчет не беру) А скажете что нельзя не думать и при этом название папке давать например)
так, что лукавите вы про отсуствие накладных расходов. Они есть.
Да нет, нету.
Более того вы сказали, что иногда объединяете компоненты внутри компонентов. Это тоже время:
Ну да, время, только ничтожно малое в сравнении с накладными расходами fsd. Поэтому оно в расчет не берется.
вот сколько дел, что бы поддерживать вашу группировку. Ненужно лукавить
И даже эти дела в классике (0.1% времени это если прям преувеличить, а так 0.001% скорее), занимают ничтожно малую часть по сравнению с накладными расходами fsd.
Одни только споры с fsd фанатиками на код ревью по поводу widgets, features, entities, fetuares, shared, ui/ui/ui/ui/ui чего стоят и сколько времени и нервов съедают.
ну так вы же тратите время разпределяя файлы. Значит вы решаете какую-то проблему этим. Вы же реалист и не делали бы это просто так? Куда вы юлите - зачем вы делаете вашу архитектуру "здорового" человека?
У меня все проблемы решены много много лет как)
(кстати распределение папокй - это не архитектура)
Знаю, просто для вас папки как мана небесная) Вы целую религию вокруг них построили)
Так вы ответите зачем вы тратите в разы больше времени на вашу "архитектуру", если она не дает профитов и мы легко находим код и без такого распределения папок
Мне классика дает профит, я ни разу не говорил что она не дает профит. И я с её помощью экономлю много времени и нервов, иначе я бы ей не пользовался) Если захочу самобичевания и депрессии, то возьму FSD.
Эммм, ну вообще то MobX конкретно спасает от проблем реакта. Если вам всё ещё не очевидно как, с учётом того что я скидывал конкретные примеры кода, то у меня для вас плохие новости.
Вы просто посмотрите на код, который вы в комментарии своем привели. И ещё раз подумайте)
Нужен, ибо реакт ни в каком виде не способен обеспечить адекватное управление состоянием, из-за того же, что я указал ниже, единственный вариант это MobX.
Без костылей как у вас, она прямая, ибо иммутабильность и отсутствие умного и незаметного для разработчика
React.memoИ какой тогда вам смысл думать лишних рендерах и т.п? Когда берешь redux, то сознательно пишешь максимально плохой код, и с этим ничего нельзя поделать, так изначально задумано.
А теперь пытаетесь бороться с проблемами, которые сами себе специально и сознательно создали. Спрашивается зачем их было создавать?
Добавление новых элементов к делу(лишние перерендеры компонентов, которые не должны перерендериваться) не относится.
1) Пропсы к делу не относятся, т.к. при изменении пропса компонент и так должен перерендериваться, в этом весь смысл.
2) Там есть глобальный стейт и локальный. Тем более для React + MobX, нет разницы MobX стор подключен как глобальное состояние или локальное конкретного компонента.
3) Вот пробросил метод через прос в дочерние компоненты, чтобы они его вызывали и меняли состояние у компонента родителя:
https://stackblitz.com/edit/stackblitz-starters-k5jbjqqv?file=src%2FApp.tsx
Разумеется ничего не поменялось и никаких лишних рендеров не добавилось.
Ну вот же, нет никаких лишних ререндеров. Только те компоненты, которые изменяются и изменения в родителе не тригерят рендер дочерних.
Откройте консоль и понажимайте:
https://stackblitz.com/edit/stackblitz-starters-eowyumpg?file=src%2FApp.tsx
Чего не скажешь о голом реакте
https://stackblitz.com/edit/stackblitz-starters-6gcj5993?file=src%2FApp.tsx
Ну и соответственно никакие zustand'ы от этого тоже не спасают, все лишнее перерендеривается только в путь
https://stackblitz.com/edit/stackblitz-starters-zzn16f51?file=src%2FApp.tsx
Он вообще даже близко не стоит с MobX'ом по удобству использования, и в zustand много boilerplate кода надо писать, поменьше чем в redux конечно, но все равно много по сравнению с MobX, где его нет вообще. А ещё zustand иммутабильный и это тоже минус.
Солидарен, мне тоже первый вариант кода ближе, плюс он нативный, в этом большой плюс. Интересно было что же киллер фича такая типизированных ошибок, а это оказалось тем же самым по сути, только в профиль)
А в чем принципиальная разница тогда с
instanceofо котором вы негативно отзывались? Вот полностью типизированная обработка ошибок у промиса:Выглядит по сути точно так же как у вас.
Да и делает все тоже самое
А покажите как конкретно вы обработаете ошибки вот в таком коде, который вы показывали, сейчас он вообще без отлова и обработки ошибок. Прям полноценный код чтобы был. Т.е. прям обработка если httpClient отвалился и если таймаут вышел. С учетом вызова этой функции и получении из нее данных.
Скрытый текст
Опять бла бла бла, уже несколько месяцев жду вашу обещанную статью про то, почему классы это плохо, но всё нет и нет её. Когда уже?
Нет)
Микрофронт, как и микросервис вещь совершенно конкретная.
Только без бонусов, которые дают микрофронты в виде отсутствия(или сведенного к минимуму) вот этого:
Эти "проблемы" с лихвой окупаются их преимуществами. Я выбираю перевес в преимуществах)
Я не жаловался, это вы жалуетесь что большой проект(много компонентов) это плохо, и одновременно говорите что любите такие проекты) А в классике не хуже, а лучше) Но учитывая то, что меня в целом не парит, что кол-во компонентов в папке больше, чем в ваших идеалах, по этому мне это количество в целом по барабану) Как только оно начнет раздражать, вжух, микрофронты и как все как рукой сняло)
Учусь у проповедника и на 4 ставки фанатика fsd)
Вот вам кейс и то как она выглядит. Дальше мысленный эксперимент и всё встает на свои места.
Вот поэтому больше и не работаю, т.к. не приятно. Уже поработал, хватит)
Вообще по барабану, никаких проблем н вижу, а если вдруг вижу, то микрофронты и все проблемы махом испаряются.
микрофронты и все проблемы махом испаряются.
Её структура, простота и никаких вредных ограничений.
Я работал на таких, и там была классика и никаких проблем касаемо архитектуры не было и в помине.
OMG что за бред опять. Вы называете компонентами всё на свете. Страницы, лейауты, реальные компоненты. Но я не удивлюсь если вы и функции с хуками компонентами называете. Группировка, слышали о таком? Уже тысячный раз
src/components/formComponentns/...src/components/cartSpecific/...src/components/whatEvenrYouWant/...
Бла бла бла. Что за "домен", что за компоненты, с какого перепуга в классике все на свете должно быть в
src/componentsна верхнем уровне... У вас уже FSD головного мозга зашкаливает. Вы теряете связь с реальностью.Это просто белая горячка. Я использую классику, точка. Именно ее структура и архитектура это идеальное сочетание. Всё остальное это перегиб. Поэтому ни какими хаос архитектурами из ваших фантазий я не пользуюсь и уж тем более fsd.
Нет, увы и ах. Удобна, более чем. И намного намного более приятна в использовании.
Не хочу утопать в говнокоде, бюрократии, пул реквестах длящихся вечность, постоянный конфликтах в коде и т.д. и т.п.
Нет, не растет быстрее. Кол-во компонентов в
src/componentsравно кол-ву общих компонентов. В вашем shared их будет ровно такое же количество. Это в вашей выдуманной хаос архитектуре растет, где все лежит в src =)Мне не интересен хаос и сравнения с ним) Я использую классику. Тут речь про сравнению классики с Freaky Sliced Design.
Затем что она покрывает абсолютно все сценарии и размеры проектов. И не накладывает чрезмерных ограничений и т.п. Все остальные вариации на фронте против классики хуже. Вот почему мы ее так любим и используем.
Плюс отсутствие чрезмерных ограничений и запретов.
Плюс она интуитивно понятна всем и всегда.
Плюс сделайте ctrl+f по этой странице по слову "интуитивно", увидите все места где я называл плюсы классики.
Этого более чем достаточно.
https://habr.com/ru/companies/doubletapp/articles/870236/comments/#comment_27831846
Тоже отвечал там же)
https://habr.com/ru/companies/doubletapp/articles/870236/comments/#comment_27831846
Сделайте ctrl+f по этой странице по слову "интуитивно", увидите все места где я называл плюсы классики.
Когда я понятия не имею что за компонент мне нужен и где он лежит да, нашел страницу - нашел все остальное.
Я не трачу) Она не накладывает расходов, базовые в расчет неберем типо напечатать название файла/папки)
У меня никогда не было проблем с организацией кода и навигацией, со времени 2012 года и php) Я сразу на интуитивном уровне создавал папки так, чтобы с ними было удобно работать)
Проблем не было) Просто до этого другие вариации организации кода были, и в эти моменты тоже не было проблем, потому что в 2016 моей первый проект на реакте уже был фактически интуитивно построен на классической архитектуре) А до этого я на PHP писал, там своя организация кода была)
Используя классику)
Когда я понятия не имею что за компонент мне нужен и где он лежит да, а ещё SCSS + CSS modules отлично помогают, React Dev Tools тоже) В остальных случая я просто знаю где лежит интересующий меня код и сразу открываю его)
В
src/components/.., если он может быть сгруппирован по какому-то признаку, то вsrc/components/group_by/...И что теперь?) Пускай.
Потому что я не прячу их туда, где сложно найти, они лежат там, где должны лежать общие компоненты. На то они и общие.
Ну это лично у вас) У меня нет) У меня как и большинства не проблем с навигацией) Это примерно 0.1% времени)
Если вам говорят что у нас в офисе дресс кода нет(т.е. вам не говорят что надо именно в рубашке с галстуком ходить) вы же не идёте туда в одних труханас и сланцах, потому что на улице +30. Вы же понимаете(надеюсь) что о настолько базовых ограничениях в явном виде просто специально не говорят и не берут их в расчет?
Для меня нет разницы) 1 секундой больше, одной секундой меньше) Мышку опустить чуть ниже или чуть выше)
Зачем? Если компонент используется больше чем на в одном месте, то он без раздумий идет в
src/components, если я его создаю специально для этой страницы, то он без раздумий ложится вsrc/pages/my_page/components. Так что думать не нужно) Ну как, то что занимает подсознательно 1 секунду, я в расчет не беру) А скажете что нельзя не думать и при этом название папке давать например)Да нет, нету.
Ну да, время, только ничтожно малое в сравнении с накладными расходами fsd. Поэтому оно в расчет не берется.
И даже эти дела в классике (0.1% времени это если прям преувеличить, а так 0.001% скорее), занимают ничтожно малую часть по сравнению с накладными расходами fsd.
Одни только споры с fsd фанатиками на код ревью по поводу
widgets,features,entities,fetuares,shared,ui/ui/ui/ui/uiчего стоят и сколько времени и нервов съедают.У меня все проблемы решены много много лет как)
Знаю, просто для вас папки как мана небесная) Вы целую религию вокруг них построили)
Мне классика дает профит, я ни разу не говорил что она не дает профит. И я с её помощью экономлю много времени и нервов, иначе я бы ей не пользовался) Если захочу самобичевания и депрессии, то возьму FSD.