У меня есть стор "параметров", есть стор "результатов"

В самом простом случае всё ок - меняю параметры, форваржу изменения в эффект гета результатов с АПИ.

Дальше появляется необходимость параметры отображать в УРЛЕ

Ок, делаю форвард с стора параметров в эффект который меняет УРЛ через хистори апи

Далее возникает вопрос - стор нужно заполнить из УРЛА, если юзер зашёл по урлу в приложение

Тут уже просто так нельзя взять и заполнить по событию или ещё как - потому что получится цикличность

Ввожу $pageMounted, на событие pageMounted вешаю эффект "перезаполнить стор из урла"

Заодно на pageUnmounted вешаю ресет обоих сторов

Форвард изменений урла по изменениям стора гаржу pageMounted.

Ещё тонкость - при навигации через браузерные стрелки не вызывается событие маунта и анмаунта компонента (для роутера это всё один локейшен в рамках разных search, матч не меняется, ререндера нет), поэтому подписываюсь на window.popstate и по нему тоже делаю рефилл стора из урла.

И вроде даже всё ок (хотя чую, что творю дичь и уже плохо помню кто что куда в какой момент что форвардит, гардит и семплит), но появляется проблема - когда я делаю pageUnmounted до того, как $pageUnmounted становится false, срабатывает ресет на $parameters, гард это видит и без задней мысли дёргает рефетч $results, потому что гард на $pageMounted ещё не встал в false к этому моменту.Получается, что при анмаунте страницы происходит лишний запрос.

Я 100% уверен что что-то делаю совсем не так, но хз что, если честно, так что забей )

const a = state => state + 1

store.on(increment, a)

store.off(a)

Так?

аа, понял про что ты, нет, нужно отписывать не функции, а сами юниты, store.off(increment)

аааaaa

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

Думаю, что стоит отказаться от этого гарда и дёргать рефетч явно когда нужно

зависит от рантайма

если что-то не получается и есть возможность повысить очевидность кода, то лучше ей воспользоваться) да, вызывать явно действительно лучше

А если у стора в какой то момент не станет подписок и не будет на него ссылок то gc снесет его?

третья фаза))

https://t.me/effector_ru/129496

ну да

код бы

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

1 пока

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

то есть если вкратце, то если чувствуешь, что получается слишком сложно — упрощай: императивный код легче писать но сложнее расширять в дальнейшем, поэтому всегда есть место для баланса

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

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

ааа, стоп, у тебя гард висит по pageMounted? это не совсем правильно, лучше заменить эту пару эвентов на createGate+useGate: он создаёт эти два эвента самостоятельно и при этом даёт и статус маунта в виде стора

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

Про гейт я вообще ничего не понял из доков, если честно.