Технология, оборачивающая все в прокси, на платформе, где большинство разрабов с зустандом то разобраться до конца не могут - это приговор. Умножим это еще на отсутствие хороших коробочных решений по кэшированию запросов.
Есть варианты и с Rx - сложно, но предсказуемо (не мой выбор), либо EventEmitter для простой мутабельности, либо оптимизации из статьи, решающие все реально встречающиеся проблемы на простых как топор иммутабельных сторах.
Но хотите пишите на нем, для меня это мусорная библиотека.
Понимать код это не читать высокоуровневый код, обмазанный проксями, а рассказать от и до что происходит в случае, например, мерджа данных в большой список.
А про классы у меня есть отличная статья, пора их уже наконец выкинуть из JS/TS.
Можете скинуть количество скачиваний пакета ваших сигналов и, например, зустанда? Чтобы мы могли оценить насколько сегодня, в 2026 году, они популярнее. Ну и Redux заодно.
Ок, за мной самая комментируемая статья по программированию в 2025 году. Значит не зря выбрал хабр!
Единственное что не очень радует - жалоба на низкий технический уровень статьи обычно идет без конструктивных комментариев, либо вместе с комментарием очень низкого технического уровня.
Примеры кода взяты из реальных проектов где он рефакторил. Так вот для большинства людей этот "чистый" код куда сложнее, чем можно написать что сейчас, что в то время.
И это одинаково плохо как для небольшого скрипта, так и для огромного монолита на миллионы строк.
Нельзя писать сегодня хорошо, а завтра плохо. Ты либо крутой разработчик, либо нет. Его код - кал, который не пропустили бы на код ревью ни в одном нормальном проекте.
Очередная обучалка от некомпетентного кодера, и не ленятся же еще статьи писать.
Использование классов, методов и this (особенно в JS) - антипаттерн. Выкиньте этот мусор и код станет намного проще, как сделали во всех современных библиотеках.
Технология, оборачивающая все в прокси, на платформе, где большинство разрабов с зустандом то разобраться до конца не могут - это приговор. Умножим это еще на отсутствие хороших коробочных решений по кэшированию запросов.
Есть варианты и с Rx - сложно, но предсказуемо (не мой выбор), либо EventEmitter для простой мутабельности, либо оптимизации из статьи, решающие все реально встречающиеся проблемы на простых как топор иммутабельных сторах.
Но хотите пишите на нем, для меня это мусорная библиотека.
Понимать код это не читать высокоуровневый код, обмазанный проксями, а рассказать от и до что происходит в случае, например, мерджа данных в большой список.
А про классы у меня есть отличная статья, пора их уже наконец выкинуть из JS/TS.
> И что вы этим докажете?
Вы просто не привыкли доказывать утверждения, а я привык. В случае с популярностью это доказывается именно так.
> Что много легаси на редаксе работает?
Так зустанд же не легаси, но вы почему то его не упоминаете. Понятно почему.
Мучиться там придется еще больше на больших проектах, и при этом практически никто не будет понимать как он реально работает - фатальный недостаток.
Хелловорлды симпатичнее, да.
Уж лучше в сторону Rx или аналогов смотреть если хочется полностью мутабельный подход, вопрос только зачем.
Можете скинуть количество скачиваний пакета ваших сигналов и, например, зустанда? Чтобы мы могли оценить насколько сегодня, в 2026 году, они популярнее. Ну и Redux заодно.
Ок, за мной самая комментируемая статья по программированию в 2025 году. Значит не зря выбрал хабр!
Единственное что не очень радует - жалоба на низкий технический уровень статьи обычно идет без конструктивных комментариев, либо вместе с комментарием очень низкого технического уровня.
Понимаю что многим сложно думается и уточню - приведен пример с классом, и там подписок нет.
Я уже знаю куда пойдет диалог - в конструирование хелловорлд велосипедов на классах, участвовать в этом не хочу, тем более с таким «архитектором».
Процедурному программированию не свойственны замыкания, функций первого порядка и иммутабельность, это во-первых. Тут прокол.
Фабрика это по определению класс, а в ФП их нет. Еще прокол.
В конструктив вы не могете, советы попридержите 👍
У вас очень слабое понимание архитектуры, ваш пример даже не реактивный / событийный.
Статья максимально конструктивно это объясняет https://habr.com/ru/articles/885980/
В эпл только ОС умеют писать, весь остальной софт лютый кал.
Примеры кода взяты из реальных проектов где он рефакторил. Так вот для большинства людей этот "чистый" код куда сложнее, чем можно написать что сейчас, что в то время.
И это одинаково плохо как для небольшого скрипта, так и для огромного монолита на миллионы строк.
Очевидно что плохими они были уже на момент написания книги. На С можно переписать намного проще, на фортране и паскале, и даже на java.
Нельзя писать сегодня хорошо, а завтра плохо. Ты либо крутой разработчик, либо нет. Его код - кал, который не пропустили бы на код ревью ни в одном нормальном проекте.
А надо воспринимать «как делать не нужно».
Сначала пишешь крутой код, потом уже книги. Дядя боб начал с конца.
Очередная обучалка от некомпетентного кодера, и не ленятся же еще статьи писать.
Использование классов, методов и this (особенно в JS) - антипаттерн. Выкиньте этот мусор и код станет намного проще, как сделали во всех современных библиотеках.
Кому интересно подробнее - есть статья https://habr.com/ru/articles/885980
Становиться тем кто принимает решения, аргументированно спорить.
Ответ здесь https://habr.com/ru/articles/885980
Ответ почему они это делают есть в статье https://habr.com/ru/articles/885980
Это ждёт все ООП языки. Как говорится, «будет хуже» (с).