децентрализованность, декларативность, эффективность. требовался инструмент, позволяющий управлять данными в сложных приложениях без опасности раздуть монолитный центральный стор, с явным control flow, нормальной типизацией и емким апи
— сторы для приложения должны быть лёгкими, насколько это возможно — не должна пугать мысль о том, что нужно добавить ещё один стор для конкретных нужд
— сторы должны свободно совмещаться — идея в том, что данные, которые потребуются приложению, можно распределить статически, заранее показав как данные будут преобразоваться во время работы приложения
— принцип работы должен by design исключать необходимость в reselect, оповещая об изменениях только тех, кому они необходимы. это позволяет не задумываться о том, что у тебя будет триггериться всё приложение если ты захочешь вынести  стейт модалки из реакта. по совместительству это означает что приложения избавлены от проблем с перфомансом, возникшим у react-redux при переходе на контекст
— возможность, место, и способ вынести любую требуемую бизнес-логику из view, максимально упрощая компоненты
— независимость от спорных концепций — никаких декораторов, никаких зависимостей от реакта/rxjs либо необходимости юзать классы или прокси — ничего из этого не требуется для управления состоянием приложения и поэтому апи библиотеки использует только функции и простые js объекты
— предсказуемость апи. небольшое число базовых принципов переиспользуются в различных кейсах, снижая нагрузку на юзера и повышая узнаваемость. зная как работает .watch  в эвентах, можно догадаться, что делает функция .watch у стора
— приложение строится из комбинации базовых элементов и возможности строить новые.
нет никакого смысла стремиться выдать всё за стрим, за редьюсер или за обсервабл, в приложении требуются они все, и библиотека предлагает решение чтобы управлять структурой данных, а не скрывать её

чекай

ну ладно убедил:
*удаляет редакс*

Хм
Можно пример пожалуйста как с Effector реализуется работа с веб-сокетами (подписка на событие, триггер событий)
И как в fetch пробрасывать хидеры

Я сейчас использую redux + redux-observable
В dependencies epic-ов пробрасываются объекты для работы с сокетами, fetch, и при тестировании я мокаю эти объекты

тут у каждого свои подходы

Бесит в редакс что даже с reduxjs/toolkit ты как бы делаешь стор модульным, но все равно селекторы зависят от глобального стейта и получается какаха )

например, я на уровне хендлера ставлю хедеры, а не эффекта

тут меня сокеты с json-rpc

У меня вот такой интерфейс объекта работы с сокетами, внутри RxJS используется для создания вебсокета

В случае Effector я так понимаю надо мне создать стор, который будет хранить в себе объект websocket ?

Мне надо что бы эффекты реагировали на переподключение вебсокета и перезапускались

написал в голове новую версию на sample + guard (поддерживает и массив и объект)

Кстати, а вот если на эффекторе сделать чат, а чатов у тебя много. Есть ли какие то практики чтобы было несколько инстансов и у каждого свой стор, эвенты итп?

На ум приходит только обернуть все в функцию которая будет каждый провайдить новые сторы и пр. Но мало ли)

Ещё есть вариант что один стор для всех чатов, тоже вполне рабочий наверно вариант

есть ещё вариант, но о нём пока рано говорить

Ну заинтриговал так заинтриговал xDDD

Templates

Ну я думаю, Руслан их именно и имел ввиду :)