АП
у ангуляра это было в примере сортируемой таблички с пагинатором. они тупо брали обычное свойство и спредили его в поток. я тогда офигел с того что они это делают по любому управляющему сигналу
Size: a a a
2021 April 03
АП
такой строчки в том stackblitz нету
121
АП
113 получается
M
Переслано от Maksim
у тебя, каждый раз когда в onCommand подается новое значение, происходит новое создание стора через Object.values(store)
АП
да, потому что в of() нельзя сделать next(). какие варианты?
первое что приходит на ум storeSubject
первое что приходит на ум storeSubject
M
возвращаемся к статье. "Для удержания потока можно применить Subject"
АП
возвращаемся к статье. "Для удержания потока можно применить Subject"
вот. можно. а нужно?
это что-то даст кроме того что теперь это будет другой обьект, на который можно подписаться и мы будем свитчмапится не на новый поток а на существующий?
это что-то даст кроме того что теперь это будет другой обьект, на который можно подписаться и мы будем свитчмапится не на новый поток а на существующий?
M
а почему не нужно?
АП
извечный вопрос между что лучше "постоянная переменная или создал-снес"
M
вот. можно. а нужно?
это что-то даст кроме того что теперь это будет другой обьект, на который можно подписаться и мы будем свитчмапится не на новый поток а на существующий?
это что-то даст кроме того что теперь это будет другой обьект, на который можно подписаться и мы будем свитчмапится не на новый поток а на существующий?
это даст решение твоего третьего вопроса: "каждый раз считывается заново. учитывая асинхронку и возможные приколы типа "3 раза нажали действие" - он может считать и вернуть лютую чушь. значит надо subject?"
АП
ну само действие next() будет писать его в сабжект который позволит отследить историю как менялось, но при этом создаст вечный обьект в памяти... в принципе и да и нет. считаешь что да?
MA
Мне кажется, стоит ответить на вопрос, зачем вообще нужен стор-свалка по принципу redux. Гораздо проще действовать по принципу один сабжект - одно атомарное состояние. Объект или коллекция какая-нибудь. А загружаемые с сервера данные нет смысла класть в стор, это просто поток. Он может зависеть от состояний из сабжектов, агрегировать результат нескольких запросов, всё что вам нужно.
АП
Мне кажется, стоит ответить на вопрос, зачем вообще нужен стор-свалка по принципу redux. Гораздо проще действовать по принципу один сабжект - одно атомарное состояние. Объект или коллекция какая-нибудь. А загружаемые с сервера данные нет смысла класть в стор, это просто поток. Он может зависеть от состояний из сабжектов, агрегировать результат нескольких запросов, всё что вам нужно.
вот это я и пытаюсь понять.
у меня же не горячий поток с сервером. а только когда команда приходит я его "пинаю" и получаю свежую пачку. при этом отталкиваться от сервера будучи клиентом - прекарсная мысль если человек едет в поезде
у меня же не горячий поток с сервером. а только когда команда приходит я его "пинаю" и получаю свежую пачку. при этом отталкиваться от сервера будучи клиентом - прекарсная мысль если человек едет в поезде
АП
если он получил новые данные - они должны таки куда-то попасть. если не получил - похер пляшем с тем что есть
АП
Мне кажется, стоит ответить на вопрос, зачем вообще нужен стор-свалка по принципу redux. Гораздо проще действовать по принципу один сабжект - одно атомарное состояние. Объект или коллекция какая-нибудь. А загружаемые с сервера данные нет смысла класть в стор, это просто поток. Он может зависеть от состояний из сабжектов, агрегировать результат нескольких запросов, всё что вам нужно.
про один сабжект - одно атомарное ничего не понял какое еще атомарное я ж не биолог и не физик
АП
к вопросу "нет смысла класть в стор это просто поток" - тоже идею не понял. холодный поток сам по себе не актуализируется
M
ну само действие next() будет писать его в сабжект который позволит отследить историю как менялось, но при этом создаст вечный обьект в памяти... в принципе и да и нет. считаешь что да?
объект вечный, да не вечный. В сторах специально используют refCount чтобы уничтожать данные и очищать память когда подписчиков нет, о чем говорится в статье
АП
объект вечный, да не вечный. В сторах специально используют refCount чтобы уничтожать данные и очищать память когда подписчиков нет, о чем говорится в статье
да, это если я сделаю .pipe(shareReplay()) я гарантирую что каждый кто подпишется получит последнюю копию.
встает вопрос - а новую он как будет получать?
встает вопрос - а новую он как будет получать?
M
Мне кажется, стоит ответить на вопрос, зачем вообще нужен стор-свалка по принципу redux. Гораздо проще действовать по принципу один сабжект - одно атомарное состояние. Объект или коллекция какая-нибудь. А загружаемые с сервера данные нет смысла класть в стор, это просто поток. Он может зависеть от состояний из сабжектов, агрегировать результат нескольких запросов, всё что вам нужно.
я тоже против стор свалок, но тут в другом дело. Человек считает subject костылем и не понимает когда какие методы/операторы нужно использовать, и учится на примере стора