Комментарии 77
то, что должно быть цельным внутри компонента, оказывается размазанным по множеству файлов и сущностей
О чем речь вообще?
даже небольшое изменение функционала может потребовать относительно большие изменения в коде, так еще и код этот однотипный и не несущий никакой полезной для данной конкретной задачи нагрузки
О чем конкретно речь?
инструменты, направленные на решение этой проблемы, существуют, но как по мне - не решают ее полностью.
Почему не решают? Какие инструменты?
А еще мне не нравится, что Redux или схожие с ним инструменты пытаются использовать там, где они не нужны
Это проблема инструмента?
Но в Angular такой проблемы нет, Injectable-сервисы прекрасно справляются с этой задачей
Скорее уж rxjs, injectable и стейт так себе связаны, Вы точно понимаете о чем речь?
А вот RxJS тут как раз ни при чём:)
В Ангуляре на самом деле используется дерево контекстов (Injector), а не один глобальный контейнер.
А вот RxJS тут как раз ни при чём:)
Все стейт менеджеры на ангуляре основаны на rxjs, даже если Вы свой будете делать - это будут сервисы с rxjs
IoC Container, который в свою очередь является глобальным состоянием приложения
Что? Есть ссылки, подтверждающие это?
MobX не основан на RxJS. Хотя и прикручивается через недокументированные костыли.
Что? Есть ссылки, подтверждающие это?
Собственно, сама документация angular.io/guide/dependency-injection
Никакого отношения Angular DI сам по себе к rxjs не имеет.
DI — это иерархия контейнеров, начиная от от глобального состояния и вплоть до локального состояния отдельного компонента, с общим единым подходом. По большому счёту, весь Angular — это просто реализация фреймворка поверх DI.
А rxjs, в свою очередь, — это уже существенная часть фреймворка.
Вот, например, одна из его standalone имплементаций ( от одного из представителей Angular Core Team) www.npmjs.com/package/injection-js, которую можно использовать где-угодно и там явно видно, что никаких внешних зависимостей(кроме tslib) у реализации DI нет.
На основе подобной библиотеки можно строить свои фреймворки, к Angular отношения не имеющие.
Собственно, сама документация angular.io/guide/dependency-injection
Я там про состояние ничего не увидел
Никакого отношения Angular DI сам по себе к rxjs не имеет.
Я обратного не утверждал. Я не согласен с идеей, что «ангуляру не нужен redux т.к. в ангуляре есть DI», изначально как то так звучала мысль
С остальным я согласен, да в общем и не спорил
Я там про состояние ничего не увидел
Не увидеть — не значит, что этого там нет. Состояние — это просто область памяти специфического назначения. Сервисы, в сочетании с rxjs и без оного, прекрасно реализуют работу с состоянием. Но и не только они. В целом, состояние — это неотъемлемый атрибут любой машины Тьюринга и поэтому присутствует везде. Даже если это слово не употебляется. Явной модели управления состоянием фреймворк не навязывает(хоть и намекает на неё).
Мысль, что «ангуляру не нужен redux т.к. в ангуляре есть DI» странна сама по себе. DI — это про управление зависимостями. Redux — про управление потоками данных. DI для angular — это фундамент, поверх которого он построен.
Redux — как способ организации потока данных абсолютно опционален. Он не нужен(или нужен) не потому, что есть DI, а потому, что есть масса и других способов организовать управление состоянием хоть с использованием DI, хоть без него.
Состояние — это просто область памяти специфического назначения
Ну это уже демагогия пошла. IoC контейнер всё ещё не является 'состоянием' в общем смысле.
Мысль, что «ангуляру не нужен redux т.к. в ангуляре есть DI» странна сама по себе
Ну так мысль то не моя, я изначально про неё и высказался, в оригинале
Redux предназначен для решения проблемы передачи данных в компоненты путем использования глобального State… Но в Angular такой проблемы нет, Injectable-сервисы прекрасно справляются с этой задачей
Я нисколько не топлю ни за redux ни против, более того — я им даже не пользуюсь
Я не согласен с идеей, что «ангуляру не нужен redux т.к. в ангуляре есть DI», изначально как то так звучала мысль
Ээ, нет, мысль звучала не совсем так
Redux предназначен для решения проблемы передачи данных в компоненты путем использования глобального State… Но в Angular такой проблемы нет, Injectable-сервисы прекрасно справляются с этой задачей
Вот же, нет?
1) Redux решает проблему передачи данных в компоненты, в случаях где нам неудобно/невозможно/нерационально использовать пропсы
2) В Angular аналогичную задачу принято решать с использованием сервисов, объявляемых с помощью Injectable (и соответственно через механизм DI внедряемых в компоненты — это не написано, но действительно подразумевается)
Здесь не написано что DI это замена Redux, но возможно мне нужно четче формулировать свои мысли
Явный троллинг
Ещё более явный троллинг
Опять же сродни троллинга
Это проблема API и ещё какая. Если уж инструмент не предназначен для чего либо, то и желательно как-то ограничить API. Опять же документация и внятное описание для решения каких проблем инструмент подходит. Топором тоже можно забить гвоздь, но ведь молотком удобнее.
Видимо понимает и ещё как. Делается отдельный сервис хранилище, отвечающий за конкретные данные. И пользуйтесь им на здоровье, в совокупности c RxJS вообще будет отличное решение. Да при этом данное решение ещё и легко тестируется.
в совокупности c RxJS вообще будет отличное решение.
Для тех, кто любит когда кровь из глаз течёт глядя на такой код да, вообще отличное решение :D
А если ещё и придётся через недельку другую к этому коду вернуться и что-то там пофиксить или добавить фичу, вообще сказочное самовозгорание произойдет :D
Люблю тогда такой «код» пишут, сразу столько проектов на рынке появляется которые нужно переписать с чистого листа по человечески, сказка.
Но на самом деле хотелось бы иметь простое и эффективное решение, лишенное вышеназванных недостатков. Context API? Может быть.
Серьезно?) Вы не знаете?) MobX разумеется ваше лекарство (и моё тоже).
Я постоянно пишу прототипы игр на js, хобби у меня такое. И как-то решил перейти на ts, а на нем мне стало что-то трудно сделать redux+thunk стек, плюс похожих статей начитался и решил забить на redux. Жили же без него и будем жить.
В итоге сделал, значит, кучу классов, Game, Entity, сделал Game.processTurn, на всякий случай выделил GameState чтобы жил отдельно. Для контроля за игрой сделал систему ивентов, чтобы entity сами решали, что они будут делать. Пара часов и вуаля, у меня есть базовая система ивентов, где мы высылаем "ивент", его ловят "ентити", у которых есть набор обработчиков на интересующие их ивенты.
Причем для большего удобства, ещё сделал так, чтобы ентити могли менять общий стейт игры. Который уже выделен отдельно и осталось сделать его иммутабельным и все.
Когда у меня получилось что-то вроде:
Game.ts:
...
this.fireEvent('attack', ...)
...
BaseFighterEntity.ts:
this.eventMap = {
move: (gameState, entityState) => {
...
return newGameState;
}
attack: (gameState, entityState) => {
...
return newGameState;
}
}Сижу я такой, довольный собой, вроде всё работает, удобно и без этого вашего redux, waaait a second, и вот тут до меня доходит, что же я наделал.
Программиста можно вытащить из redux, а redux из программиста уже нет.
Ну вы палку перегибаете. Это всё в минималистичном backbone.js из коробки есть, и при этом backbone.js никому не приходит в голову называть ридаксом. А похожие паттерны везде используются, на то они и паттерны, верно? Паб/саб, диспетчер-медиатор - это стандартные широко используемые штуки.
Если не ошибаюсь, пабсаб предполагает свободную подписку/отписку на каналы событий и отдельные, изолированные стейты подписчиков, которые не меняют общий глобальный стейт
Только там store.subscribe это не "стор может подписаться на что-то", а "подписать любой другой листенер на стор"
Action creator - это publisher. Хук или ХоК в составе коннекта - это subscriber. Стор не что-то умное, listener будет вызываться после каждого диспатча, даже если изменений в сторе не последовало. Диспатчер, скрывающийся за стором - это и есть канал событий.
Да, всё немного сложнее. Но давайте не будем холиварить о терминологии паттернов, это дело неблагодарное и напрочь субъективное. Да и суть не в этом, а в том, что увидев пару-тройку широкоиспользуемых паттернов, вы не можете вешать на всё вокруг ярлык "да это же redux!".
Вы правы в том, что принцип взаимодействия, основный на сообщениях "message-based", не нов. Но он настолько абстрактен (широк), что под него попадает куча всего разного: устная и письменная речь, голубиная почта, комментарии на Хабре, IP protocol, Http, ReST, упомянутый вами winapi - список можно продолжать до бесконечности. Принципиальные отличия, которые обусловливают применимость в том или ином случае, находятся в деталях.
По-моему основная заслуга flux в том, что он из конкретной технологии, которой пользовались дорогие годы PHP'шники (http, stateless server, database), сформулировал своеобразный абстрактный архитектурный принцип. Это позволило создать новые подобные решения, включая redux, для использования в других областях.
Сам по себе redux тоже довольно абстрактен - его можно "готовить" по-разному, и это создаст основные проблемы разработчикам. Например, один из альтернативных вариантов предлагает воспринимать действия "actions" не как команды (намерения) что-то сделать в будущем, а как события "events", т.е. информацию о том что уже случилось в прошлом. В этом есть определенная логика. Что случилось, то случилось и это уже нельзя отметить. Можно лишь сделать какие-то выводы (reducers) и где-то записать (state). Подобные соглашения снимают массу вопросов при разработке, но требуют определенной дисциплины, которую не понятно как формализовать, чтобы автоматически обнаруживать несоответствия в коде. Это делает такие решения довольно уязвимыми к ошибочным изменениям, что может быть так же причиной критики redux.
Redux хорошо уживаются с другими event-based паттернами, например Event Sourcing (одним из применений которого является пресловутая time machine, позволяющая проигрывать историю изменений в любой момент времени). Согласитесь, это совсем не похоже на то, как используют winapi.
Сравнение redux и win API это очень метко, у меня на один аргумент для споров стало больше. Жаль только, что множество молодых разработчиков не испытали на себе все это и не поймут всю боль. Возможно поэтому мы и наступаем на одним и те же грабли раз за разом.
Хорошо изложено. Согласен насчёт boilerplate-кода - это прямо беда.
И вот тут Redux подводит - то, что должно быть цельным внутри компонента, оказывается размазанным по множеству файлов и сущностей - получаем Low cohesion вместо High. Связи, которые должны оставаться внутри, выходят наружу
Вот с этим не могу согласиться. Основная идея центрального хранилища в том, чтобы обеспечить единый источник информации (source of truth), которая нужна в разных компонентах или даже в разных модулях. Redux отлично подходит для глобального стейта. Он также вполне позволяет изолировать часть состояния и его логику на уровне модуля. Ну а если какая-то логика и состояние нужны только в одном компоненте - используйте для этого внутренний стейт компонента. Не нужно всё локальное пихать в store - это и сам Дэн Абрамов, по-моему, советовал.
Ну а множество файлов - это неплохо, если файлы, относящиеся к одному модулю, лежат рядом в одной папке - так мы избегаем файлов на сотни строк кода, как часто бывало с WinAPI. К тому же, Redux Toolkit смягчает эту проблему, объединяя объявление экшнов и редьюсеров с помощью "слайсера" в одном файле.
Жаль, что про Redux-toolkit в основном либо не слышали, либо не пробовали. И ведь статей хватает что на Хабре, что на Медиуме.
Тут проблема в самой постановке. Добавим на redux сверху redux-toolkit, это уже практически столько же пожатого js, сколько одна mobx — и это просто для того, чтоб редаксом можно было пользоваться без боли… везде.
В конечном итоге бизнес всё равно потратит больше на оплату времени разработчика, чем потеряет в продажах из-за более медленной загрузки страницы. А потом и вовсе может оказаться так, что скорость выпуска новых фич в приложении гораздо важнее, чем размер бандла.
В этих делах важно найти золотую середину и redux-toolkit в этом случае как раз помогает перейти от чего-то что "так себе" к чему-то что "норм" без значительных потерь.
Я рассуждаю о том, что видел в использовании в рамках крупных проектов и о том, чем пользовался сам. Про MobX мне действительно мало известно, но радикализм в выборе технологий осуждаю.
Я рассуждаю о том, что видел в использовании в рамках крупных проектов и о том, чем пользовался сам.
Вы имеете ввиду древнее легаси, от которого воняет за километр. И не надо пытаться защищать такие проекты с точки зрения разработчика, это абсурдно. Топтаться годами на месте и тем более не смотреть по сторонам, не знаю какие есть инструменты, не пробуя их — тупиковый путь. Работая на таких проектах, вы автоматически отстаете от мира лет на 5. Про сильнейшую потерю навыков проектирования архитектуры и т.д. и т.п. я вообще молчу.
Про MobX мне действительно мало известно
Ахахах, жесть, в 2021 году слышать такие слова нелепо.
Очень странно, откуда вы тогда вообще про React слышали? Это же технология из нашей эры. К сожалению не удивительно тогда почему вы думаете что redux-toolkit это «норм».
но радикализм в выборе технологий осуждаю.
Сменить Redux на MobX это типо радикальный шаг который нафиг надо делать да?) Пересесть с гужевых повозок на машины тоже радикализм да?) Про освоение авиации и перемещение по воздуху я вообще тогда молчу) С такой логикой вы поступаете радикально, когда пишете на JS, ведь есть же замечательный assembler.
Меня умиляет, как вы смеётесь над теми, кто не пробовал мобх, но сами при этом не пробуете ничего лучше реакта. Парадокс Блаба во всей красе.
Меня умиляет, как вы смеётесь над теми, кто не пробовал мобх, но сами при этом не пробуете ничего лучше реакта. Парадокс Блаба во всей красе.
Кто сказал? Я пробовал всё из актуального, Vue (v2 и v3), Angular, Svelte, Flutter, React, Preact, Inferno и т.п. и лично для меня на сегодняшний день связка React + MobX является лучшей:
1) Cправляются со всеми моими проектами и задачами более чем достаточно.
2) Не связывают мне руки.
3) Дают легко читаемый, легко развиваемый и поддерживаемый код. Конечно если уметь его писать, если не уметь, то будет говно всегда)
Ваш любимый $mol не пробовал и не при каких обстоятельствах даже пробовать не буду, там настолько отвратительный синтаксис что мама не горюй. Путь он хоть будет работать в 100 раз быстрее реакта, будет в 1000 раз эффективней и т.п., всё равно из-за синтаксиса ни за что его не возьму.
Итого: для меня сейчас нету ничего лучше React'a + MobX.
$mol не пробовал и не при каких обстоятельствах даже пробовать не буду, там настолько отвратительный синтаксис что мама не горюй.
Я вот подозреваю (хотя нельзя сказать наверняка), что в $mol есть прорывные идеи. Но, увы, банально из-за синтаксиса он никогда не взлетит, даже если его будет пропушивать какая-нибудь корпорация.
Вы перепробовали много разных корнеплодов, но ни одного фрукта не ели, и утверждаете, что репа - вкуснее всего.
А малину даже пробовать не станете так как у неё форма странная и вся в пупырышках.
В идеальном безкомпромиссном мире я бы возможно когда-нибудь и попробовал ваш $mol. В реальном — я даже начинать не буду, потому что уже даже со Svelte есть определенные сложности по поводу объяснения её другим людям, когда вам нужен +1 программист на проекте или просто другой программист взамен вас.
И в этом смысле реакт прекрасно попадает в зону компромисса, Svelte — близок к ней, а $mol находится от неё настолько же далеко, насколько, скажем Idris от С++.
Что такое, стрелочка не поворачивается? Когда кто-то использует менее эффективную технологию, то вы смеётесь над ним, а когда сами используете менее эффективную, так начинаются отмазки в пользу дибилов, не способных прочитать документацию и освоить куда более простую технологию.
Что такое, стрелочка не поворачивается? Когда кто-то использует менее эффективную технологию, то вы смеётесь над ним, а когда сами используете менее эффективную, так начинаются отмазки в пользу дибилов, не способных прочитать документацию и освоить куда более простую технологию.
Вы путаете.
Дело не только в эффективности, дело в совокупности всех факторов.
А касаемо $mol, вам же сто раз уже говорили, что по совокупности факторов он не пригоден для использования(из-за адского синтаксиса), и не важно насколько он эффективный и быстрый.
Если брать голую эффективность и производительность, то React это достаточно ущербная штука. Но если взять React + MobX, то по совокупности всех факторов и по сравнению со всеми остальными альтернативами, получается лучший вариант на сегодняшний день.
Что такое, стрелочка не поворачивается?
Синтаксис у вас ущербнейший, это факт. И нет никаких оснований, почему он должен быть совершенно нечитаем, кроме как вашего "ну он только таким и должен быть, честно!".
Но дело не в этом. Дело в том, что в серьезный прод это брать — слишком высокие риски по поддержке, а что у вас "более эффективная технология", и причем настолько "более", чтоб крайне высокие риски по поддержке этого кода хоть как-то перебить своей великолепностью — это совершенно не доказано фактурой.
В сухом остатке имеем отличную технологию для протаскивания куда-нибудь в важное место тихой сапой в попытке стать незаменимым работником. А для адекватного использования — всё разбивается об то, что 9 из 10 фронтэндеров смотрят на это и говорят "ну и зачем это тут, уберите". А из оставшихся — еще 9 из 10 смотрят чуть дальше, и им становится плохо от синтаксиса и от запредельной местячковости всего проекта. А из джунов и вовсе 10 из 10 не хотят на это смотреть, потому что это не marketable skills.
Синтаксис у вас ущербнейший, это факт.
Докажите.
Это субъективная оценка, какое доказательство вы хотите тут видеть? И да — это факт, что для меня синтаксис $mol ущербнейший.
Впрочем, кое-какой небольшой анекдотичный опыт у меня собран: в общей сложности я навёл на $mol (среди прочих) с середины 2019 года шестерых коллег на двух разных работах и проектах — на одном нужен был выбор с чистого листа, на другом — можно было сменить реакт. До усечения выборки по критериям применимости к ситуации: 6/6 были готовы работать с реактом. 4/6 были готовы работать с ангуляром. 2/6 были готовы возиться с вебкомпонентами. 1/6 был готов на svelte. 0/6 захотели $mol.
Вот с этим не могу согласиться. Основная идея центрального хранилища в том, чтобы обеспечить единый источник информации (source of truth), которая нужна в разных компонентах или даже в разных модулях
С точки зрения исходной идеи — да, так и есть и должно быть. Но вот на практике почему-то так не получается.
Вот с этим не могу согласиться. Основная идея центрального хранилища в том, чтобы обеспечить единый источник информации (source of truth), которая нужна в разных компонентах или даже в разных модулях. Redux отлично подходит для глобального стейта.
Ну, с этим даже глобальные переменные справятся (ладно, утрирую, нужен еще какой-то Pub/Sub). В чем смысл, если нарушается инкапсуляция данных, принцип Single Responsibility? Singleton-сервис + Dependency Injection и задача решена без лишних сложностей.
Лично меня больше всего в Redux напрягает то, что селекторы не являются его частью. Это ведь общая система, как СУБД и удобно когда рядом с СУБД лежат и хранимые процедуры или VIEW, который знает всё об организации хранения данных и позволяет другим частям абстрагироваться от этого, что уменьшает число дублирующегося кода, ошибок, упрощает рефакторинг в случае необходимости. Такой себе фасад. Настрочили на Reselect кучу этих селекторов, всё хорошо, но как дебажить? Они нигде не видны.
Схожая ситуация с эффектами, которые у нас на сагах организованы. Хочется видеть где-то всех участников: экшны — редьюсеры — саги — селекторы.
Другой момент, который может больше к Реакту относится — пихаемая где надо и не надо декларативность. Ну вот не везде она нужна. Сколько раз было, что мне надо ловить именно событие, а не состояние. И в итоге приходится извращаться и отслеживать какую-нибудь смену статуса видимости для показа модалки.
Селекторы на Reselect — лишний слой. Возник из-за бардака в структуре состояния. Имеем дело с "состоянием приложения", а не базой данных. Состояние нужно быстро, просто напрямую использовать без всяких трансформаций и заметаний следов к источнику. PS Саги для извращения логики. :)
Это ведь общая система, как СУБД
Ой, а вот это мне совсем не по душе. Вы в случае СУБД что, SQL-запросы привыкли вызывать прямо из Presentation-слоя?
Так в том-то и дело, что из презентационного слоя неправильно напрямую с базой работать. Обычно делается отдельное API. И вот тут таким API c выборками для чтения являются селекторы, а для изменения — экшны. Но почему-то экшны входят в состав Redux, а селекторы — нет.
Я правильно понимаю, что селекторы возникают из-за сложной структуры вашего стейта? Сложная структура имеет тенденцию к частому пересмотру и изменению в будущем. При использовании запросов из презентационного слоя, которые должны полагаться на знание этой струкуры, вам необходимо будет модифицировать ваши компоненты при каждом изменении организации стейта. Различные уровни между слоем презентации и слоем данных как раз должны изолировать визуальную часть от необходимости такого знания.
Не совсем понимаю, как наличие селекторов — слоя, специально добавленного для абстрагирования от внутренней структуры стейта, приводит к модификации компонентов при изменении организации стейта. Структура стейта как раз не особо сложная и всю сложность скрывают в себе селекторы, как это и рекомендуют.
Стейт у нас используется во-первых как кэш зафетченных данных от API, почти без обработок. На этот кеш смотрят селекторы, с которыми не ведётся работа из UI. Они используются в других селекторах, где при необходимости данные уже обрабатываются, аггрегируются, добавляются отдельные селекторы для фильтрации, калькулируемые поля. Под каждое поле идёт отдельный селектор, чтобы изменение, скажем, имени юзера, не приводило к ререндеру всего, что связано с этим юзером, а только тех компонентов, где присутствует имя. Ещё в стейте есть, конечно, чисто UI-ные данные со своими селекторами, типа селектора для показа какой-то глобальной панели или модалки.
redux можно приготовить без boilerplate-кода, без middleware (thunk, saga..) и вообще без кучи типов действий. Останется простой менеджер состояний без ваших минусов. То что вы сами изобретете, отказавшись от redux.
Вообще, конечно, я знаю как.
А мне, кстати, любопытно
Как вообще этот трэш смог стать таким популярным?
Да понятно как. На "курсах по хэтээмелю" Реакт подается именно в связке с Редуксом. Это уже позднее, при наличии самостоятельного мышления, человек может осмотреться по сторонам. Ну а штампованые на курсах джуны, к сожалению, не могут.
На самом деле еще проще: на протяжении как минимум пары лет к реакту не было ничего лучше. МобХ только заводился и был очень рискованным выбором, Flux был еще даже хуже редакса… вот и взлетело. Достаточно находиться в правильном месте в правильный момент времени.
А что сейчас учат — так это не потому, что прям всех купили и продали. Это потому, что уже есть очень много фронтов с редаксом внутри, которые естественно никто не будет так просто переписывать только потому, что появились лучшие альтернативы.
уже есть очень много фронтов с редаксом внутри, которые естественно никто не будет так просто переписывать
Когда работал в аутсорсинге — два раза кидали на крупные проекты, где буквально была одна долгосрочная основная задача — переписывание с redux на mobx..)) ибо дальше видимо было невозможно с этим жить и развивать)
Жизненно. Как то проходил на известном иностранном ресурсе курс курс по реакту, там тоже редукс потом добавляли. Выглядело это мянко говоря нелепо, куча бойлерплейта ради простейших задач.
Правда, у меня был бэкграунд (много C, солидный проект на C++, поделки на Python). Но вроде и без него должно быть видно, что редукс нужен только в очень сложных или специфичных проектах
Вы видимо не разобрались или не умеете его готовить. UDF архитектура - одна из самых слабосвязанных и легкотестируемых архитектур.
Подобное супер объяснение, но уже про коллбеки видел лишь однажды в толстенном учебнике по VBA для Excel. Респект таким, кто может на пальцах рассказывать сложные вещи просто.
Но в Angular такой проблемы нет, Injectable-сервисы прекрасно справляются с этой задачей.Injectable сервисы нужны для того, чтобы шарить состояние между деревом компонентов. Эти сервисы никак не отвечают за оповещение компонентов об изменениях. За это отвечает Zone.js — самая глупая система оповещения изменений, которую только можно найти в современных фреймворках. Почему глупая? Потому что это monkey patching и потому что обновления компонентов не точечные. Умная система оповещения изменений знает какой компонент от какого значения зависит и обновляет компоненты точечно (Mobx / Vue).
Эти сервисы никак не отвечают за оповещение компонентов об изменениях.
Сервисы шарят, а Observable, Subject — оповещают об изменениях
За это отвечает Zone.js
Вы ошибаетесь. Zone.js вообще не для этого.
Концептуально это execution context только для для асинхронного кода и соответсвующего runtime, а это совсем другая история.
Более того, он вообще опционален и приложения можно строить вообще без него.
Умная система оповещения с точечными изменениями фреймворку вполне по силам.
Я думаю, никогда. Всё-таки React официально позиционирует себя как библиотеку, а не как фреймворк
За что я не люблю Redux