Comments 102
Со временем я конечно привык. Привык и к идее того, что Observable - это новый Promise. <...>
А http запросы? Ну почему, если я хочу принести данные и вызываю функцию getData, я должен делать subscribe?<...>
А потом чешешь затылок и думаешь: и как теперь принести вторую страницу? Ну или просто обновить данные? Снова вызывать getData? Так зачем? Оно же не запускает запрос, а возвращает Observable, и он то у нас уже есть в руках. Вроде уже не получается. Значит нужен subscribe? И тут ещё многие стараются делать unsubscribe запросу в onDestroy. Видимо не понимают, что observable "заканчивается" после запроса.
Я настоятельно рекомендую вам разобраться (почитать или пройти курс) с RxJS и Observable. Там объснят что некоторые observable не "заканчиваются", как кешировать данные стандарным shareReplay и на другие ваши вопросы.
Сейчас пишу проект с RxJS - совсем по другому приходится мыслить и компоновать код, и у этого способа есть свои плюсы. Некоторые вещи становятся очень простыми. Но иногда когнитивная сложность становится большой, впрочем, такое на любом фреймворке можно наговнокодить.
Моё личное мнение, наблюдая последнее время вакансии и код:
1) Angular сейчас очень редко используется на новых проектах. В основном - для поддержки legacy.
2) React - да, сейчас и несколько лет уже на пальме первенства.
3) Vue 3 - уже ничем не хуже React, но это религиозный вопрос, прошу не хейтить, это лично моё.
Ну как не настоящая.. я бы сказал далеко не самая оптимальная.
Кто чем пользуется то и видит, наблюдаю обратное в своем окружении)
эх, где мой 2 way data-binding из 2014
В $mol. Тут есть 3 вида биндинга:
Двусторонний: вложенный компонент работает напрямую со внешним состоянием.
Затягивающий: вложенный компонент читает внешнее состояние, но не может его менять.
Вытягивающий: внешний компонент работает с состоянием вложеннго.
А их комбинация позволяет связывать не только внешний и вложенный компоненты, но и компоненты находящиеся рядом. Например, вытягиваем состояние вложенного инпута, и затягиваем его во вложенный параграф - он начинает напрямую показывать значение инпута. И это состояние не дублируется между 3 копонентами. Соответственно невозможны и гличи, связанные с рассинхроном состояний.
Типичная пропаганда react. Статья не раскрывает сильные и слабые стороны
При чем ни реакта, ни ангуляра. В последнем автор не разобрался, видимо в своей жизни не встречав действительно сложные юзер интерфейсы, где без NGRX был ад с биндингами, а в первом ему просто все нравится, потому что просто и свободно.
Проблема свободно в том, что каждый городит как хочет, и переход между проектами с такой свободой становится все сложнее и сложнее. Фреймворк наоборот обязан задавать стандарты и бест практисы, и чем сильнее он развит, тем большее количество кейсов должно быть ими покрыто.
Проблема свободно в том, что каждый городит как хочет, и переход между проектами с такой свободой становится все сложнее и сложнее.
А проблема несвободно в том, что все пишут какое-то унылое говно, тратя на это кратно больше времени, чем могли бы, взяв реально удобные технологии. И в итоге всё равно получают здоровое раздутое нечто, которое надо еще отдельно причесывать и утрясать за еще дополнительные расходы времени и денег. Зато переходить между проектами просто, агась.
Вся тимлидошная рукоплещет — народ можно между проектами кидать как угодно, никакого проектного онбординга, везде одно и то же квадратно-гнездовое. А что люди пишут неделями то, что даже в голом VanillaJS можно было б сделать за пару дней — так это наоборот прекрасно, чем дольше всё идёт, тем больше тимлидам зряплаты зряплатят!
Я больше 10 лет во фронте. Всё это время я работал на крупный энтерпрайс, никогда не занимался сайтиками или мелкими проектами. За это время разрабатывал на всех видах фремвёрках. От ext и gwt, до сейчас на ангуляре, реакте (да, у нас в конторе оба фреймвёрка равноправны и живут, просто в разных продуктах) и vue (1 пробный продукт). Так вот если смотреть на wbs, то разница по времени затраченному на разработку практически одинакова обоих фреймвёрков (да, пусть реакт это и библиотека, но с учётом накрученных на него расширений всё же уже ближе к фреймвёрку). Разница может в погрешности. Условно на реакте потратим 5000 человекодней, а на ангуляре 5100. Иногда в обратную сторону, иногда оценки и вовсе получаются одинаковые.
Никто ещё за много лет не смог взять на себя ответственности и сказать: мы это напишем на %фреймвёрк_нейм% за 2 раза меньшее время, чем на %текущий_фреймвёрк_нейм%. Если бы такое существовало в реальном мире, бизнес бы давно проголосовал рублём, но этого до сих пор не произошло. И да, в нашу контору приходили адепты vue, им дали картбланш и повелись на их убеждения что они напишут большую информационную систему за 2 месяца, а не за пол года как оценивали на ангуляре. По итогу они потратили те же 6 месяцев, с учётом всех накладок и проблем. Так что в сказки что какой-то фреймвёрк кратно лучше другого я уже не верю.
Никто ещё за много лет не смог взять на себя ответственности и сказать: мы это напишем на %фреймвёрк_нейм% за 2 раза меньшее время, чем на %текущий_фреймвёрк_нейм%.
Меня забавляет как все упорно делают вид, что меня не существует.
Ох, зря я решил перейти по ссылке... Какая адова дичь.
В комментариях к той статье уже спрашивали, но повторюсь.
Есть ли примеры крупных проектов, реализованных на $mol? Ссылки на компании, которые попробовали его использовать для разработки новых приложений? Сравнение скорости разработки чего-то сложнее Hello world? Отзывы новичков о сложности вкатывания в новую технологию?
Если $mol такая прорывная технология, то что-то не видно, чтобы за нее бизнес проголосовал рублем. А у разработчиков она определенно не в почете, судя по комментариям к каждой статье про этот фреймворк.
Есть ли примеры крупных проектов, реализованных на $mol?
В паблике нет.
Ссылки на компании, которые попробовали его использовать для разработки новых приложений?
Известных нет.
Сравнение скорости разработки чего-то сложнее Hello world?
Убедительных нет.
Отзывы новичков о сложности вкатывания в новую технологию?
Статистически значимых нет.
не видно, чтобы за нее бизнес проголосовал рублем
Бизнес, как и обычные потребители, рублём голосуют за то, что им продали. А что им продают вы и без меня знаете.
Ну а вы сами решайте, пробовать ли самому, или же следовать за толпой.
название проекта мысли о jquery навивает.
У него, кстати, был хороший слоган: "write less, do more", которому $mol более чем соответствует.
Может сконцентрироваться на том что хорошо получается.
Сидеть в депрессии? Хороший совет..
Чтобы более менее простые контролы одной кнопкой в мол переводить.
Не надо их "переводить" - в $mol они уже есть.
Создать вспомогательные прокси которые позволяют прозрачно использовать чужие фреймворки.
И получится ни рыба, ни мясо. Никому оно такое не нужно, особенно мне.
Типа основное приложение это реакт, мы делаем пару контролов на моле
Любой компонент или даже приложение на $mol легко регистрируется в качестве веб-компонента и используется так же как любой другой веб-компонент.
Если мол реально так хорош как вы декларируете, то очень быстро начнётся рост использования.
Я тоже раньше думал, что достаточно показать людям классные штуки, и они тут же их оценят. Но нет, это так не работает.
Это всё замечательно, но за 2 года чтения моих статей, желания глянуть в сторону мола у вас так и не возникло.
вы могли бы вместо впихивания $mol, адаптировать какие-либо из своих концепций к существующим фреймам, что-то улучшить, а потом дескать а вот в $mol все так же, только еще лучше.
В своё время я 3 месяца лечил детские болезни в Ангуляре. Никто этих стараний не оценил.
а статья есть?
Это всё закрытый код был. В паблике есть только впечатления: https://habr.com/ru/post/348818/comments/#comment_10664058
.
чтобы при переходе с
/tasts/наtasks/1/роутер не перерендеривал весь список задач, а просто открывал рядом панельку с детализацией? Базовое поведение безбожно сломано кривыми абстракциями.
Взял первую претензию из твоего комментария
Структура такая Lists Component -> Details Component
Details Component - это дочерний роут Lists Component
В Details Component делаем список, а ниже <router-outlet></router-outlet>
При смене роута список не перерисуется, а Details перерисуется.
Список не будет перерисововаться при наличии OnPush вообще никак.
Я больше 10 лет во фронте. Всё это время я работал на крупный энтерпрайс, никогда не занимался сайтиками или мелкими проектами.
Я тоже.
Никто ещё за много лет не смог взять на себя ответственности и сказать: мы это напишем на %фреймвёрк_нейм% за 2 раза меньшее время, чем на %текущий_фреймвёрк_нейм%.
Я брал и делал. Что дальше?
И это был даже не реакт-ангуляр-вью, а просто нормальный выбор технологий "по месту" для задачи. С решением всех вопросов по интеграции в остальную часть проекта, разумеется.
И да, в нашу контору приходили адепты vue, им дали картбланш и повелись на их убеждения что они напишут большую информационную систему за 2 месяца
Слова "большая информационная система" прямо таки вопят о том, что проблема в данном случае была не во фронтах. Я тоже видел немало проектов, где главной, основной, и практически единственной проблемой было отсутствие понимания, что же в итоге хочется получить. Либо отсутствие способностей разложить это понимание в приемлемую для исполнителей форму. А далее на фронтах всего лишь происходит классическое "нет ТЗ — результат хз".
И чем больше проект, тем вероятность того, что все полимеры на нем будут просраны на уровне организаторов (даже и не аналитиков) всё больше приближается к единице.
Фреймворк наоборот обязан задавать стандарты и бест практисы, и чем сильнее он развит, тем большее количество кейсов должно быть ими покрыто.
На таких фреймворках разработка со временем преваращается в войну с фреймворком. Из-за неучтенных авторами кейсов пользователям фреймворка приходится городить костыли для обхода ограничений. И у свободы и у ограничений свои плюсы и минусы. Свобода плоха, когда попадаешь в чужой проект и часто там сделано не очень. Ограничения плохи, когда авторами фреймворка сделано не очень.
Из моего опыта, на гибких технологиях без кучи ограничений писать гораздо проще и они много лет остаются популярными. К тому же лучше развивается навык проектирования т.к. можно придумать свое решение, а не ограничиваться придуманными авторами.
Имхо, фреймворк в первую очередь нужен для упрощения и более быстрого решения определенных задач, чтобы не делать с нуля кучу типовой работы. Архитектура, выработка и выбор каким практикам следовать - это уже на совести пользователей фреймворка. Мнение авторов фреймворка не всегда правильное. При использовании любого фрейморка со временем становится понятно, что те или иные вещи можно было сделать лучше.
Это все звучит конечно круто, но в реальности опыт у меня противоположный. Описанное может и существует, но в очень ограниченных условиях. Если ты единственный разработчик на проекте, или хотя бы единственный сеньор на проекте и доводишь его с нуля до состояния релиза. А потом только ты и сопровождаешь.
В реальности же как правило происходит так, что приходит один сеньор со своим виденьем как надо писать и проектировать, и пишет код по-своему. Ему действительно легко и просто писать код, и может быть даже его команде, если он свои подходы шарит. А потом приходит другой сеньор и следующий, и каждый со своими подходами и реализацией гибкости фреймворка. В лучшем случае своими подходами они пишут только новое, а старое не трогают. В худшем все переписывают.
Проект превращается в адское месиво из свободы и гибкости, с которым никто не хочет работать. Потом оказывается, что единообразность была гораздо важнее гибкости, а свобода нужна только сеньорам, чтобы придумывать новые способы проектирования, рассказывать про них на собесах и уходить на большие деньги. А бизнес остается с франкенштейном и не понимает, почему к нему никто не идет и считает его 3х летний код жутким легаси.
Писать код должно быть сложно, поддерживать же его должно быть легко. А не наоборот. Строгие фреймворки и индустриальные стандарты позволяют этого достичь. Борьбой с фреймворками же занимаются обычно люди которые не поняли или не приняли фреймворк-way of doing things и пытаются сделать что-то по своему.
Писать код должно быть сложно, поддерживать же его должно быть легко. А не наоборот.
Именно ради этого и нужна гибкость. Писать простой код квадратно-гнездовым методом попросту невозможно, квадратно-гнездовым методом можно писать исключительно квадратно-гнездовой код.
В редчайших случаях вы можете точно попасть в ту прикладную область и в проект такого размера, при которых выбранный фреймворк позволит вам писать простой код без больших отрицательных эффектов. Во всех остальных — вы получите всё того же франкенштейна, с которым рано или поздно никто не захочет работать.
Строгие фреймворки и индустриальные стандарты позволяют этого достичь.
Ахахахах.
Как-то раз меня со слезами в глазах уговаривали идти переводить проект с одного "строгого фреймворка" по имени AngularJS на другой "строгий фреймворк" по имени Angular2, строго по индустриальным стандартам™, сиречь официальным гайдам по миграции. Правда, денег особо дать не могли, вместо этого живописуя трагическую историю о том, что те, кто идут за предлагаемые деньги (люди без особого опыта) — тупо не справляются, а кто бы справился — не идёт, денег трагически мало.
Это всё видимо от легкости поддержки происходит, не иначе.
ЗЫ: Вообще, у меня уже много лет как есть такая "народная примета": те, кто много говорят о легкости поддержки и индустриальных стандартах — как раз живут на самых высоких нагромождениях кривоватого кода, просто им повезло никогда не попадать под воздействия, которые бы всё это обрушили. Или у них есть сложившийся кружок B2B, который просто вынужден жрать что дают, каким бы кривым оно не было, или у них настолько элементарнейшее B2C, что даже и кратный перерасход ресурсов на разработку и запуски этого на компах клиентов — не замечается, в конце концов никому нет дела до кривоты проекта, пока он работает и приносит деньги.
Писать код должно быть сложно, поддерживать же его должно быть легко. А не наоборот.
У вас тут ложная дилемма. И писать, и поддерживать не должно быть сложно. Почему в популярных фреймворках это не так - вопрос скорее социополитический, чем технический.
Например, $mol даёт выскоуровневые абстракции, позволяющие разрабатывать быстро и единообразно, но в то же время и не ограничивает в возможностях. Так что обычно голову можно даже не включать, двигаясь по колее, но там где надо - у тебя вся полнота возможностей прокладки новых дорог.
Тут я не спорю, что у каждого свое виденье и когда к одному проекту применяют разные подходы, ничего хорошего не выйдет. Обычно бизнесу нужны те, кто делает, руководствуясь придуманными за них подходами и практиками (то есть вполне подойдет middle с 2-3 годами опыта, хотя почти все почему-то хотят "лучших" сеньоров). А хорошие разработчики не будут долго делать по стандарту, иначе они бы не стали хорошими. Бывают конечно исключения.
"придумывать новые способы проектирования, рассказывать про них на собесах и уходить на большие деньги."
Эх, если бы( Мне не попадался интервьюер, который бы это ценил.
Писать код должно быть сложно, поддерживать же его должно быть легко.
Эм, какой-то у вас странный опыт был.
И то и другое должно быть легко) Иначе для решения простых задач придется тратиться и нанимать одних сеньоров. И текучка будет большой, т.к. долго терпеть сложности на ровном месте толковые разработчики не станут.
Борьбой с фреймворками же занимаются обычно люди которые не поняли или не приняли фреймворк-way of doing things и пытаются сделать что-то по своему.
Есть и такие. А также к этим же людям относятся авторами фреймворков, которые стали стандартом) Хороший разработчик со врененем должен начинать видеть недостатки используемого фреймворка и нормально, что он хочет где-то отойти от традиционного пути. Слова "все нравиться в фрейморке" от хорошего разрабатчика вряд ли услышишь.
Если в проекте много специфичных хотелок, то фреймворк оказывается просто не рассчтитан на них и приходится искать обходные пути. Авторы фрейморков обычные люди и не могут знать всего и выдать решение подходящее под все. К тому же им тоже приходится использовать технологии, которые являются legaсy с 30-ти летней историей)
Кстати, приведу, с чем я столкнулся, используя фрейморк для админок на реакте: https://github.com/marmelab/react-admin/issues/2260
Разработчикам, использующим фреймворк, понадобилось отобразить кнопки в компоненте-таблице не справа, а слева. Им в ответ - нет возможности задать стили этому элементу в нашем компоненте-таблице, напишите свой компонент-таблицу с которым еще должен уметь работать фреймворк. И подобных проблем там довольно много. У фрейморка почти 20к звезд в github.
где без NGRX был ад с биндингами
где внедрение NGRX превращает ад с биндингами в просто ад
О чем статья то? После прочтения создается впечатление, что это поток сознания на тему "как я стал фанбоем js", но даже эта тема не раскрыта
Вкратце статья о том, что автор за столько лет не смог разобраться с парой десятков операторов rxjs, и ушел писать хеллоуворлды на реакте.
Проблема "не смог разобраться с операторами" настолько популярна, что rxjs запилили интерактивную страницу "а какой же мне оператор заюзать?" https://rxjs.dev/operator-decision-tree. Много ли вы еще видели технологий, где приходилось делать такую страницу?
Да, есть такое дело, rxjs и Ангуляр сам попали в ловушку собственной универсальности. Предоставляемых возможностей слишком много и изучать их долго.
Если я соберусь заюзать все, что может предложить rxjs, например, в Реакте, мне придется поставить сверху еще три десятка мелких либ и изучать все это месяцами. И еще десяточек костылей либ, если я захочу получить функциональность Ангуляра. Но на практике это все не нужно сразу, поэтому этот процесс размывается по времени.
Rxjs следовало бы отобрать небольшой набор самых частых операторов, а остальные удалить или убрать в дополнительный пакет. На бандле разумеется это никак не скажется, но уменьшит доку. Например тот же mergeMap или exhaustMap или auditTime практически не применяется, но при нужде их можно себе быстро сколхозить себе или подобрать что-нибудь из npm.
Это конечно срежет часть возможностей, зато новички перестанут теряться.
mergeMap один из самых используемых операторов в RxJS:)
Если я соберусь заюзать все, что может предложить rxjs, например, в Реакте, мне придется поставить сверху еще три десятка мелких либ и изучать все это месяцами
Большая часть операторов rxjs нахуй не нужна в реакте. Просто потому что реакт не пытается изобрести свой собственный язык программирования, а расширяет существующий.
По сути rxjs почти всегда героически решает проблемы, которые он же создал. За исключением некоторых операторов типа debounce/throttle, которые, кхм, реализованы в lodash или там redux-saga.
То что я говорю — это правда, пока мы говорим о user-коде. Если мы говорим о том, чтобы точечно применить rxjs внутри какого-то черного ящика, то rxjs становится превосходным инструментом. Правда, область применения у rxjs в таком случае сужается до "за 5 лет можно не почувствовать, что такой технологии не хватает".
Эквивалентном идеи "давайте использовать rxjs на ui" является идея "давайте использовать sql для бизнес-логики".
кхм, lodash или там redux-saga нахуй не нужны на фронте, потому что lodash пытается изобрести свой собственный язык программирования, а redux-saga героически решает проблемы, которые redux создал.
Зачем тащить это барахло, когда все есть в rx и еще дофига всего разного, просто берешь его и используешь, без споров "а какую же еще шикарную конструкцию из стейтов и костылей мы сегодня соберем".
вы таки правда не используете lodash и считаете что rxjs его заменит?
Я таки правда не использую лодаш за ненадобностью, на прошлом проекте за 2 года из лодаша понадобился один только groupBy и это потому что rxjs-аналог довольно странный.
А насчет того, что заменит, это врядли.
Rx реактовцам не впихнешь, хотя он и в реакте ложится довольно удобно через самописные хуки.
Ребят, вы тут спорите какая какашка лучше, в то время как есть куда более продуманные решения.
redux-saga героически решает проблемы, которые redux создал.
ну и тут тоже ошибка, как-бы. redux-saga не решает проблемы, созданные redux. redux-saga решает проблемы, которые не решил redux.
эквивалент redux-saga - это ngrx/effects, только ngrx/effects - дерьмо поверх ngrx+rxjs.
Зачем тащить это барахло, когда все есть в rx и еще дофига всего разного
а вы микроскопом гвозди не забиваете, случаем, с таким уровнем аргументации?
ngrx/effects - дерьмо поверх ngrx+rxjs.
тут соглашусь. ngrx вообще появился когда реактовцы зачем-то притащили свой flux в ангуляр.
а вы микроскопом гвозди не забиваете
Еще раз. Я использую один универсальный инструмент для широкого круга задач, связанных с распространением изменений данных и контроля процессов. А по вашему я для каждого гвоздика и шурупчика должен выкопать и применить свой узкоспециализированный? И при этом убедить коллег применять точно такой же. А зачем?
тут соглашусь. ngrx вообще появился когда реактовцы притащили свое барахло в ангуляр.
ngrx появился, потому что rxjs явно недостаточно для стейт-менеджмента.
Еще раз. Я использую один универсальный инструмент для широкого круга задач, связанных с распространением изменений данных и контроля процессов. А по вашему я для каждого гвоздика и шурупчика должен выкопать и применить свой узкоспециализированный? И при этом убедить коллег применять точно такой же. А зачем?
Беда универсальных инструментов в том, что на них все задачи решаются через жопу.
ну и тут тоже ошибка, как-бы. redux-saga не решает проблемы, созданные redux. redux-saga решает проблемы, которые не решил redux.
Я вас, пожалуй, тоже поправлю: redux-saga не решает проблемы, созданные redux, не решает проблемы, которые не решил redux, а решает проблемы, созданные им самим.
Мне кажется, что львиная доля нелюбви к реакту идет от redux, почему-то заезжающему вместе. React - one love. Redux - хрень, не решающая никаких проблем, если только кому не платят за бесполезные строчки кода.
redux решает проблемы, просто раньше он решал проблемы довольно большой ценой. Сейчас есть redux-toolkit, который уменьшил количество страданий до приемлемого.
Интересно, что с redux-toolkit он стал больше похож на другие менеджеры состояний, которые появились за несколько лет до redux-toolkit и еще тогда решали аналогичные проблемы без такого количества страданий.
С точки зрения архитектуры redux несколько более правильная штука. В частности, из-за предсказуемости.
с точки зрения архитектуры это godlike object антипаттерн. С прикрученным потоком событий.
а, расскажите, по вашей логике DI-контейнеры тоже godlike объект?
У вас рассогласование числа в одном предложении :)
А так, ну смотря какой di. В Ангуляре он иерархический, и соседние экземпляры могут использовать инжектор одинаковым образом, но получать свои собственные экземпляры. Что в редаксе провернуть уже проблематично, придется лепить составные ключи и пробрасывать их внутрь структуры.
Да и задача, решаемая di, совершенно другая.
А так, ну смотря какой di. В Ангуляре он иерархический, и соседние экземпляры могут использовать инжектор одинаковым образом, но получать свои собственные экземпляры. Что в редаксе провернуть уже проблематично, придется лепить составные ключи и пробрасывать их внутрь структуры.
Ну т.е. если в ангуляре инжектор был бы не иерархический, он был бы godlike?
А если бы в redux существовал прозрачный механизм иерархичности, он перестал бы быть godlike?
Да и задача, решаемая di, совершенно другая.
Это оправдывает di?
Ну т.е. если в ангуляре инжектор был бы не иерархический, он был бы godlike?
да, он такой в angular.js и это очень неудобно.
А если бы в redux существовал прозрачный механизм иерархичности
лучше изоляции, но да. Но вообще это будет обычный useReducer.
Это оправдывает di?
Свою задачу он решает.
лучше изоляции, но да. Но вообще это будет обычный useReducer.
Если вам прям строгая изоляция нужна, то не существует технических ограничений чтобы держать несколько сторов (я проверял). Есть только рекомендация так делать в последнюю очередь. However, creating new stores shouldn't be your first instinct, especially if you come from a Flux background. Try reducer composition first, and only use multiple stores if it doesn't solve your problem.
А вот с иерархичностью как раз будут проблемы, её нетривиально реализовать.
И нет, это не будет обычный useReducer. Во-первых, потому что обычный useReducer никак не отображается толком в devtools. Во-вторых, потому что useSelector/useDispatch работать не будут, а это одна из самых полезных вещей.
Свою задачу он решает.
А redux типа свою задачу не решает? Просто в моих руках он отлично подходил, чтобы решать мои проблемы.
В реакте mobx удобнее и гибче.
В ангуляре я раньше жил с akita, он использует редаксовские девтулзы, но удобней в использовании чем тот же ngrx, но со временем вообще избавился от него в пользу голого rxjs, а девтулзы перестал использовать еще раньше. В нетривиальных случаях от них мало толку, отследить огромный поток событий сложно, а в тривильных проще отследить инпуты компонента.
А redux типа свою задачу не решает?
Отлично решает задачу хранения глобального состояния. Впрочем столь же отлично, как и вообще что угодно из стейтов.
Глобальная переменная с возможностью связи чего угодно с чем угодно это правильная, с точки зрения архитектуры, штука? Да ладно?
Если вы под "глобальная переменная" имеете в виду то, что в большинстве приложений всего один redux-стор, то вы всегда можете сделать несколько сторов при необходимости. См. https://redux.js.org/usage/isolating-redux-sub-apps
Как-бы, каждый дрочит как хочет, redux предоставляет вам свободу. Обычно так не делают, но не по причине "так нельзя".
А какое стейт-менеджмент решение вы считаете более хорошим с архитектурной точки зрения, чем использование redux?
Но при создании нескольких сторов вы получаете все те же проблемы, для решения которых Redux и создавался: расинхронизация сторов и неатомарность изменений.
то вы всегда можете сделать несколько сторов при необходимости
Redux тем и отличается от Flux, что Store всего один. Это была попытка уйти от проблемы согласования разных store-ов и всяких гонок данных между ними. Мол пока стор один всё очень просто.
Обычно так не делают, но не по причине "так нельзя".
Что такое "архитектура приложения"? Это по сути, если упростить, перечень правил и требований к организации кодовой базы и потока данных. Вот redux навязывает весьма гхм… спорную архитектуру. У неё есть свои сильные стороны, которые нужны чем менее чем никогда, чуть более чем никому.
Задумайтесь. Что особенного в Redux? Это то, что это pub/sub система, где любой reducer может отреагировать на любой action. Даже если это какая-то внутрянка какого-нибудь совсем другого модуля с другого конца приложения. А зачем так делать? "Ну удобно же". Люди, с поражением мозга redux-ом уже и мыслить по-другому не могут. Для них возможность связать что угодно с чем угодно это "свобода", а не грубый костыль, который хоронит кодовую базу ещё на стадии написания MVP. Они выстраивают всю бизнес логику и все её связи вокруг глобальной переменной, внедряя в неё же и локальную внутрянку. Да блин это чёртов ад, а не архитектура.
Пока люди изобретают внешние интерфейсы, модульный API, и вообще ломают голову, как бы убрать все паразитные связи, в redux царит полная анархия.
А стоит вам усилием воли, линтерами, code review и паяльником устроить жёсткие правила по изоляции различных частей стора друг от друга вы заметите, что от redux-а не осталось ничего полезного (кроме возможности сериализовать весь store). И все эти нелепые страдания (даже с immer и прочими уловками) нужны ради… ради ничего.
Применяется ли что-то подобное на практике где-нибудь ещё? Да. Например системы вроде babel и webpack. Там развесистые системы хуков. Всё можно связать со всем практически каким-угодно способом. Зачем там весь этот ад? Потому что нужна супер-гибкость для произвольных плагинов. Архитектура заложена такая, чтобы не пришлось переписывать весь core ради очередного плагина. В какой-то степени это расплата за требования в сверх-гибкости.
А теперь вопрос на засыпку — а это вообще нужно в SPA? В 99% нафиг не нужно.
А какое стейт-менеджмент решение вы считаете более хорошим с архитектурной точки зрения, чем использование redux?
Любой НЕ глобальный. Да хоть useReducer и useState, если его не пытаются использовать как global store.
Redux тем и отличается от Flux, что Store всего один. Это была попытка уйти от проблемы согласования разных store-ов и всяких гонок данных между ними. Мол пока стор один всё очень просто.
Простите, но вот этот вот спор по поводу разделения flux/redux — это какой-то локальный мемчик, подробности которого никому не интересны.
Т.е. вы конечно молодец и вся х..ня, но поставьте себя на место человека, который выбирает стейт-менеджмент решение сейчас (а не когда был актуален срач по поводу flux/redux). У него есть выбор из: них..я (очень частый выбор), симулировать стейт-менеджмент на rxjs, mobx, redux, какое-то специализированное flux-way/redux-way решение от автора фреймворка, и полсотни никем не используемых говноизобретений в библиотеке npm.
И так уж на поверку оказывается, что я вот взял себе в приложении и з..башил два redux-стора, когда появилась нужда сделать модульность. И почему-то мне не понадобилось заменять redux на какую-то реализацию flux. Почему-то реальность не конфликтует с моим убеждением, зато конфликтует с вашим.
И все эти нелепые страдания (даже с immer и прочими уловками) нужны ради… ради ничего.
нужны ради... dev tools как минимум!
Любой НЕ глобальный. Да хоть useReducer и useState, если его не пытаются использовать как global store.
Как мило, конечно. То, что приложение на useReducer/useState разрабатывать/дебажить/сопровождать стало в кучу раз сложнее — это конечно, не х..вая архитектура. Зато redux — это х..вая архитектура, потому что "в древности была битва между redux и flux; и с тех пор мы обязали redux быть глобальным-глобальным и даже микрофронтенды redux обязательно должен прорывать". Прекрасно.
Честно говоря я так и не понял, что вы хотели сказать этим комментарием. Единственный довод, который я увидел, это redux dev tools. Смею вас заверить, вы очень сильно переоцениваете его важность. Так же как и упускаете важный факт — при более разумной архитектуре вам в принципе нужно куда реже что-нибудь дебажить.
Я очень долго использовал redux на постоянной основе. Неоднократно дебажил кишки redux-react, писал 1001 велосипед по усмирению redux- бойлерплейта, и что я только с этим несчастным redux не делал.
Как только до меня дошло, что от него больше проблем, чем пользы, жить стало намного легче. Код стал проще, кода стало меньше, всё стало работать более предсказуемо и примитивно. Пишу на хуках уже 3-й год. И могу сказать что:
То, что приложение на useReducer/useState разрабатывать/дебажить/сопровождать стало в кучу раз сложнее
- разрабатывать и сопровождать код стало намного легче
- дебажить стало сложнее, но сам дебаг нужен куда реже
Мой вам совет — не сотворите себе кумира. Мне кажется вы просто купились на красивую обёртку "unidirectional dataflow", и просто не замечаете, что за слона в посудной лавке вам подсунул Даниил. Как и то что можно придерживаться этого принципа и с локальными сторами.
Зато redux — это хуевая архитектура, потому что "в древности была битва между redux и flux; и с тех пор мы обязали redux быть глобальным-глобальным и даже микрофронтенды redux обязательно должен прорывать". Прекрасно.
Redux плохая архитектура потому что это:
- глобальная переменная
- со связями вида any to any
- проблемой O(n) на подписках
- огромным количеством бойлерплейта (не важно как много костылей вроде immer и redux-toolkit вы воткнёте)
- до 18 React-а оно ещё и работает на костылях вроде
try-catchдля отлова dead zoombies и stale props, потому что всё делает в обход react.
С этой технологией просто ужасно неудобно работать. На кодовых базах любых масштабов. И что самое интересное, в этом просто нет никакой необходимости.
Вам нравятся чистые функции reducer-ы? Отлично. Вам не нужен глобальный store. Вам нравится однонаправленный поток данных? Отлично. Вам не нужен глобальный стор. Вам нравится, что нет props hell? Отлично, для этого вам не нужен глобальный стор. И т.д..
Честно говоря, я не хочу вас переубеждать. Вы зачем-то прицепились к какой-то мифической войне flux-а и redux-а, что даже не замечаете красной нити того, о чём вам пишут. Никакой войны не было.
P.S. Даниил (автор redux-а) сам говорит, что будет гореть в аду, за его создание. Не могу с ним не согласиться.
Так же как и упускаете важный факт — при более разумной архитектуре вам в принципе нужно куда реже что-нибудь дебажить.
Не бывает таких волшебных архитектур, чтобы не приходилось дебажить. Но эта фраза все объясняет. Скорее всего, сложность вашего бизнес-кода довольно тривиальна, раз вам не нужно дебажить.
проблемой O(n) на подписках
это единственная существенная проблема и то нужно постараться, чтобы в неё упереться.
Прекрасно. Давайте на этой замечательной ноте и закончим наш разговор.
это единственная существенная проблема и то нужно постараться, чтобы в неё упереться.
Например, написать не совсем тривиальный бизнес-код?
Проблема O(n) на подписках аукнется не в случае нетривиального бизнес-кода, а в случае попытки отобразить слишком много данных. Грубо говоря, при любом изменении стора у вас дергается проверка "а надо ли инициализировать попытку перерендера реакт-компонента?". Данная проблема никак не лечится, но к нетривиальности бизнес-кода не имеет никакого отношения.
Нетривиальный бизнес-код — это когда у вас сайд-эффекты есть. Там тоже можно O(n) случайно добиться, но если так произойдет, то это можно починить.
Применяется ли что-то подобное на практике где-нибудь ещё? Да. Например системы вроде babel и webpack. Там развесистые системы хуков. Всё можно связать со всем практически каким-угодно способом. Зачем там весь этот ад? Потому что нужна супер-гибкость для произвольных плагинов. Архитектура заложена такая, чтобы не пришлось переписывать весь core ради очередного плагина. В какой-то степени это расплата за требования в сверх-гибкости.
И вот этот вот отрывок очень прекрасен. Прям хочется спросить. Вы таки правда предлагаете писать код так, чтобы при необходимости добавить что-то пришлось переписывать все нахуй?
И называете это хорошей архитектурой? А что же мы получаем взамен? Некую строгую фиксированную изоляцию, которая не нужна, потому что соблюдается сама по себе?
В основе Redux лежит идея из ФП-мира - централизованный стейт, меняющийся синхронно и атомарно - это благо. Но в ФП (см. Хаскель, ELM) - понятно как делать декомпозицию состояния. Тип данных, конструктор, и операции над типом данных - кладешь в модуль, и все понятно как инкапсулировать и переиспользовать.
В redux это потерялось по-дороге. Хотя вполне можно было бы это, хотя-бы, продумать и объяснить. Можно попробовать сделать это поверх redux - но он, скорее, будет мешаться.
А без инкапсуляции, централизованный стейт - больше создает проблем, чем решает.
Вот, например, можно элементарно написать хук типа const [isLoading, data] = useApiCall('/api/getItems') - один раз, и потом в 90% случаев писать только эту строчку. Как вот такое сделать переиспользуемое на redux?
И можно мне как-нибудь гарантировать, что страничка А не сломает страничку Б, если страничка А откроется перед Б?
Асинхронщина и прочие эффекты - туда же. Типа "потом библиотекой сделаем". Ага, да. Либо опять пишем асинхронный императивный код вообще сбоку (redux-saga), либо закат солнца вручную (redux-thunk).
В результате имеем библиотеку-карго-культ - нормально идею из ФП нам недонесли. Огрызок этой идеи - скорее зло. Зато придумали какой-то безумный API на кучу букв - который еще и приходится оборачивать другими либами чтобы использовать!
Вот, например, можно элементарно написать хук типа const [isLoading, data] = useApiCall('/api/getItems') - один раз, и потом в 90% случаев писать только эту строчку. Как вот такое сделать переиспользуемое на redux?
А в чем именно проблема? Довольно наивным образом пишется та версия хука, которая делит статус API-запроса между всеми компонентами. Если почему-то это не подходит и мы желаем строгой изоляции, то всегда можно побить стейт апи-запросов по отдельным инстансам компонентов (а идентифицировать их через useState(newGuid())). Из тонких моментов нужно предусмотреть только очистку данных, когда они не нужны.
Однако. Если вы считаете, что из компонента нормально дергнуть апиху напрямую, то у меня для вас плохие новости. Вам не нужен redux. Накладные расходы на него будут выше, чем польза.
Да там и без редакса хватает поводов материться. Когда одни и те же вещи решаются по разному, разными либами, да еще где-нибудь в глубине проброшенных 20 раз рендер пропсов, всплывающих в самых неожиданных местах. Реакт позволяет легко миксовать код и разметку, и этим злоупотребляют.
А вот редакс не проблема, он однотипный.
Как и автор, я не понимаю навязывания везде где только можно RxJS. Нет, с исторической точки зрения, оно понятно. Когда только начиналась разработка Angular 2, то async/await был в черновиках спецификации. И брать в работу что-то, что только в черновике спеки и еще не понятко как будет выглядеть в релизе, было бы очень стремным решением. Да и RxJs был (да и сейчас, благодяря Ангуляру) популярен.
Но сегодня не вчера, можно ведь и по другому.
У себя в проекте, мы сделали так. Разделили логику и компоненты. Все сервисы работают только с async/await. Вся обработка данных, проебразования итд только в service layer. Так же все вызовы к API проходят через инстанс класса API, который всего лишь обертка с методами GET/POST/PUT/DELETE над fetch функцией.
А компоненты ангуляра стали просто крайне простыми компонентами, которые просто берут данные из сервиса и рендерят. Не более.
Из профита.
Service layer может быть написан не ангуляр девелоперами. Если нехватает рук, то ребята с бекенда могут без проблем имплементировать задачу.
Упростилось тестирование, так как тестируем сервис отдельно, а компонент отдельно. И тестирование компонента стало очень простым, так как там просто отображение данных.
Повысился перформанс приложения, так как мы убрали с ангуляра часть работы по проверке, сравнению итд.
Я к тому, что и на ангуляре можно нормально делать приложения. Главное включить думалку, а не слепо следовать разным модным трендам и делать только так, как книжка пишет.
Всем добра! :)
Когда только начиналась разработка Angular 2, то async/await был в черновиках спецификации. И брать в работу что-то, что только в черновике спеки и еще не понятко как будет выглядеть в релизе, было бы очень стремным решением
Зато с декораторами такой проблемы у них почему-то не сложилось.
Главное включить думалку, а не слепо следовать разным модным трендам и делать только так, как книжка пишет
fixed: Главное включить думалку, а не следовать документации angular.
Я к тому, что и на ангуляре можно нормально делать приложения.
Тут главное вовремя понять, что без ангуляра могло бы быть всё гораздо лучше. Вот скажем на хабре уже довольно давно пишут ребята из Тинькофф, делающие Taiga UI. Пишут они замечательные вещи. Но каждый раз читая их, я не могу отделаться от мысли, что то, что они пишут — где-то наполовину или даже больше борьба с ангуляром (в которой они мужественно победили ангуляр).
Можно подумать статьи о Реакте не про борьбу с созданными самим Реактом проблемами. Добрая половина из них про борьбу с ререндерами, вызванными протекующей абстракцией.
Я с вами полностью согласен. В моем случае у меня не было выбора. Решение использовать ангуляр было принято "сверху", и все что мне оставалось, по максимуму заставить его работать быстро.
А о том, к чему мы пришли в команде, я написал выше. :)
У них куча статей помимо тайги, где они делают разные классные штуки именно при помощи Ангуляра, вы говорите что без него было бы лучше :)) Там никто его не побеждал, они просто действительно используют возможности фреймворка.
У них куча статей помимо тайги
Я про них и пишу.
где они делают разные классные штуки именно при помощи Ангуляра
Угу. Типа, "посмотрите, как мы классно победили ангулярский DI, чтоб им наконец-то было достаточно удобно пользоваться". Действительно, и почему же это я говорю, что без него было бы лучше?
Они не побеждают DI. Они им пользуются.
"Победить" в моем понимании это влезть в приватное апи, чето там намутить, что изначально не предусматривалось. Я такое действительно иногда делаю в редких случаях, чтобы сократить бойлерплейт.
А в статьях у них обычное использование инструмента по назначению. Просто возможности достаточно богатые, чтобы и так тоже делать, это штатные вещи всё, изначально заложенные.
А еще можно использовать async/await, навертеть поверх него каких-нить костылей и считать что "победили" Ангуляр %)
"Победить" в моем понимании это влезть в приватное апи, чето там намутить, что изначально не предусматривалось.
Это "переписать", а уж никак не "победить". "Победить" — это дописать.
"Победить" — это взять кривоватый и неудобный инструмент, и таки найти путь применить его, спрятав весь неочевидный код в библиотечные классы и методы (как раз собственно то, о чем они пишут), и выставив наружу уже более интересное и удобное для применения API.
вопрос скорее про фрагментацию библиотек в реакте: в реакте есть свой роутер или нужно ставить одну из каких-то там библиотек? в реакте есть свой пакет для работы с формами или тоже что-то левое нужно ставить? тут, в принципе, можно еще и NgRx добавить и RxJS к сравнению. я это к чему - переходя с проекта на другой проект в ангуляре ты увидишь одну и ту же библиотеку и ты знаешь как она работает - ничего нового. а в реакте так же?
сюда же
1. анимации. Первый же запрос в гугл выдает кучу статей на тему "лучшие 10 способов сделать анимации в Rect"
Изоляции стилей. Тоже самое.
DI. В реакте реализуется через Context и это выглядит просто адски.
Расширение компонентов. Вместо директив берите HOC внутри HOC внутри HOC внутри... Можно еще кучу вложенных хуков добавить по вкусу.
Для Http - axios, для интернационализации еще что-то, даже для лейзи лоадинга тоже часто всплывает какая-то либа.
В общем чтобы собрать себе удобную среду, нужно во-первых долго искать подходящие либы, потом это все связывать, а потом доказывать что вот именно это лучше, чем то.
в реакте есть свой роутер или нужно ставить одну из каких-то там библиотек?
Нету. по дефолту все тащат react-router
в реакте есть свой пакет для работы с формами или тоже что-то левое нужно ставить?
Нету. можно втащить formik, например.
переходя с проекта на другой проект в ангуляре ты увидишь одну и ту же библиотеку и ты знаешь как она работает - ничего нового. а в реакте так же?
Нет, не так же. Будешь видеть разные библиотеки, в зависимости от того, что именно лучше подходит. В этом и фишка.
В этом и фишка.
ну, по мне так это наоборот спорный момент. тут как раз выбор между свободой с фрагментацией+разной степенью мощности библиотек (реакт) и стандартными+мощными библиотеками (ангуляр)
fixed: выбор между свободой с кривыми библиотеками и стандартизацией с кривыми библиотеками.
Вся вот эта вот принудительная стандартизация — она вам нравится пока вы не упираетесь в то, что какая-то из частей экосистемы не выполняет ваши цели. И в случае ангуляра у вас меньше шансов заменить неподходящую библиотеку на другую.
Т.е. о чем говорить, если вы не можете использовать актуальную версию тайпскрипта без того, чтобы ангуляр обновился до неё?
В общем, это срач android (react) vs iOS (angular)
вот как только вы подходите к моменту когда что-то стандартного не хватает - вы и думаете как быть. а когда хватает стандартного - нет головной боли. ну и про "стандартные кривые библиотеки" - в ангуляре они как раз таки отличные. бывает что у них есть до боли тупые проблемы о которых знают, но которые пока не собираются решать, но это скорее исключение
я бы не назвал это срачем - я бы назвал это сравнением что имеет одна библиотека против другой чтобы можно было сравнивать предметно и по пунктам, а не орать в 3 горла что одно хуже другого потому что "ТАМ ВСЁ ПЛОХО"
На самом деле просто возьми какой-нибудь живой проект на реакте и насладись :) А лучше два, от другой тимы.
Почему же всё-таки React, а не Angular