Претензия то в чем? Что я не смотрю на Mobx? а где я такое заявлял? Смотреть и использовать это разные вещи.
Сигналы посмотрел и предметно прокомментировал, автор коммента про то, что это чуть ли не новый стандарт и нужно использовать только их сразу куда то слился с обсуждения. Как это всегда бывает. И как будет с вами.
все остальные плохие и нехорошие
Тут вы правы, я действительно считаю большинство комментаторов хабра (да и вообще тыкателей клавиатуры, тем более на JS) неконструктивными, хороших разрабов абсолютное меньшинство. Если бы был сервис споров на деньги, я бы за счет таких уже обогатился. Кстати, надо такой сделать.
Большая просьба всех любителей очередных "убийц" React, Zustand, Redux - обсуждать это в соответствующих статьях про выбор и сравнение технологий. Хотелось бы иметь здесь комментарии по статье, а не превращать их в извечный, практически всегда неконструктивный спор.
Минусаторам любителей "убийц" - отдельный привет, вам тут не рады, но к сожалению это реалии хабра. Давать минусы всем моим комментариям, карме и даже статье - видимо все на что вы способы.
Вы если хотите обсудить ту статью, то стоит это сделать там. И учитесь это делать конструктивно - так, как написана статья, с примерами кода. Ничем не подкрепленные мнения мне абсолютно не интересны.
И да, помню вас, что конструктивно это делать у вас там не получилось. Теперь гадите минусами комментариев во всех моих статьях - ваш уровень.
Я занимаюсь мобильной разработкой, которая точно не переедет ни на Vue, ни прости господи Angular, и мне есть чем интересоваться. И пока я на ней работаю сменилось уже множество "убийц" и зустанда/редакса, и реакта. А по части различных архитектур - насмотренности уже более чем достаточно, куда больше чем у любителей ранее перечисленных "убийц".
Никто не называл сигналы "стандартом разработки",
Именно что очень неоднозначно заявлял.
однако, на различных конференциях и митапах эта тема стала появляться делятся опытом использования этой идеи - и в основном она положительная.
Отлично, пусть побудут бетатестерами, я не имею желания.
В моей статье нет ни одного конструктивного коммента за классы - в каком моменте они лучше, при том что это самая обсуждаемая статья по программированию за 2025 год.
Такие как вы просто не могут в конструктив, поэтому да, заканчивайте.
@preact/signals 0.6м скачиваний против 54.5м у зустанда. Понятно что вы так триггеритесь. Ну ок, может и правда в реакте что то гениальное появилось, посмотрим:
If you need to instantiate new signals or create new side effects on signal changes inside your components, you can use the useSignal, useComputed and useSignalEffect hooks.
Новое апи в тч для эффектов. Круто. Сейчас все начнем переписывать.
If you pass a signal directly into JSX, it will bind directly to the DOM Text
ММ, магию, которая работает никому неизвестно как - такое джуны любят. Правда как начнутся проблемы, придется либо все переписывать, либо терпеть. Н - надежность.
Using signals in render props is not recommended. In this situation, the component that reads the signal is the component that calls the render prop, which may or may not be hooked up to track signals.
Еще и на Бабель нужно полагаться, чтобы код работал, только вот незадача - он не сработает в некоторых случаях. Сразу захотелось затащить в проект.
Similar issues exist with using object getters & setters. Since the it isn't easily statically analyzable that a getter or setter is backed by a signal, the Babel plugin may miss some components that use signals in this way.
Ну короче магия не всегда срабатывает, нужно поставить mode: all и все заработает. И конечно же очень оптимизированно - так разрабы написали.
Изучив данную библиотеку, прихожу к выводу, что она пригодна лишь для очень популярных в России псевдоахритекторов, не до конца разобравшимся даже с оф документацией и работой основного апи, которым только скажи что есть убертехнология, регающая все проблемы (как - неважно), и они начнут ее внедрять везде, докуда дотянутся. А как только все пойдет по звезде - ливают с проекта и оставляют горе-заказчика с этим один на один (ну либо переписывают все проекты как не так давно ВК с эффектором).
Хорошо, что есть и разрабы, которые не любят использовать всякий мусор, хоть таких и единицы.
Про Vue, Angular и тп мне глубоко все равно, нет желания разбираться что там происходит. А в ТС39 - там чего только нет, в тч есть и парочка моих, это вообще смешно приводить пример какого то непринятого командой JS пропозала. Как примут, так и поговорим.
Напоминает ситуацию с абсолютным мусором - WatermelonDB. Чего только там разрабы не обещали, и кто только ее не затащил. Закончилось у многих одинаково - под небольшой нагрузкой работает как кусок г****, помогает только полное переписывание проектов с ее удалением.
Чтобы понимать, почему то, что вы перечислили это переусложнение - mobx, классы, нужно как раз иметь хорошее архитектурное мышление. Если его не иметь, то все кажется простым и понятным.
RxJS это не совсем state manager, его можно использовать в этом качестве, особенно если взглянуть на subject, но изначально он создавался для управления потоками данных.
А то что какие то сигналы (из космоса?) якобы сейчас это стандарт разработки вы так и не доказали, и не докажете потому что это чушь.
Технология, оборачивающая все в прокси, на платформе, где большинство разрабов с зустандом то разобраться до конца не могут - это приговор. Умножим это еще на отсутствие хороших коробочных решений по кэшированию запросов.
Есть варианты и с Rx - сложно, но предсказуемо (не мой выбор), либо EventEmitter для простой мутабельности, либо оптимизации из статьи, решающие все реально встречающиеся проблемы на простых как топор иммутабельных сторах.
Но хотите пишите на нем, для меня это мусорная библиотека.
На каких технологиях нет проблем?
«Веб-разработчик Младший» - хотя можете не отвечать.
Претензия то в чем? Что я не смотрю на Mobx? а где я такое заявлял? Смотреть и использовать это разные вещи.
Сигналы посмотрел и предметно прокомментировал, автор коммента про то, что это чуть ли не новый стандарт и нужно использовать только их сразу куда то слился с обсуждения. Как это всегда бывает. И как будет с вами.
Тут вы правы, я действительно считаю большинство комментаторов хабра (да и вообще тыкателей клавиатуры, тем более на JS) неконструктивными, хороших разрабов абсолютное меньшинство. Если бы был сервис споров на деньги, я бы за счет таких уже обогатился. Кстати, надо такой сделать.
@markelov69 Вы уже тоже пробовали что то доказать в той статье, но конструктивно не получилось.
Тем более, что в статье именно на этом примере и показано в чем разница. Перечитайте. И да, ту статью давайте обсуждать там.
Нет, вполне достаточно линтером запретить ключевое слово class, что я уже очень давно и делаю на своих проектах.
Если на редаксе у вас получается говнокод, то у меня для вас плохие новости.
Большая просьба всех любителей очередных "убийц" React, Zustand, Redux - обсуждать это в соответствующих статьях про выбор и сравнение технологий. Хотелось бы иметь здесь комментарии по статье, а не превращать их в извечный, практически всегда неконструктивный спор.
Минусаторам любителей "убийц" - отдельный привет, вам тут не рады, но к сожалению это реалии хабра. Давать минусы всем моим комментариям, карме и даже статье - видимо все на что вы способы.
Спасибо.
Множество примеров кода с объяснением. Набросы это ровно то, что делаете вы:
PS. Ту статью давайте обсуждать там.
Вы если хотите обсудить ту статью, то стоит это сделать там. И учитесь это делать конструктивно - так, как написана статья, с примерами кода. Ничем не подкрепленные мнения мне абсолютно не интересны.
И да, помню вас, что конструктивно это делать у вас там не получилось. Теперь гадите минусами комментариев во всех моих статьях - ваш уровень.
Я занимаюсь мобильной разработкой, которая точно не переедет ни на Vue, ни прости господи Angular, и мне есть чем интересоваться. И пока я на ней работаю сменилось уже множество "убийц" и зустанда/редакса, и реакта.
А по части различных архитектур - насмотренности уже более чем достаточно, куда больше чем у любителей ранее перечисленных "убийц".
Именно что очень неоднозначно заявлял.
Отлично, пусть побудут бетатестерами, я не имею желания.
В моей статье нет ни одного конструктивного коммента за классы - в каком моменте они лучше, при том что это самая обсуждаемая статья по программированию за 2025 год.
Такие как вы просто не могут в конструктив, поэтому да, заканчивайте.
Язык без иммутабельности? Да в TS с ней работать удобнее чем большинстве других языков.
Классы уже выкинули практически отовсюду, в том числе из React, Redux, Zustand и тп. Чтобы оценивать других нужно самому что то из себя представлять.
В JS много исторического мусора, и много на нем построено, речь про код, который пишет разработчик.
@preact/signals 0.6м скачиваний против 54.5м у зустанда. Понятно что вы так триггеритесь. Ну ок, может и правда в реакте что то гениальное появилось, посмотрим:
If you need to instantiate new signals or create new side effects on signal changes inside your components, you can use the
useSignal,useComputedanduseSignalEffecthooks.Новое апи в тч для эффектов. Круто. Сейчас все начнем переписывать.
If you pass a signal directly into JSX, it will bind directly to the DOM
TextММ, магию, которая работает никому неизвестно как - такое джуны любят. Правда как начнутся проблемы, придется либо все переписывать, либо терпеть. Н - надежность.
Using signals in render props is not recommended. In this situation, the component that reads the signal is the component that calls the render prop, which may or may not be hooked up to track signals.
Еще и на Бабель нужно полагаться, чтобы код работал, только вот незадача - он не сработает в некоторых случаях. Сразу захотелось затащить в проект.
Similar issues exist with using object getters & setters. Since the it isn't easily statically analyzable that a getter or setter is backed by a signal, the Babel plugin may miss some components that use signals in this way.
Ну короче магия не всегда срабатывает, нужно поставить mode: all и все заработает. И конечно же очень оптимизированно - так разрабы написали.
Изучив данную библиотеку, прихожу к выводу, что она пригодна лишь для очень популярных в России псевдоахритекторов, не до конца разобравшимся даже с оф документацией и работой основного апи, которым только скажи что есть убертехнология, регающая все проблемы (как - неважно), и они начнут ее внедрять везде, докуда дотянутся. А как только все пойдет по звезде - ливают с проекта и оставляют горе-заказчика с этим один на один (ну либо переписывают все проекты как не так давно ВК с эффектором).
Хорошо, что есть и разрабы, которые не любят использовать всякий мусор, хоть таких и единицы.
Про Vue, Angular и тп мне глубоко все равно, нет желания разбираться что там происходит. А в ТС39 - там чего только нет, в тч есть и парочка моих, это вообще смешно приводить пример какого то непринятого командой JS пропозала. Как примут, так и поговорим.
Напоминает ситуацию с абсолютным мусором - WatermelonDB. Чего только там разрабы не обещали, и кто только ее не затащил. Закончилось у многих одинаково - под небольшой нагрузкой работает как кусок г****, помогает только полное переписывание проектов с ее удалением.
Похоже на борьбу с инструментом. В вашем случае лучше либо его освоить, либо сменить. Первое как минимум покончит со страданием.
PS. Реакт не запрещает использовать мутабельные сторы, если они вам так почему то нравятся.
Чтобы понимать, почему то, что вы перечислили это переусложнение - mobx, классы, нужно как раз иметь хорошее архитектурное мышление.
Если его не иметь, то все кажется простым и понятным.
RxJS это не совсем state manager, его можно использовать в этом качестве, особенно если взглянуть на subject, но изначально он создавался для управления потоками данных.
А то что какие то сигналы (из космоса?) якобы сейчас это стандарт разработки вы так и не доказали, и не докажете потому что это чушь.
PS. И да, RxJS сейчас популярнее, не спорю.
mapStateToProps это лишь один из примеров, и он до сих пор используется во многих проектах
то что появились хуки - так они тоже затронуты в статье и проблемы там те же самые остались, и тоже упомянуты в статье.
про слайсы RTK отдельно упомянуто в секции Immer (кратко - лучше не использовать)
статья в том числе и про zustand, в котором меньше предупреждений если что то используется неправильно
Если с чем то не согласны раскройте мысль поточнее. Либо читайте внимательнее, и разберитесь в технологии получше.
Именно так я и представляю типичного адвоката mobx. Топит за то, что понимать код не надо, и что классы - это отличная вещь )
Технология, оборачивающая все в прокси, на платформе, где большинство разрабов с зустандом то разобраться до конца не могут - это приговор. Умножим это еще на отсутствие хороших коробочных решений по кэшированию запросов.
Есть варианты и с Rx - сложно, но предсказуемо (не мой выбор), либо EventEmitter для простой мутабельности, либо оптимизации из статьи, решающие все реально встречающиеся проблемы на простых как топор иммутабельных сторах.
Но хотите пишите на нем, для меня это мусорная библиотека.