Привет, читатели Хабра. Решил написать пост о том как мой выбор вэб фреймворкабиблиотеки пал именно на React. Это лично моё субъективное мнение и найдутся многие, кто с этим не согласен.
Программировать я начал в 2006 году. Нет, конечно ещё году в 1999, помню, игрался с Delphi, ну там аналоговые часы, блокнот, наподобие тому, что в Винде, видеоплейер с плейлистом (тогда кстати во встроенном в систему плейлиста не было). В 2006 году в израильской армии начал строить веб-систему, которая автоматически распределяла солдат в зависимости от большого числа различных показателей. И естественно на тот момент это был ASP.NET с C#. Тогда ещё он не назывался Web Forms.
Вэб технологии менялись, каждый раз производя революцию в моём мозгу: ASP.NET MVC, JQUERY, AngularJS. И вот последний совершил наиболее серьёзное влияние, ибо только тогда я узнал, что возможно построить вэб аппликацию без серверных вьюшек (aspx, cshtml). А плюс к этому я узнал про Node JS ("Что? JavaScript на сервере? Не верю!"). И тогда я принял решение, в которое бы не поверил раньше: оставить C#, которому был "предан" в течение 9 лет, и полностью погрузиться в JavaScript.
Мне очень нравилось писать на новом вэб фреймворке от Google. Очень быстро получались вещи, для которых раньше мне нужно было сильно постараться с jQuery. SPA это был уже стандарт, ниже которого, казалось, стыдно опускаться вэб разработчику.
Писать на angularjs было одно удовольствие. Не было cli, но создать и сконфигурировать новый рабочий проект с 0 можно было минут за 20. На чистом es5, без babel, traceur, wepback (последнего ещё и не существовало вроде бы). Тогда уже и появлялись слухи о скором появлении angular 2 и его абсолютной несовместимости с первой версией. Google поставили разработчиков в сложное положение: с одной стороны руки чесались попереписывать системы с ASP.NET на новый классный фреймворк. С другой стороны вопрос: это вот мы сейчас перепишем, а потом снова переписывать?
Лично я, когда увидел примеры кода на angular 2, очень надеялся, что такое не взлетит. Я недоумевал зачем они всё на столько усложнили. И с каждым meetup'ом, посвящённом новой версии, на котором мне пришлось побывать, желание переходить на вторую версию было всё меньше и меньше.
И вот с release candidate было решено начать создавать новый проект (а по сути переписывать старый немного по-другому) уже используя angular 2. Я даже не говорю о том, что с обновлением этих release candidate приходилось переписывать большие участки кода. На angular 2 было на столько не комфортно писать, что я чувствовал боль, когда переписывал код. Поднял вопрос по поводу того, стоит ли это делать или же может продолжить писать на angular 1. Но несмотря на то, что до сих пор было много проблем и непонятных багов (помню, что описание ошибки в консоле было очень детальное... Вот только абсолютно не о том, где на самом деле была ошибка), куча непонятной функциональности (помню много времени взяло, пока мы поняли, что за forChild в описании модуля), все понимали, что оставаться на первой версии нельзя, нужно было идти вперёд. То есть переход на новый фреймворк был уже не потому что мы так хотели, а потому что Google нас вынуждали, выбора не было. Тогда ещё у меня пронеслась в голове мысль, что лучше бы уже на самом деле перейти на React. Но мысль эту я отогнал, ибо чувствовал, что следовать нужно за Google ).
Со временем я конечно привык. Привык и к идее того, что Observable - это новый Promise. Код пытался писать так, чтобы везде они были, как можно больше async в шаблоне. А большое количество операторов в цепочке (это ещё до pipe) заставляло думать, что код выглядит очень круто.
Со временем я смотрел на этот код и в голове представлял, как бы это всё выглядело с Promise и понимал, что так код был бы на много понятнее и читаем. Но я себя уверял в том, что Promise - старьё и следовал за тенденциями.
А тенденции были такие, что вдруг оказалось, что код нужно писать с помощью ngrx и вообще все компоненты делать OnPush. Я несколько раз смотрел на пример todo списка через ngrx с недоумением: "ЗАЧЕМ??". Ведь всё же было так просто и удобно. Я понимал, что ничего не осталось от того самого angularjs, на котором я начал писать не потому, что так надо, а потому что я в него просто влюбился.
Повсеместное использование rxjs где надо и где не надо. Со временем я уже не наблюдал в коде ни объектов данных, ни функциональной логики. В глазах просто мельтешил набор операторов типа: mergeMap, switchMap, mergeAll, switchAll, combineLatest, combineLatestAll... ну, Вы меня понимаете. Мне кажется, что все остальные, кто писал этот код, сами не понимали, что там происходит, но продолжали возводить эти "сочинения" на пьедестал эталона идеального кода.
А http запросы? Ну почему, если я хочу принести данные и вызываю функцию getData, я должен делать subscribe? Подписываться на что? Это же не websockets. Обратился к серверу - принёс данные. И я даже не говорю о том сколько раз бывало, что вызываешь функцию, а данные не приходят. И думаешь, гадаешь в чём же дело? А дело именно в отсутствии subscribe. getData теперь Observable возвращает. Ну и вообще по-новому теперь пишешь так
this.data$ = getData()А потом в самом шаблоне
{{data$ | async}}И вот это да, всё работает! А потом чешешь затылок и думаешь: и как теперь принести вторую страницу? Ну или просто обновить данные? Снова вызывать getData? Так зачем? Оно же не запускает запрос, а возвращает Observable, и он то у нас уже есть в руках. Вроде уже не получается. Значит нужен subscribe? И тут ещё многие стараются делать unsubscribe запросу в onDestroy. Видимо не понимают, что observable "заканчивается" после запроса. Но как меня уверял приверженец http запросов на observables, что когда пользователь, например зашёл на страницу и запрос застрял, то он может нажать назад (о как) и запрос... прекращается! Ну да, это конечно оправданный сценарий использования observable вместо promise (которые кстати тоже можно abort'ить на минуточку)
Я почувствовал будто Google меня обманули. Хитро и пошагово подменили мне то, что когда-то понравилось, на что-то другое, что они посчитали правильным. Но я продолжал писать на angular, потому что верил в этот путь, отгоняя "грешные мысли".
И тут мой team leader, перейдя в новую фирму, через несколько месяцев предложил присоединиться к нему. Аргументов было 3 (не считая незначительное повышение зарплаты, которое мне и так предлагали, на нынешнем месте, чтобы я остался): ближе к дому (примерно минус час в день на дорогу), наконец-то получить nodejs на бэке (у нас были попытки ввести его, но не нашли уважительной причины для этого) и... Попробовать React. Я подумал, посовещался с людьми, которые пробовали и то и другое и все однозначно предпочитали react, сравнил популярность фреймворков (npmtrends, популярные сайты на react/angular). И решился на ответственный шаг в своей жизни: кинулся с головой в мир нового.
И тогда я понял чего мне так не хватало в новом angular: простоты. Всё элегантно и легко. Код был похож на JavaScript больше, чем в случае с angular. Чувствовалось больше свободы, возможности выбора различных библиотек, стилизации компонентов, выбора стэйт менеджмента, в конце концов.
Да, по началу было не привычно писать html внутри JavaScript, пока я не понял, что это уже не html, а JSX. Неудобно было и то, что теперь, когда я к примеру строил компоненту дерева, я не мог как раньше свернуть/развернуть узел:
node.expanded = !node.expandedНо в чём-то это и правильнее, когда речь идёт не о быстром примере, а о готовой функциональности.
Сейчас я пишу проекты на реакт. Благодаря функциональным компонентам и хукам код выглядит очень минималистично и максимально читаемо, на сколько это возможно. В то же время приходиться иногда возвращаться к старым проектам, написанным на ангуляре. И код написан максимально не читаемо (но это уже зависит от криворукости тех, кто этот код писал до моего прихода в фирму. Просто на мой взгляд современные практики ангуляра, дали возможность, "криворукому" написать всё таким образом). Попытки разбираться в этом коде и добавлять туда функциональности доставляют мне боль
Подводя итог, почему не ангуляр по моему мнению:
Google поначалу сделали что-то одно, чем привлекли внимание и сердца веб-программистов. А потом дали совершенно другое, пользуясь названием и репутацией полюбившейся платформы
Повсеместное использование rxjs там где он вообще не подходит
С каждой версией рассказывают об улучшении производительности. Но видимо это достигается тем, что по умолчанию теперь OnPush (эх, где мой 2 way data-binding из 2014)
Ощущение, что загружается в браузер огромная махина
В качестве UI библиотеки толкают Material с элементами на пол-экрана (Мне нравится material design на android, но не в вэбе же). За то, понимаешь ли, всё, что нужно для разарботки, на одном сайте и ходить больше никуда не надо, всё-всё там, на angular.io.
После того как Google убили AngularJS (и не только его) гарантировать вечную жизнь Angular они вряд ли могут.
Нет свободы выбора. Google как бы говорят: мы сами знаем, что Вам надо и как Вам лучше. Хотя многие (поклонники ангуляра) отсутствие этой свободы представляют, как отсутствие "Дикого Запада". Будто бы держать программиста в рамках выровняет ему руки
Ну и конечно в данном случае на меня повлиял невероятный скачок популярности реакта. Хотя этот фактор скорее дополнительный. Иначе бы я пользовался redux
А вообще у меня немало коллег, которые обожают angular, ngrx, считают этот путь единственным и не повторимым и самым лучшим и с моим мнением не согласны. Поэтому выбирайте то, что Вам нравится, что удобно. Главное не забывать, что скорее всего Ваш код будет читать ещё кто-то и возможно Вы не хотите, чтобы Вам в этот момент икалось ;-)
Комментарии (99)
AndyPike
05.02.2022 20:05+3Моё личное мнение, наблюдая последнее время вакансии и код:
1) Angular сейчас очень редко используется на новых проектах. В основном - для поддержки legacy.
2) React - да, сейчас и несколько лет уже на пальме первенства.
3) Vue 3 - уже ничем не хуже React, но это религиозный вопрос, прошу не хейтить, это лично моё.
nin-jin
05.02.2022 20:39-8эх, где мой 2 way data-binding из 2014
В $mol. Тут есть 3 вида биндинга:
Двусторонний: вложенный компонент работает напрямую со внешним состоянием.
Затягивающий: вложенный компонент читает внешнее состояние, но не может его менять.
Вытягивающий: внешний компонент работает с состоянием вложеннго.
А их комбинация позволяет связывать не только внешний и вложенный компоненты, но и компоненты находящиеся рядом. Например, вытягиваем состояние вложенного инпута, и затягиваем его во вложенный параграф - он начинает напрямую показывать значение инпута. И это состояние не дублируется между 3 копонентами. Соответственно невозможны и гличи, связанные с рассинхроном состояний.
atomic1989
05.02.2022 21:20+8Типичная пропаганда react. Статья не раскрывает сильные и слабые стороны
princessmilana
05.02.2022 21:52+12При чем ни реакта, ни ангуляра. В последнем автор не разобрался, видимо в своей жизни не встречав действительно сложные юзер интерфейсы, где без NGRX был ад с биндингами, а в первом ему просто все нравится, потому что просто и свободно.
Проблема свободно в том, что каждый городит как хочет, и переход между проектами с такой свободой становится все сложнее и сложнее. Фреймворк наоборот обязан задавать стандарты и бест практисы, и чем сильнее он развит, тем большее количество кейсов должно быть ими покрыто.JustDont
06.02.2022 02:06+4Проблема свободно в том, что каждый городит как хочет, и переход между проектами с такой свободой становится все сложнее и сложнее.
А проблема несвободно в том, что все пишут какое-то унылое говно, тратя на это кратно больше времени, чем могли бы, взяв реально удобные технологии. И в итоге всё равно получают здоровое раздутое нечто, которое надо еще отдельно причесывать и утрясать за еще дополнительные расходы времени и денег. Зато переходить между проектами просто, агась.
Вся тимлидошная рукоплещет — народ можно между проектами кидать как угодно, никакого проектного онбординга, везде одно и то же квадратно-гнездовое. А что люди пишут неделями то, что даже в голом VanillaJS можно было б сделать за пару дней — так это наоборот прекрасно, чем дольше всё идёт, тем больше тимлидам зряплаты зряплатят!
Raspy
06.02.2022 12:05+2Я больше 10 лет во фронте. Всё это время я работал на крупный энтерпрайс, никогда не занимался сайтиками или мелкими проектами. За это время разрабатывал на всех видах фремвёрках. От ext и gwt, до сейчас на ангуляре, реакте (да, у нас в конторе оба фреймвёрка равноправны и живут, просто в разных продуктах) и vue (1 пробный продукт). Так вот если смотреть на wbs, то разница по времени затраченному на разработку практически одинакова обоих фреймвёрков (да, пусть реакт это и библиотека, но с учётом накрученных на него расширений всё же уже ближе к фреймвёрку). Разница может в погрешности. Условно на реакте потратим 5000 человекодней, а на ангуляре 5100. Иногда в обратную сторону, иногда оценки и вовсе получаются одинаковые.
Никто ещё за много лет не смог взять на себя ответственности и сказать: мы это напишем на %фреймвёрк_нейм% за 2 раза меньшее время, чем на %текущий_фреймвёрк_нейм%. Если бы такое существовало в реальном мире, бизнес бы давно проголосовал рублём, но этого до сих пор не произошло. И да, в нашу контору приходили адепты vue, им дали картбланш и повелись на их убеждения что они напишут большую информационную систему за 2 месяца, а не за пол года как оценивали на ангуляре. По итогу они потратили те же 6 месяцев, с учётом всех накладок и проблем. Так что в сказки что какой-то фреймвёрк кратно лучше другого я уже не верю.
nin-jin
06.02.2022 12:44-7Никто ещё за много лет не смог взять на себя ответственности и сказать: мы это напишем на %фреймвёрк_нейм% за 2 раза меньшее время, чем на %текущий_фреймвёрк_нейм%.
Меня забавляет как все упорно делают вид, что меня не существует.
dolfinus
06.02.2022 19:07+1В комментариях к той статье уже спрашивали, но повторюсь.
Есть ли примеры крупных проектов, реализованных на $mol? Ссылки на компании, которые попробовали его использовать для разработки новых приложений? Сравнение скорости разработки чего-то сложнее Hello world? Отзывы новичков о сложности вкатывания в новую технологию?
Если $mol такая прорывная технология, то что-то не видно, чтобы за нее бизнес проголосовал рублем. А у разработчиков она определенно не в почете, судя по комментариям к каждой статье про этот фреймворк.
nin-jin
06.02.2022 19:40-2Есть ли примеры крупных проектов, реализованных на $mol?
В паблике нет.
Ссылки на компании, которые попробовали его использовать для разработки новых приложений?
Известных нет.
Сравнение скорости разработки чего-то сложнее Hello world?
Убедительных нет.
Отзывы новичков о сложности вкатывания в новую технологию?
Статистически значимых нет.
не видно, чтобы за нее бизнес проголосовал рублем
Бизнес, как и обычные потребители, рублём голосуют за то, что им продали. А что им продают вы и без меня знаете.
Ну а вы сами решайте, пробовать ли самому, или же следовать за толпой.
Korobei
06.02.2022 23:10Читаю ваши статьи и комментарии пару лет, по моему мнению вам надо ребрендинг сделать, а то название проекта мысли о jquery навивает.
Плюс маркетинг страдает. Переосмыслить бы подходы. Статьи хорошие, комментарии не очень. Может сконцентрироваться на том что хорошо получается.
Сделать инструменты помогающие миграции. Чтобы более менее простые контролы одной кнопкой в мол переводить.
Создать вспомогательные прокси которые позволяют прозрачно использовать чужие фреймворки.
Типа основное приложение это реакт, мы делаем пару контролов на моле, добавив прокси органично интегрируемся в реакт. Также в ангуляр и вуй. Если мол реально так хорош как вы декларируете, то очень быстро начнётся рост использования.nin-jin
06.02.2022 23:28+2название проекта мысли о jquery навивает.
У него, кстати, был хороший слоган: "write less, do more", которому $mol более чем соответствует.
Может сконцентрироваться на том что хорошо получается.
Сидеть в депрессии? Хороший совет..
Чтобы более менее простые контролы одной кнопкой в мол переводить.
Не надо их "переводить" - в $mol они уже есть.
Создать вспомогательные прокси которые позволяют прозрачно использовать чужие фреймворки.
И получится ни рыба, ни мясо. Никому оно такое не нужно, особенно мне.
Типа основное приложение это реакт, мы делаем пару контролов на моле
Любой компонент или даже приложение на $mol легко регистрируется в качестве веб-компонента и используется так же как любой другой веб-компонент.
Если мол реально так хорош как вы декларируете, то очень быстро начнётся рост использования.
Я тоже раньше думал, что достаточно показать людям классные штуки, и они тут же их оценят. Но нет, это так не работает.
Korobei
07.02.2022 02:15+2Ну если цель вывести свой фреймворк хотя бы в топ-100, то надо делать то что продвигает его. Ну или он реально должен быть крут. Или кто-то за ним должен стоять.
Комменты на хабре выглядят пассивнодушновато. Вызывают не желание глянуть в сторону мола, а желание заблокировать писателя. Статьи же наоборот, оставляют впечатление позитивное.nin-jin
07.02.2022 02:33+1Это всё замечательно, но за 2 года чтения моих статей, желания глянуть в сторону мола у вас так и не возникло.
Korobei
07.02.2022 03:00+2Возникло, но посмотрев на глючный демосайт оно стало гипотетическим.
Я не говорю что ваш фреймворк плох, но изучив тот-же реакт я могу сделать +30% к вакансиям и зарплатам, ангуляр +10%, мол 0%.
nin-jin
07.02.2022 03:08+2Зато изучив $mol получаешь +200% к скорости прокачки, даже если не будешь его использовать.
Korobei
07.02.2022 08:35Кто нибудь кроме вас может под этим подписаться?
Вы заинтересованная сторона, так что не считается.
nin-jin
07.02.2022 08:50Заинтересованная в чём? От того, что вы расширите свой кругозор и в вашем арсенале появится ещё пара десятков подходов к решению задач, мне ни тепло, ни холодно.
Xuxicheta
08.02.2022 00:04+1вы могли бы вместо впихивания $mol, адаптировать какие-либо из своих концепций к существующим фреймам, что-то улучшить, а потом дескать а вот в $mol все так же, только еще лучше.
nin-jin
08.02.2022 00:17+1В своё время я 3 месяца лечил детские болезни в Ангуляре. Никто этих стараний не оценил.
nin-jin
08.02.2022 00:53Это всё закрытый код был. В паблике есть только впечатления: https://habr.com/ru/post/348818/comments/#comment_10664058
essome
08.02.2022 18:07чтобы при переходе с
/tasts/наtasks/1/роутер не перерендеривал весь список задач, а просто открывал рядом панельку с детализацией? Базовое поведение безбожно сломано кривыми абстракциями.Взял первую претензию из твоего комментария
Структура такая Lists Component -> Details Component
Details Component - это дочерний роут Lists Component
В Details Component делаем список, а ниже <router-outlet></router-outlet>
При смене роута список не перерисуется, а Details перерисуется.
Список не будет перерисововаться при наличии OnPush вообще никак.
JustDont
06.02.2022 14:15+2Я больше 10 лет во фронте. Всё это время я работал на крупный энтерпрайс, никогда не занимался сайтиками или мелкими проектами.
Я тоже.
Никто ещё за много лет не смог взять на себя ответственности и сказать: мы это напишем на %фреймвёрк_нейм% за 2 раза меньшее время, чем на %текущий_фреймвёрк_нейм%.
Я брал и делал. Что дальше?
И это был даже не реакт-ангуляр-вью, а просто нормальный выбор технологий "по месту" для задачи. С решением всех вопросов по интеграции в остальную часть проекта, разумеется.И да, в нашу контору приходили адепты vue, им дали картбланш и повелись на их убеждения что они напишут большую информационную систему за 2 месяца
Слова "большая информационная система" прямо таки вопят о том, что проблема в данном случае была не во фронтах. Я тоже видел немало проектов, где главной, основной, и практически единственной проблемой было отсутствие понимания, что же в итоге хочется получить. Либо отсутствие способностей разложить это понимание в приемлемую для исполнителей форму. А далее на фронтах всего лишь происходит классическое "нет ТЗ — результат хз".
И чем больше проект, тем вероятность того, что все полимеры на нем будут просраны на уровне организаторов (даже и не аналитиков) всё больше приближается к единице.
strannik_k
06.02.2022 10:53Фреймворк наоборот обязан задавать стандарты и бест практисы, и чем сильнее он развит, тем большее количество кейсов должно быть ими покрыто.
На таких фреймворках разработка со временем преваращается в войну с фреймворком. Из-за неучтенных авторами кейсов пользователям фреймворка приходится городить костыли для обхода ограничений. И у свободы и у ограничений свои плюсы и минусы. Свобода плоха, когда попадаешь в чужой проект и часто там сделано не очень. Ограничения плохи, когда авторами фреймворка сделано не очень.
Из моего опыта, на гибких технологиях без кучи ограничений писать гораздо проще и они много лет остаются популярными. К тому же лучше развивается навык проектирования т.к. можно придумать свое решение, а не ограничиваться придуманными авторами.
Имхо, фреймворк в первую очередь нужен для упрощения и более быстрого решения определенных задач, чтобы не делать с нуля кучу типовой работы. Архитектура, выработка и выбор каким практикам следовать - это уже на совести пользователей фреймворка. Мнение авторов фреймворка не всегда правильное. При использовании любого фрейморка со временем становится понятно, что те или иные вещи можно было сделать лучше.
princessmilana
06.02.2022 16:06+7Это все звучит конечно круто, но в реальности опыт у меня противоположный. Описанное может и существует, но в очень ограниченных условиях. Если ты единственный разработчик на проекте, или хотя бы единственный сеньор на проекте и доводишь его с нуля до состояния релиза. А потом только ты и сопровождаешь.
В реальности же как правило происходит так, что приходит один сеньор со своим виденьем как надо писать и проектировать, и пишет код по-своему. Ему действительно легко и просто писать код, и может быть даже его команде, если он свои подходы шарит. А потом приходит другой сеньор и следующий, и каждый со своими подходами и реализацией гибкости фреймворка. В лучшем случае своими подходами они пишут только новое, а старое не трогают. В худшем все переписывают.
Проект превращается в адское месиво из свободы и гибкости, с которым никто не хочет работать. Потом оказывается, что единообразность была гораздо важнее гибкости, а свобода нужна только сеньорам, чтобы придумывать новые способы проектирования, рассказывать про них на собесах и уходить на большие деньги. А бизнес остается с франкенштейном и не понимает, почему к нему никто не идет и считает его 3х летний код жутким легаси.
Писать код должно быть сложно, поддерживать же его должно быть легко. А не наоборот. Строгие фреймворки и индустриальные стандарты позволяют этого достичь. Борьбой с фреймворками же занимаются обычно люди которые не поняли или не приняли фреймворк-way of doing things и пытаются сделать что-то по своему.JustDont
06.02.2022 16:32+2Писать код должно быть сложно, поддерживать же его должно быть легко. А не наоборот.
Именно ради этого и нужна гибкость. Писать простой код квадратно-гнездовым методом попросту невозможно, квадратно-гнездовым методом можно писать исключительно квадратно-гнездовой код.
В редчайших случаях вы можете точно попасть в ту прикладную область и в проект такого размера, при которых выбранный фреймворк позволит вам писать простой код без больших отрицательных эффектов. Во всех остальных — вы получите всё того же франкенштейна, с которым рано или поздно никто не захочет работать.Строгие фреймворки и индустриальные стандарты позволяют этого достичь.
Ахахахах.
Как-то раз меня со слезами в глазах уговаривали идти переводить проект с одного "строгого фреймворка" по имени AngularJS на другой "строгий фреймворк" по имени Angular2, строго по индустриальным стандартам™, сиречь официальным гайдам по миграции. Правда, денег особо дать не могли, вместо этого живописуя трагическую историю о том, что те, кто идут за предлагаемые деньги (люди без особого опыта) — тупо не справляются, а кто бы справился — не идёт, денег трагически мало.
Это всё видимо от легкости поддержки происходит, не иначе.ЗЫ: Вообще, у меня уже много лет как есть такая "народная примета": те, кто много говорят о легкости поддержки и индустриальных стандартах — как раз живут на самых высоких нагромождениях кривоватого кода, просто им повезло никогда не попадать под воздействия, которые бы всё это обрушили. Или у них есть сложившийся кружок B2B, который просто вынужден жрать что дают, каким бы кривым оно не было, или у них настолько элементарнейшее B2C, что даже и кратный перерасход ресурсов на разработку и запуски этого на компах клиентов — не замечается, в конце концов никому нет дела до кривоты проекта, пока он работает и приносит деньги.
nin-jin
06.02.2022 17:08-3Писать код должно быть сложно, поддерживать же его должно быть легко. А не наоборот.
У вас тут ложная дилемма. И писать, и поддерживать не должно быть сложно. Почему в популярных фреймворках это не так - вопрос скорее социополитический, чем технический.
Например, $mol даёт выскоуровневые абстракции, позволяющие разрабатывать быстро и единообразно, но в то же время и не ограничивает в возможностях. Так что обычно голову можно даже не включать, двигаясь по колее, но там где надо - у тебя вся полнота возможностей прокладки новых дорог.
strannik_k
06.02.2022 22:17Тут я не спорю, что у каждого свое виденье и когда к одному проекту применяют разные подходы, ничего хорошего не выйдет. Обычно бизнесу нужны те, кто делает, руководствуясь придуманными за них подходами и практиками (то есть вполне подойдет middle с 2-3 годами опыта, хотя почти все почему-то хотят "лучших" сеньоров). А хорошие разработчики не будут долго делать по стандарту, иначе они бы не стали хорошими. Бывают конечно исключения.
"придумывать новые способы проектирования, рассказывать про них на собесах и уходить на большие деньги."
Эх, если бы( Мне не попадался интервьюер, который бы это ценил.
Писать код должно быть сложно, поддерживать же его должно быть легко.
Эм, какой-то у вас странный опыт был.
И то и другое должно быть легко) Иначе для решения простых задач придется тратиться и нанимать одних сеньоров. И текучка будет большой, т.к. долго терпеть сложности на ровном месте толковые разработчики не станут.Борьбой с фреймворками же занимаются обычно люди которые не поняли или не приняли фреймворк-way of doing things и пытаются сделать что-то по своему.
Есть и такие. А также к этим же людям относятся авторами фреймворков, которые стали стандартом) Хороший разработчик со врененем должен начинать видеть недостатки используемого фреймворка и нормально, что он хочет где-то отойти от традиционного пути. Слова "все нравиться в фрейморке" от хорошего разрабатчика вряд ли услышишь.
Если в проекте много специфичных хотелок, то фреймворк оказывается просто не рассчтитан на них и приходится искать обходные пути. Авторы фрейморков обычные люди и не могут знать всего и выдать решение подходящее под все. К тому же им тоже приходится использовать технологии, которые являются legaсy с 30-ти летней историей)Кстати, приведу, с чем я столкнулся, используя фрейморк для админок на реакте: https://github.com/marmelab/react-admin/issues/2260
Разработчикам, использующим фреймворк, понадобилось отобразить кнопки в компоненте-таблице не справа, а слева. Им в ответ - нет возможности задать стили этому элементу в нашем компоненте-таблице, напишите свой компонент-таблицу с которым еще должен уметь работать фреймворк. И подобных проблем там довольно много. У фрейморка почти 20к звезд в github.
nsinreal
06.02.2022 18:45где без NGRX был ад с биндингамигде внедрение NGRX превращает ад с биндингами в просто ад
KislyFan
06.02.2022 00:04+10О чем статья то? После прочтения создается впечатление, что это поток сознания на тему "как я стал фанбоем js", но даже эта тема не раскрыта
Xuxicheta
06.02.2022 13:35+6Вкратце статья о том, что автор за столько лет не смог разобраться с парой десятков операторов rxjs, и ушел писать хеллоуворлды на реакте.
nsinreal
06.02.2022 18:41+3Проблема "не смог разобраться с операторами" настолько популярна, что rxjs запилили интерактивную страницу "а какой же мне оператор заюзать?" https://rxjs.dev/operator-decision-tree. Много ли вы еще видели технологий, где приходилось делать такую страницу?
Xuxicheta
06.02.2022 21:51Да, есть такое дело, rxjs и Ангуляр сам попали в ловушку собственной универсальности. Предоставляемых возможностей слишком много и изучать их долго.
Если я соберусь заюзать все, что может предложить rxjs, например, в Реакте, мне придется поставить сверху еще три десятка мелких либ и изучать все это месяцами. И еще десяточек
костылейлиб, если я захочу получить функциональность Ангуляра. Но на практике это все не нужно сразу, поэтому этот процесс размывается по времени.Rxjs следовало бы отобрать небольшой набор самых частых операторов, а остальные удалить или убрать в дополнительный пакет. На бандле разумеется это никак не скажется, но уменьшит доку. Например тот же mergeMap или exhaustMap или auditTime практически не применяется, но при нужде их можно себе быстро сколхозить себе или подобрать что-нибудь из npm.
Это конечно срежет часть возможностей, зато новички перестанут теряться.
pharrell
06.02.2022 22:36mergeMap один из самых используемых операторов в RxJS:)
Xuxicheta
06.02.2022 22:38да неужели?
Сейчас поискал по своему проекту, нашел только один, в методе, который 1) не используется, 2) написан каким-то левым челом, 3) стоит сразу после http, т.е. именно как mergeMap он не работает, ничего не мерджит.
А приведите пример, когда вы обоснованно его применяете?
nsinreal
06.02.2022 23:26Если я соберусь заюзать все, что может предложить rxjs, например, в Реакте, мне придется поставить сверху еще три десятка мелких либ и изучать все это месяцами
Большая часть операторов rxjs нахуй не нужна в реакте. Просто потому что реакт не пытается изобрести свой собственный язык программирования, а расширяет существующий.
По сути rxjs почти всегда героически решает проблемы, которые он же создал. За исключением некоторых операторов типа debounce/throttle, которые, кхм, реализованы в lodash или там redux-saga.
То что я говорю — это правда, пока мы говорим о user-коде. Если мы говорим о том, чтобы точечно применить rxjs внутри какого-то черного ящика, то rxjs становится превосходным инструментом. Правда, область применения у rxjs в таком случае сужается до "за 5 лет можно не почувствовать, что такой технологии не хватает".
Эквивалентном идеи "давайте использовать rxjs на ui" является идея "давайте использовать sql для бизнес-логики".
Xuxicheta
07.02.2022 00:22+1кхм, lodash или там redux-saga нахуй не нужны на фронте, потому что lodash пытается изобрести свой собственный язык программирования, а redux-saga героически решает проблемы, которые redux создал.
Зачем тащить это барахло, когда все есть в rx и еще дофига всего разного, просто берешь его и используешь, без споров "а какую же еще шикарную конструкцию из стейтов и костылей мы сегодня соберем".
nsinreal
07.02.2022 00:59вы таки правда не используете lodash и считаете что rxjs его заменит?
Xuxicheta
07.02.2022 01:11Я таки правда не использую лодаш за ненадобностью, на прошлом проекте за 2 года из лодаша понадобился один только groupBy и это потому что rxjs-аналог довольно странный.
А насчет того, что заменит, это врядли.
Rx реактовцам не впихнешь, хотя он и в реакте ложится довольно удобно через самописные хуки.
nin-jin
07.02.2022 01:05-2Ребят, вы тут спорите какая какашка лучше, в то время как есть куда более продуманные решения.
nsinreal
07.02.2022 01:15-1redux-saga героически решает проблемы, которые redux создал.
ну и тут тоже ошибка, как-бы. redux-saga не решает проблемы, созданные redux. redux-saga решает проблемы, которые не решил redux.
эквивалент redux-saga - это ngrx/effects, только ngrx/effects - дерьмо поверх ngrx+rxjs.
Зачем тащить это барахло, когда все есть в rx и еще дофига всего разного
а вы микроскопом гвозди не забиваете, случаем, с таким уровнем аргументации?
Xuxicheta
07.02.2022 01:30ngrx/effects - дерьмо поверх ngrx+rxjs.
тут соглашусь. ngrx вообще появился когда реактовцы зачем-то притащили свой flux в ангуляр.
а вы микроскопом гвозди не забиваете
Еще раз. Я использую один универсальный инструмент для широкого круга задач, связанных с распространением изменений данных и контроля процессов. А по вашему я для каждого гвоздика и шурупчика должен выкопать и применить свой узкоспециализированный? И при этом убедить коллег применять точно такой же. А зачем?
nsinreal
07.02.2022 01:46тут соглашусь. ngrx вообще появился когда реактовцы притащили свое барахло в ангуляр.
ngrx появился, потому что rxjs явно недостаточно для стейт-менеджмента.
Еще раз. Я использую один универсальный инструмент для широкого круга задач, связанных с распространением изменений данных и контроля процессов. А по вашему я для каждого гвоздика и шурупчика должен выкопать и применить свой узкоспециализированный? И при этом убедить коллег применять точно такой же. А зачем?
Беда универсальных инструментов в том, что на них все задачи решаются через жопу.
Xuxicheta
07.02.2022 02:10Если rxjs недостаточно, то есть RxState или elf. Оба предоставляют достаточно удобный инструментарий без лишних структур. Но на практике таки достаточно.
JustDont
07.02.2022 10:26+1ну и тут тоже ошибка, как-бы. redux-saga не решает проблемы, созданные redux. redux-saga решает проблемы, которые не решил redux.
Я вас, пожалуй, тоже поправлю: redux-saga не решает проблемы, созданные redux, не решает проблемы, которые не решил redux, а решает проблемы, созданные им самим.
jakobz
06.02.2022 14:55+4Мне кажется, что львиная доля нелюбви к реакту идет от redux, почему-то заезжающему вместе. React - one love. Redux - хрень, не решающая никаких проблем, если только кому не платят за бесполезные строчки кода.
nsinreal
06.02.2022 18:37redux решает проблемы, просто раньше он решал проблемы довольно большой ценой. Сейчас есть redux-toolkit, который уменьшил количество страданий до приемлемого.
strannik_k
06.02.2022 22:27+2Интересно, что с redux-toolkit он стал больше похож на другие менеджеры состояний, которые появились за несколько лет до redux-toolkit и еще тогда решали аналогичные проблемы без такого количества страданий.
nsinreal
06.02.2022 23:30-2С точки зрения архитектуры redux несколько более правильная штука. В частности, из-за предсказуемости.
Xuxicheta
07.02.2022 00:25+4с точки зрения архитектуры это godlike object антипаттерн. С прикрученным потоком событий.
nsinreal
07.02.2022 01:03а, расскажите, по вашей логике DI-контейнеры тоже godlike объект?
Xuxicheta
07.02.2022 01:23У вас рассогласование числа в одном предложении :)
А так, ну смотря какой di. В Ангуляре он иерархический, и соседние экземпляры могут использовать инжектор одинаковым образом, но получать свои собственные экземпляры. Что в редаксе провернуть уже проблематично, придется лепить составные ключи и пробрасывать их внутрь структуры.
Да и задача, решаемая di, совершенно другая.
nsinreal
07.02.2022 23:05А так, ну смотря какой di. В Ангуляре он иерархический, и соседние экземпляры могут использовать инжектор одинаковым образом, но получать свои собственные экземпляры. Что в редаксе провернуть уже проблематично, придется лепить составные ключи и пробрасывать их внутрь структуры.
Ну т.е. если в ангуляре инжектор был бы не иерархический, он был бы godlike?
А если бы в redux существовал прозрачный механизм иерархичности, он перестал бы быть godlike?
Да и задача, решаемая di, совершенно другая.
Это оправдывает di?
Xuxicheta
07.02.2022 23:09Ну т.е. если в ангуляре инжектор был бы не иерархический, он был бы godlike?
да, он такой в angular.js и это очень неудобно.
А если бы в redux существовал прозрачный механизм иерархичности
лучше изоляции, но да. Но вообще это будет обычный useReducer.
Это оправдывает di?
Свою задачу он решает.
nsinreal
07.02.2022 23:41лучше изоляции, но да. Но вообще это будет обычный 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 типа свою задачу не решает? Просто в моих руках он отлично подходил, чтобы решать мои проблемы.
Xuxicheta
07.02.2022 23:49+1В реакте mobx удобнее и гибче.
В ангуляре я раньше жил с akita, он использует редаксовские девтулзы, но удобней в использовании чем тот же ngrx, но со временем вообще избавился от него в пользу голого rxjs, а девтулзы перестал использовать еще раньше. В нетривиальных случаях от них мало толку, отследить огромный поток событий сложно, а в тривильных проще отследить инпуты компонента.
А redux типа свою задачу не решает?
Отлично решает задачу хранения глобального состояния. Впрочем столь же отлично, как и вообще что угодно из стейтов.
faiwer
07.02.2022 01:16+2Глобальная переменная с возможностью связи чего угодно с чем угодно это правильная, с точки зрения архитектуры, штука? Да ладно?
nsinreal
07.02.2022 01:31Если вы под "глобальная переменная" имеете в виду то, что в большинстве приложений всего один redux-стор, то вы всегда можете сделать несколько сторов при необходимости. См. https://redux.js.org/usage/isolating-redux-sub-apps
Как-бы, каждый дрочит как хочет, redux предоставляет вам свободу. Обычно так не делают, но не по причине "так нельзя".
А какое стейт-менеджмент решение вы считаете более хорошим с архитектурной точки зрения, чем использование redux?
nin-jin
07.02.2022 01:37+1Но при создании нескольких сторов вы получаете все те же проблемы, для решения которых Redux и создавался: расинхронизация сторов и неатомарность изменений.
faiwer
07.02.2022 01:48+5то вы всегда можете сделать несколько сторов при необходимости
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.
nsinreal
07.02.2022 02:38-3Redux тем и отличается от 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 обязательно должен прорывать". Прекрасно.
faiwer
07.02.2022 11:44+3Честно говоря я так и не понял, что вы хотели сказать этим комментарием. Единственный довод, который я увидел, это 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-а) сам говорит, что будет гореть в аду, за его создание. Не могу с ним не согласиться.
nsinreal
07.02.2022 13:58Так же как и упускаете важный факт — при более разумной архитектуре вам в принципе нужно куда реже что-нибудь дебажить.
Не бывает таких волшебных архитектур, чтобы не приходилось дебажить. Но эта фраза все объясняет. Скорее всего, сложность вашего бизнес-кода довольно тривиальна, раз вам не нужно дебажить.
проблемой O(n) на подписках
это единственная существенная проблема и то нужно постараться, чтобы в неё упереться.
nin-jin
07.02.2022 14:02+1это единственная существенная проблема и то нужно постараться, чтобы в неё упереться.
Например, написать не совсем тривиальный бизнес-код?
nsinreal
07.02.2022 14:08Проблема O(n) на подписках аукнется не в случае нетривиального бизнес-кода, а в случае попытки отобразить слишком много данных. Грубо говоря, при любом изменении стора у вас дергается проверка "а надо ли инициализировать попытку перерендера реакт-компонента?". Данная проблема никак не лечится, но к нетривиальности бизнес-кода не имеет никакого отношения.
Нетривиальный бизнес-код — это когда у вас сайд-эффекты есть. Там тоже можно O(n) случайно добиться, но если так произойдет, то это можно починить.
nsinreal
07.02.2022 02:48-2Применяется ли что-то подобное на практике где-нибудь ещё? Да. Например системы вроде babel и webpack. Там развесистые системы хуков. Всё можно связать со всем практически каким-угодно способом. Зачем там весь этот ад? Потому что нужна супер-гибкость для произвольных плагинов. Архитектура заложена такая, чтобы не пришлось переписывать весь core ради очередного плагина. В какой-то степени это расплата за требования в сверх-гибкости.
И вот этот вот отрывок очень прекрасен. Прям хочется спросить. Вы таки правда предлагаете писать код так, чтобы при необходимости добавить что-то пришлось переписывать все нахуй?
И называете это хорошей архитектурой? А что же мы получаем взамен? Некую строгую фиксированную изоляцию, которая не нужна, потому что соблюдается сама по себе?
faiwer
07.02.2022 11:45+1Вы таки правда предлагаете писать код так, чтобы при необходимости добавить что-то пришлось переписывать все нахуй?
Матерная речь на хабре не усиливает вашу позицию. Зря вы так.
А если по существу, то почитайте про принцип YAGNI.
jakobz
07.02.2022 12:01+4В основе Redux лежит идея из ФП-мира - централизованный стейт, меняющийся синхронно и атомарно - это благо. Но в ФП (см. Хаскель, ELM) - понятно как делать декомпозицию состояния. Тип данных, конструктор, и операции над типом данных - кладешь в модуль, и все понятно как инкапсулировать и переиспользовать.
В redux это потерялось по-дороге. Хотя вполне можно было бы это, хотя-бы, продумать и объяснить. Можно попробовать сделать это поверх redux - но он, скорее, будет мешаться.
А без инкапсуляции, централизованный стейт - больше создает проблем, чем решает.
Вот, например, можно элементарно написать хук типа const [isLoading, data] = useApiCall('/api/getItems') - один раз, и потом в 90% случаев писать только эту строчку. Как вот такое сделать переиспользуемое на redux?
И можно мне как-нибудь гарантировать, что страничка А не сломает страничку Б, если страничка А откроется перед Б?
Асинхронщина и прочие эффекты - туда же. Типа "потом библиотекой сделаем". Ага, да. Либо опять пишем асинхронный императивный код вообще сбоку (redux-saga), либо закат солнца вручную (redux-thunk).
В результате имеем библиотеку-карго-культ - нормально идею из ФП нам недонесли. Огрызок этой идеи - скорее зло. Зато придумали какой-то безумный API на кучу букв - который еще и приходится оборачивать другими либами чтобы использовать!
nsinreal
07.02.2022 14:16-1Вот, например, можно элементарно написать хук типа const [isLoading, data] = useApiCall('/api/getItems') - один раз, и потом в 90% случаев писать только эту строчку. Как вот такое сделать переиспользуемое на redux?
А в чем именно проблема? Довольно наивным образом пишется та версия хука, которая делит статус API-запроса между всеми компонентами. Если почему-то это не подходит и мы желаем строгой изоляции, то всегда можно побить стейт апи-запросов по отдельным инстансам компонентов (а идентифицировать их через
useState(newGuid())). Из тонких моментов нужно предусмотреть только очистку данных, когда они не нужны.Однако. Если вы считаете, что из компонента нормально дергнуть апиху напрямую, то у меня для вас плохие новости. Вам не нужен redux. Накладные расходы на него будут выше, чем польза.
Xuxicheta
06.02.2022 22:00Да там и без редакса хватает поводов материться. Когда одни и те же вещи решаются по разному, разными либами, да еще где-нибудь в глубине проброшенных 20 раз рендер пропсов, всплывающих в самых неожиданных местах. Реакт позволяет легко миксовать код и разметку, и этим злоупотребляют.
А вот редакс не проблема, он однотипный.
AriesUa
06.02.2022 23:20+1Как и автор, я не понимаю навязывания везде где только можно RxJS. Нет, с исторической точки зрения, оно понятно. Когда только начиналась разработка Angular 2, то async/await был в черновиках спецификации. И брать в работу что-то, что только в черновике спеки и еще не понятко как будет выглядеть в релизе, было бы очень стремным решением. Да и RxJs был (да и сейчас, благодяря Ангуляру) популярен.
Но сегодня не вчера, можно ведь и по другому.
У себя в проекте, мы сделали так. Разделили логику и компоненты. Все сервисы работают только с async/await. Вся обработка данных, проебразования итд только в service layer. Так же все вызовы к API проходят через инстанс класса API, который всего лишь обертка с методами GET/POST/PUT/DELETE над fetch функцией.
А компоненты ангуляра стали просто крайне простыми компонентами, которые просто берут данные из сервиса и рендерят. Не более.
Из профита.Service layer может быть написан не ангуляр девелоперами. Если нехватает рук, то ребята с бекенда могут без проблем имплементировать задачу.
Упростилось тестирование, так как тестируем сервис отдельно, а компонент отдельно. И тестирование компонента стало очень простым, так как там просто отображение данных.
Повысился перформанс приложения, так как мы убрали с ангуляра часть работы по проверке, сравнению итд.
Я к тому, что и на ангуляре можно нормально делать приложения. Главное включить думалку, а не слепо следовать разным модным трендам и делать только так, как книжка пишет.
Всем добра! :)
nsinreal
06.02.2022 23:32Когда только начиналась разработка Angular 2, то async/await был в черновиках спецификации. И брать в работу что-то, что только в черновике спеки и еще не понятко как будет выглядеть в релизе, было бы очень стремным решением
Зато с декораторами такой проблемы у них почему-то не сложилось.
Главное включить думалку, а не слепо следовать разным модным трендам и делать только так, как книжка пишетfixed: Главное включить думалку, а не следовать документации angular.
JustDont
07.02.2022 13:58+1Я к тому, что и на ангуляре можно нормально делать приложения.
Тут главное вовремя понять, что без ангуляра могло бы быть всё гораздо лучше. Вот скажем на хабре уже довольно давно пишут ребята из Тинькофф, делающие Taiga UI. Пишут они замечательные вещи. Но каждый раз читая их, я не могу отделаться от мысли, что то, что они пишут — где-то наполовину или даже больше борьба с ангуляром (в которой они мужественно победили ангуляр).
nin-jin
07.02.2022 14:05+3Можно подумать статьи о Реакте не про борьбу с созданными самим Реактом проблемами. Добрая половина из них про борьбу с ререндерами, вызванными протекующей абстракцией.
AriesUa
07.02.2022 14:25+1Я с вами полностью согласен. В моем случае у меня не было выбора. Решение использовать ангуляр было принято "сверху", и все что мне оставалось, по максимуму заставить его работать быстро.
А о том, к чему мы пришли в команде, я написал выше. :)
Xuxicheta
07.02.2022 21:53У них куча статей помимо тайги, где они делают разные классные штуки именно при помощи Ангуляра, вы говорите что без него было бы лучше :)) Там никто его не побеждал, они просто действительно используют возможности фреймворка.
JustDont
07.02.2022 22:42У них куча статей помимо тайги
Я про них и пишу.
где они делают разные классные штуки именно при помощи Ангуляра
Угу. Типа, "посмотрите, как мы классно победили ангулярский DI, чтоб им наконец-то было достаточно удобно пользоваться". Действительно, и почему же это я говорю, что без него было бы лучше?
Xuxicheta
07.02.2022 22:46Они не побеждают DI. Они им пользуются.
"Победить" в моем понимании это влезть в приватное апи, чето там намутить, что изначально не предусматривалось. Я такое действительно иногда делаю в редких случаях, чтобы сократить бойлерплейт.
А в статьях у них обычное использование инструмента по назначению. Просто возможности достаточно богатые, чтобы и так тоже делать, это штатные вещи всё, изначально заложенные.
А еще можно использовать async/await, навертеть поверх него каких-нить костылей и считать что "победили" Ангуляр %)
JustDont
07.02.2022 23:00+1"Победить" в моем понимании это влезть в приватное апи, чето там намутить, что изначально не предусматривалось.
Это "переписать", а уж никак не "победить". "Победить" — это дописать.
"Победить" — это взять кривоватый и неудобный инструмент, и таки найти путь применить его, спрятав весь неочевидный код в библиотечные классы и методы (как раз собственно то, о чем они пишут), и выставив наружу уже более интересное и удобное для применения API.
gorenburg
07.02.2022 23:01+1вопрос скорее про фрагментацию библиотек в реакте: в реакте есть свой роутер или нужно ставить одну из каких-то там библиотек? в реакте есть свой пакет для работы с формами или тоже что-то левое нужно ставить? тут, в принципе, можно еще и NgRx добавить и RxJS к сравнению. я это к чему - переходя с проекта на другой проект в ангуляре ты увидишь одну и ту же библиотеку и ты знаешь как она работает - ничего нового. а в реакте так же?
Xuxicheta
07.02.2022 23:21+2сюда же
1. анимации. Первый же запрос в гугл выдает кучу статей на тему "лучшие 10 способов сделать анимации в Rect"Изоляции стилей. Тоже самое.
DI. В реакте реализуется через Context и это выглядит просто адски.
Расширение компонентов. Вместо директив берите HOC внутри HOC внутри HOC внутри... Можно еще кучу вложенных хуков добавить по вкусу.
Для Http - axios, для интернационализации еще что-то, даже для лейзи лоадинга тоже часто всплывает какая-то либа.
В общем чтобы собрать себе удобную среду, нужно во-первых долго искать подходящие либы, потом это все связывать, а потом доказывать что вот именно это лучше, чем то.
nsinreal
07.02.2022 23:45в реакте есть свой роутер или нужно ставить одну из каких-то там библиотек?
Нету. по дефолту все тащат react-router
в реакте есть свой пакет для работы с формами или тоже что-то левое нужно ставить?
Нету. можно втащить formik, например.
переходя с проекта на другой проект в ангуляре ты увидишь одну и ту же библиотеку и ты знаешь как она работает - ничего нового. а в реакте так же?
Нет, не так же. Будешь видеть разные библиотеки, в зависимости от того, что именно лучше подходит. В этом и фишка.
gorenburg
08.02.2022 00:05В этом и фишка.
ну, по мне так это наоборот спорный момент. тут как раз выбор между свободой с фрагментацией+разной степенью мощности библиотек (реакт) и стандартными+мощными библиотеками (ангуляр)
nsinreal
08.02.2022 00:16fixed: выбор между свободой с кривыми библиотеками и стандартизацией с кривыми библиотеками.
Вся вот эта вот принудительная стандартизация — она вам нравится пока вы не упираетесь в то, что какая-то из частей экосистемы не выполняет ваши цели. И в случае ангуляра у вас меньше шансов заменить неподходящую библиотеку на другую.
Т.е. о чем говорить, если вы не можете использовать актуальную версию тайпскрипта без того, чтобы ангуляр обновился до неё?
В общем, это срач android (react) vs iOS (angular)
gorenburg
08.02.2022 00:44вот как только вы подходите к моменту когда что-то стандартного не хватает - вы и думаете как быть. а когда хватает стандартного - нет головной боли. ну и про "стандартные кривые библиотеки" - в ангуляре они как раз таки отличные. бывает что у них есть до боли тупые проблемы о которых знают, но которые пока не собираются решать, но это скорее исключение
я бы не назвал это срачем - я бы назвал это сравнением что имеет одна библиотека против другой чтобы можно было сравнивать предметно и по пунктам, а не орать в 3 горла что одно хуже другого потому что "ТАМ ВСЁ ПЛОХО"
Xuxicheta
08.02.2022 00:00На самом деле просто возьми какой-нибудь живой проект на реакте и насладись :) А лучше два, от другой тимы.
gorenburg
08.02.2022 00:02да вот тоже думал об этом. так, для сравнения понять что и как. просто потом придя в другой проект на реакте я скорее всего увижу уже что-то новое :)
Xuxicheta
08.02.2022 00:06+1Реакт предоставляет невероятную возможность постоянно изучать все новые и новые способы делать привычные вещи :D
На самом деле это даже прикольно, но постоянно чего-то не хватает, вроде и гибкость, но вечно какое-то костылестроение.
RouR
Я настоятельно рекомендую вам разобраться (почитать или пройти курс) с RxJS и Observable. Там объснят что некоторые observable не "заканчиваются", как кешировать данные стандарным shareReplay и на другие ваши вопросы.
Сейчас пишу проект с RxJS - совсем по другому приходится мыслить и компоновать код, и у этого способа есть свои плюсы. Некоторые вещи становятся очень простыми. Но иногда когнитивная сложность становится большой, впрочем, такое на любом фреймворке можно наговнокодить.
Alexufo
Будем открывать?)
