ДМ
выходит, что это и не плюс, если часть логики получения/хранения данных ложиться на компоненты, а часть на стейт, часть еще куда-то вынесена
Size: a a a
2020 May 25
DM
ну мне кажется с 2015 года или когда там редакс вышел
DM
люди потихоньку поняли что этот единый механизм брехня
BK
подскажите что нужно сделать , чтобы собитие клик работало ? Отрабатывает только change
DM
люди потихоньку поняли что этот единый механизм брехня
а использовать технологию по её прямому назначению — менеджменту глобального стейта, никакого зла не несёт
IF
подскажите что нужно сделать , чтобы собитие клик работало ? Отрабатывает только change
Тебе надо через change открывать свой календарь. чекать велью выбранного опшена
ДМ
а использовать технологию по её прямому назначению — менеджменту глобального стейта, никакого зла не несёт
может быть, но не проще тогда для таких узких кейсов использовать сервисы? а не тащить монстров вроде ngrx, редаксов и тд?
ДМ
ну я про кейс автора
ДМ
просто не понятно, если часть стейта валяется и лежит в глобал сторе, а часть вынесена в сервисы, то тогда чем это отличается от обычного хаоса при "неправильной" архитектуре с которой борется ngrx/redux?
M
Всем привет, наткнулась на статью на хабре о том, как лучше отписываться от изменения Observable (https://habr.com/ru/company/ruvds/blog/503312/?utm_source=vk&utm_medium=social&utm_campaign=kak-vyzvat-utechku-pamyati-v-angular-pril). Пишут, что лучшая практика - дополнительный Subject и takeUntil
Так действительно правильно делать? Или простой и понятный .unsubscribe() будет все-таки лучше?
Так действительно правильно делать? Или простой и понятный .unsubscribe() будет все-таки лучше?
AS
Всем привет, наткнулась на статью на хабре о том, как лучше отписываться от изменения Observable (https://habr.com/ru/company/ruvds/blog/503312/?utm_source=vk&utm_medium=social&utm_campaign=kak-vyzvat-utechku-pamyati-v-angular-pril). Пишут, что лучшая практика - дополнительный Subject и takeUntil
Так действительно правильно делать? Или простой и понятный .unsubscribe() будет все-таки лучше?
Так действительно правильно делать? Или простой и понятный .unsubscribe() будет все-таки лучше?
соглашусь.
всмысле unsubscribe лучше, чем сабжект.
всмысле unsubscribe лучше, чем сабжект.
BK
Тебе надо через change открывать свой календарь. чекать велью выбранного опшена
благодарю,сработало
IF
Всем привет, наткнулась на статью на хабре о том, как лучше отписываться от изменения Observable (https://habr.com/ru/company/ruvds/blog/503312/?utm_source=vk&utm_medium=social&utm_campaign=kak-vyzvat-utechku-pamyati-v-angular-pril). Пишут, что лучшая практика - дополнительный Subject и takeUntil
Так действительно правильно делать? Или простой и понятный .unsubscribe() будет все-таки лучше?
Так действительно правильно делать? Или простой и понятный .unsubscribe() будет все-таки лучше?
Да, так все и делают
DM
что то не совсем я понял.
Я же спросил, получится перейти назад, не вводя состояние? можно ли воспользоваться старым состояниям компонента, или нет?
Допустим я был на:
там было какое то состояние. Потом я перешел на
а потом хочу вернуться на
так вот это будет создан новый компонент. А можно ли сделать так, чтобы был закеширован старый, и именно он показывался?
Я же спросил, получится перейти назад, не вводя состояние? можно ли воспользоваться старым состояниям компонента, или нет?
Допустим я был на:
/postsтам было какое то состояние. Потом я перешел на
/posts/3а потом хочу вернуться на
/postsтак вот это будет создан новый компонент. А можно ли сделать так, чтобы был закеширован старый, и именно он показывался?
ну конкретно по такому кейсу глобальные стейт менеджеры удобны, только по-хорошему я бы параметры страницы posts всё равно в квери вынес. А в глобальном стейт менеджере чисто данные кешировал
Если у него сейчас нет никакого стейт менеджера и проект ток начинается, и подобных случаев будет не один, то чёб не взять. Что-то простое а не с миллионами фич и логики как нгрх
Если у него сейчас нет никакого стейт менеджера и проект ток начинается, и подобных случаев будет не один, то чёб не взять. Что-то простое а не с миллионами фич и логики как нгрх
DM
там же в posts скорее всего пагинация, и по сути можно много и просто накешировать.
Работать через BehaviorSubject с подобным объёмом не оч комфортно честно
Работать через BehaviorSubject с подобным объёмом не оч комфортно честно
B
ну конкретно по такому кейсу глобальные стейт менеджеры удобны, только по-хорошему я бы параметры страницы posts всё равно в квери вынес. А в глобальном стейт менеджере чисто данные кешировал
Если у него сейчас нет никакого стейт менеджера и проект ток начинается, и подобных случаев будет не один, то чёб не взять. Что-то простое а не с миллионами фич и логики как нгрх
Если у него сейчас нет никакого стейт менеджера и проект ток начинается, и подобных случаев будет не один, то чёб не взять. Что-то простое а не с миллионами фич и логики как нгрх
в квери не пойдет, так как есть пагинация + фильтр большой(который может становится больше в дальнейшем)
E
там же в posts скорее всего пагинация, и по сути можно много и просто накешировать.
Работать через BehaviorSubject с подобным объёмом не оч комфортно честно
Работать через BehaviorSubject с подобным объёмом не оч комфортно честно
достаточно простенькую обвязку написать, не надо для этого тащить стейтменеджер
DM
в квери не пойдет, так как есть пагинация + фильтр большой(который может становится больше в дальнейшем)
ну и сами посты ты хочешь тож кешировать как я понимаю?
DM
достаточно простенькую обвязку написать, не надо для этого тащить стейтменеджер
есть на 500 байт стейтменеджеры
B
ну и сами посты ты хочешь тож кешировать как я понимаю?
нет