Ты рассматриваешь стор как единое состояние приложения или как примитив, который отвечает за конкретную часть глобального стейта?

один из кейсов который меня волнует, это восстановление процессов логики, при запуске приложения из дампа

скорее как единое состояние приложение чтобы можно было именно от стора отрендерить приложение и получить нужный вид чтобы хоть тесты всего приложения гонять на этом

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

Я допускаю. Но я вторую вещь так и не увидел на примерах

я рассказываю концепцию разделения приложения на три части если буду показывать свои попытки реализовать апи, ты скажешь что идея говно и забьешь, даже не попытавшись понять всю концепцию

Любой псевдокод, который покажет, как компонент берет данные из стора и как логика взаимодействует со стором

Так, что при изменении одного из трех, не нужно менять все остальное

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

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

да

Что-то типа такого? function() { incrementI() if (getI() > 5) { alert(); } }

Что-то типа такого? function() { incrementI() if (getI() > 5) { alert(); } }

вот этот псевдокод ровно то, что я хочу

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

У тебя createStore и является этим интерфейсом. Да, может быть апи и кривоватое. Я ещё не полностью его переварил, но концепция как раз то, что ты описываешь.

У тебя createStore и является этим интерфейсом. Да, может быть апи и кривоватое. Я ещё не полностью его переварил, но концепция как раз то, что ты описываешь.

но я не могу в этом апи делать условный getCounter() (не увидел по крайней мере) и делать условный setCounter(value) с возможностью подмены стора, на другой по структуре, но с таким же слоем доступа

но я не могу в этом апи делать условный getCounter() (не увидел по крайней мере) и делать условный setCounter(value) с возможностью подмены стора, на другой по структуре, но с таким же слоем доступа

то есть по факту, заменить effector на redux абсолютно бесшовно

но я не могу в этом апи делать условный getCounter() (не увидел по крайней мере) и делать условный setCounter(value) с возможностью подмены стора, на другой по структуре, но с таким же слоем доступа

Здесь уже провал в абстракции эффектора. Мемчанский отстаивает позицию, что у стора нет локальности.

Здесь уже провал в абстракции эффектора. Мемчанский отстаивает позицию, что у стора нет локальности.

ну вот опять вернулись к фундаментальной конструкции. я не говорю, что это плохо. просто мне не нравится

А если вообще конструировать стор с локальностью, то там пипец какие проблемы с описанием апи.

Если я правильно понял, то 1) Стор пилит методы, которые меняют стор 2) Есть какой-то "компьютед", который, независимо от изменений организации, возвращает всегда стейт одного формата Но в таком случае, здесь даже не один бойлерплейт, а два. Пилить методы на каждый i++ и преобразовывать стейт при каждом изменении структуры стора к одному виду

но я не могу в этом апи делать условный getCounter() (не увидел по крайней мере) и делать условный setCounter(value) с возможностью подмены стора, на другой по структуре, но с таким же слоем доступа

counter.getState()

И придётся завязываться на view-либу, потому что мы с помощью неё строим дерево компонентов.

А это мне оооочень не нравится.

И придётся завязываться на view-либу, потому что мы с помощью неё строим дерево компонентов.

также как react-redux effector-redux

также как react-redux effector-redux

У тебя там нет завязки на view) Ты руками разрешаешь локальность с помощью айдишников)

Я поэтому и хочу пробрасывать key в компонент, чтобы переложить генерацию key на стор, чтобы человеку не прешлось с этой говной возиться.

Если я правильно понял, то 1) Стор пилит методы, которые меняют стор 2) Есть какой-то "компьютед", который, независимо от изменений организации, возвращает всегда стейт одного формата Но в таком случае, здесь даже не один бойлерплейт, а два. Пилить методы на каждый i++ и преобразовывать стейт при каждом изменении структуры стора к одному виду

ты правильно понял. я ищу способы решения этих кейсов, по идее это решаемо через прямую апишку. но опять же как мы все понимаем, такого не будет часто, кейс такого подхода в переиспользуемости стора по всеми приложению, в том числе в тестах и внутри вложенной логики

У тебя там нет завязки на view) Ты руками разрешаешь локальность с помощью айдишников)

вот тут я не понял про айдишники

вот тут я не понял про айдишники

Кейс arr.map(a => <A a={a} />) с локальными сторами у A и <><A/><A/></>

Без этого смысла пилить замену эффектору просто нет.

Кейс arr.map(a => <A a={a} />) с локальными сторами у A и <><A/><A/></>

а, ну тут да, также как в react-redux

а, ну тут да, также как в react-redux

Вот, а я хочу переложить это на стор.

Кейс arr.map(a => <A a={a} />) с локальными сторами у A и <><A/><A/></>

Вот, собственно, единственная проблема эффектора, кек

Вот, а я хочу переложить это на стор.

на либу связку?

Вот, собственно, единственная проблема эффектора, кек

Это единственная и фундаментальная проблема. Для её решения потребуется выкинуть абсолютно всё апи эффектора.

Вот, собственно, единственная проблема эффектора, кек

а ещё то, что я не могу описывать чистый бизнес-кейс

на либу связку?

Да, на биндинги стора к реакту.

Да, на биндинги стора к реакту.

вот тут это уместно, да

Но фишка в том, что стор надо проектировать именно от биндингов, а не наоборот.

Но фишка в том, что стор надо проектировать именно от биндингов, а не наоборот.

такое. запроектировал для реакта, а для других либ юзать не можешь толку то

Это единственная и фундаментальная проблема. Для её решения потребуется выкинуть абсолютно всё апи эффектора.

Это можно решить вне контекста вьюхи, но притягивать к вьюхе геморрно. И дело даже не в том, что ты считаешь проблемой

кстати, как в эффекторе с тестированием логики?

такое. запроектировал для реакта, а для других либ юзать не можешь толку то

Здесь больше не реакт, а те кейсы, которые возникают. Типа двух выше, которые я описал.

Вот, а я хочу переложить это на стор.

а зачем, тогда, нужен будет virtual dom реакта?

И если удасться решить проблему, то сразу решается проблема с ssr.

а зачем, тогда, нужен будет virtual dom реакта?

Не понимаю вопроса. Распиши, пожалуйста.

а зачем, тогда, нужен будет virtual dom реакта?

Не нужен, получается

Ты сделал <A /> То есть создал новый "стейт" Скажем, это форма При нажатии кнопки закрыть, компонент анмаунтится и удаляется запись При нажатии кнопки сохранить, компонент анмаунтится и сохраняется запись А еще, что будут делать компоненты на вложенности? Откуда они будут брать стор? Как они поймут, какой стор брать? Я придумал решение на контекстах, но оно тоже просасывает на сложных кейсах

кстати, как в эффекторе с тестированием логики?

?

Не понимаю вопроса. Распиши, пожалуйста.

Ну я так понимаю качественно реактивные сторы могут предоставлять на столько точечные подписки, что если обновление до view дошло - можно мержить в реальный дом. Но при этом остается проблема со списками, когда аппенд 1 элемента заставляет пересчитать весь список - тут уже весь список в дом дорого класть

Ты сделал <A /> То есть создал новый "стейт" Скажем, это форма При нажатии кнопки закрыть, компонент анмаунтится и удаляется запись При нажатии кнопки сохранить, компонент анмаунтится и сохраняется запись А еще, что будут делать компоненты на вложенности? Откуда они будут брать стор? Как они поймут, какой стор брать? Я придумал решение на контекстах, но оно тоже просасывает на сложных кейсах

Здесь у меня есть решение, но я пока не готов его в народ выносить, так как оно очень многословное и сырое.

Не понимаю вопроса. Распиши, пожалуйста.

Кстати, я уже описывал тут идею. Если разделить список на множество мелких списков и по отдельности за ними следить, то проблема производительности "вставки" списка в дом должна уйти

?

А что тебя интересует? Просто апи настолько простое, что я даже хз, какие проблемы могут быть

Кстати, я уже описывал тут идею. Если разделить список на множество мелких списков и по отдельности за ними следить, то проблема производительности "вставки" списка в дом должна уйти

А, ну это уже пользовательская задача, а не стора или реакта.

А что тебя интересует? Просто апи настолько простое, что я даже хз, какие проблемы могут быть

как протестить кейс с тем же инкрементом и бабблом

А, ну это уже пользовательская задача, а не стора или реакта.

почему это!?

почему это!?

Делай список на основе дерева и рендери его.

а как тестить случай, с эффектами и зависимостями сторов?

почему это!?

Потому что для этой проблемы нет решения без добавления в сам реакт списка на основе деревьев. Тупо енумерабл не даёт тебе апи, который позволит рендерить всё эффективно.

а как тестить случай, с эффектами и зависимостями сторов?

Для тебя импорт интересующих сторов и вызова эффекта устроит с последующей проверкой значений в сторах?)

Для тебя импорт интересующих сторов и вызова эффекта устроит с последующей проверкой значений в сторах?)

так эффект совершит запрос

effect.use(fakeRequest)

effect.use(fakeRequest)

что-то меня в этом смущает, пока не пойму что

а, точно, паралелльные тесты не будут работать

то, что ответ запроса надо возвращать в нем

а, точно, паралелльные тесты не будут работать

всм не будут?

а, точно, паралелльные тесты не будут работать

Почему?

Потому что для этой проблемы нет решения без добавления в сам реакт списка на основе деревьев. Тупо енумерабл не даёт тебе апи, который позволит рендерить всё эффективно.

Да просто map должен быть не массивный а свой, в стиле редуса... Ну не важно. Вопрос в том, что, казалось бы, еще шажок и стейт-менеджера будет достаточно для полной замены реакта. Но, если подумать, у нас просто получается ангуляр =D Но у ангуляра свои проблемы. Какой компромис между этим? Нужна декларативная реактивность. Эффектор мне, все же, кажется не достаточным в этом плане

Почему?

test(‘foo’, async t => { effect.use(stub().returns(2)) // if i call effect() here, what stub would called }) test(‘bar’, async t => { effect.use(stub().returns(3)) })

test(‘foo’, async t => { effect.use(stub().returns(2)) // if i call effect() here, what stub would called }) test(‘bar’, async t => { effect.use(stub().returns(3)) })

Недогоняю.

ERROR: S client not available

test(‘foo’, async t => { effect.use(stub().returns(2)) // if i call effect() here, what stub would called }) test(‘bar’, async t => { effect.use(stub().returns(3)) })

Попахивает говнецом. Если тебе для разных тест кейсов нужен разный stub, то тут даже хз что сказать

Недогоняю.

параллельные тесты запускаются одновременно а effect.use это просто замена содержимого

test(‘foo’, async t => { effect.use(stub().returns(2)) // if i call effect() here, what stub would called }) test(‘bar’, async t => { effect.use(stub().returns(3)) })

effect.use(payload => result)

Да просто map должен быть не массивный а свой, в стиле редуса... Ну не важно. Вопрос в том, что, казалось бы, еще шажок и стейт-менеджера будет достаточно для полной замены реакта. Но, если подумать, у нас просто получается ангуляр =D Но у ангуляра свои проблемы. Какой компромис между этим? Нужна декларативная реактивность. Эффектор мне, все же, кажется не достаточным в этом плане

Ты переоцениваешь людей, которые будут пользоваться стором. Я уверен, что можно написать говно, которое исправит только виртуал дом.

effect.use(payload => result)

так мб понятнее будет

effect(payload)

объявление эффекта статическое и use глобальный. Все из-за того же проблемы с ssr

Попахивает говнецом. Если тебе для разных тест кейсов нужен разный stub, то тут даже хз что сказать

ммм)) ну да тестить же эффект который вернул корректный результат и ошибку не надо

А, вот ещё косяк, да.

так мб понятнее будет

то есть ты не понял, да)

Не думал, кстати, над этим.

я статически заменяю значение в эффекте ОДНОВРЕМЕННО из нескольких тестов

так работают параллельные тесты

ммм)) ну да тестить же эффект который вернул корректный результат и ошибку не надо

че effect.use(payload => fetch('/zalupa')) const res = await effect(payload) expect(res.result).toBe(...) expect(res.error).toBe(...)

че effect.use(payload => fetch('/zalupa')) const res = await effect(payload) expect(res.result).toBe(...) expect(res.error).toBe(...)

чувак

а теперь напиши мне 5-10 таких тестов

и гарантируй что будет всё ок

2 достаточно

а теперь напиши мне 5-10 таких тестов

Запускаешь 10 нод.

Ну чего ты как маленький?)

Запускаешь 10 нод.

“параллельные” да)

и что произойдет? типа до вызова эффекта второй юз прокнет?

и что произойдет? типа до вызова эффекта второй юз прокнет?

да

ну с этим хз. я не гуру тестов

че effect.use(payload => fetch('/zalupa')) const res = await effect(payload) expect(res.result).toBe(...) expect(res.error).toBe(...)

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

и гарантируй что будет всё ок

чет я не вижу проблему в этом кейсе

я вот тоже не понимаю. как в изолированном тесте может прокнуть юз из другого теста

я вот тоже не понимаю. как в изолированном тесте может прокнуть юз из другого теста

Глобальные переменные.

если только какой-нить таймаут

я вот тоже не понимаю. как в изолированном тесте может прокнуть юз из другого теста

ну тебе вызов каждого эффекта нужно мокать строго перед вызовом. Нельзя сначала замокать, а потом вызывать асинхронно

А вообще все норм

ну тебе вызов каждого эффекта нужно мокать строго перед вызовом. Нельзя сначала замокать, а потом вызывать асинхронно

Говно.