DD
обновляй в сабскрайбе
Size: a a a
2020 August 18
OP
обновляй в сабскрайбе
Точно) Спасибо большое)
DD
Oleg Pavl
Точно) Спасибо большое)
не за что ))
AO
Олександр Савуловський
Привет, всем. Помогите с организацией кода.
Задача: при изменении календаря получать новые данные по сотруднику.
Сделал сервис синглтон.
В нем написал:
private userPermissionSubject = new BehaviorSubject<Array<string>>({} as Array<string>);
userPermission = this.userPermissionSubject.asObservable().pipe(distinctUntilChanged());
setDateCalendar() {
this.api.post(q)
.pipe(
filter(data => data.code == 200),
map(data => data.response)
)
.subscribe(data => this.userPermissionSubject.next(data));
}
Потом буду подписываться на userPermission в нужных мне компонентах. Читал, что в сервисах, лучше не подписываться, тем более если синглтон. В связи чем и вопрос. Буду благодарен за любую подсказку.
Задача: при изменении календаря получать новые данные по сотруднику.
Сделал сервис синглтон.
В нем написал:
private userPermissionSubject = new BehaviorSubject<Array<string>>({} as Array<string>);
userPermission = this.userPermissionSubject.asObservable().pipe(distinctUntilChanged());
setDateCalendar() {
this.api.post(q)
.pipe(
filter(data => data.code == 200),
map(data => data.response)
)
.subscribe(data => this.userPermissionSubject.next(data));
}
Потом буду подписываться на userPermission в нужных мне компонентах. Читал, что в сервисах, лучше не подписываться, тем более если синглтон. В связи чем и вопрос. Буду благодарен за любую подсказку.
Это основа push-based систем, где Сервис предоставляет реактивный (Observable) проперти.
Возможная проблема в коде, как он сейчас написан, это race conditions.
Когда вызывается setDateCalendar()? Если юзер часто меняет то, что тригерит setDataCalendar может случится, что результат первого запроса прийдет позже результата второго запроса, и перепишет эти userPermissions (возможно на устаревшие).
Может это не проблема в данном примере, но об этом надо задумываться.
Именно поэтому и создан ComponentStore:
- во-первых он сам создает ReplaySubject внутри и описывает, когда компонент дестроится
- во-вторых, setDateCalendar() будет еффектом, в котором можно организовать эти race conditions и выбрать правильный оператор для этого - один из switchMap, mergeMap, exhaustMap или concatMap.
и т.д. :)
А так, подписываться в методе - это не страшно. Я бы добавил еще
Возможная проблема в коде, как он сейчас написан, это race conditions.
Когда вызывается setDateCalendar()? Если юзер часто меняет то, что тригерит setDataCalendar может случится, что результат первого запроса прийдет позже результата второго запроса, и перепишет эти userPermissions (возможно на устаревшие).
Может это не проблема в данном примере, но об этом надо задумываться.
Именно поэтому и создан ComponentStore:
- во-первых он сам создает ReplaySubject внутри и описывает, когда компонент дестроится
- во-вторых, setDateCalendar() будет еффектом, в котором можно организовать эти race conditions и выбрать правильный оператор для этого - один из switchMap, mergeMap, exhaustMap или concatMap.
и т.д. :)
А так, подписываться в методе - это не страшно. Я бы добавил еще
take(1) на всякий случай после map.ОС
Alex Okrushko
Это основа push-based систем, где Сервис предоставляет реактивный (Observable) проперти.
Возможная проблема в коде, как он сейчас написан, это race conditions.
Когда вызывается setDateCalendar()? Если юзер часто меняет то, что тригерит setDataCalendar может случится, что результат первого запроса прийдет позже результата второго запроса, и перепишет эти userPermissions (возможно на устаревшие).
Может это не проблема в данном примере, но об этом надо задумываться.
Именно поэтому и создан ComponentStore:
- во-первых он сам создает ReplaySubject внутри и описывает, когда компонент дестроится
- во-вторых, setDateCalendar() будет еффектом, в котором можно организовать эти race conditions и выбрать правильный оператор для этого - один из switchMap, mergeMap, exhaustMap или concatMap.
и т.д. :)
А так, подписываться в методе - это не страшно. Я бы добавил еще
Возможная проблема в коде, как он сейчас написан, это race conditions.
Когда вызывается setDateCalendar()? Если юзер часто меняет то, что тригерит setDataCalendar может случится, что результат первого запроса прийдет позже результата второго запроса, и перепишет эти userPermissions (возможно на устаревшие).
Может это не проблема в данном примере, но об этом надо задумываться.
Именно поэтому и создан ComponentStore:
- во-первых он сам создает ReplaySubject внутри и описывает, когда компонент дестроится
- во-вторых, setDateCalendar() будет еффектом, в котором можно организовать эти race conditions и выбрать правильный оператор для этого - один из switchMap, mergeMap, exhaustMap или concatMap.
и т.д. :)
А так, подписываться в методе - это не страшно. Я бы добавил еще
take(1) на всякий случай после map.Огромное спасибо!
ОС
Alex Okrushko
Это основа push-based систем, где Сервис предоставляет реактивный (Observable) проперти.
Возможная проблема в коде, как он сейчас написан, это race conditions.
Когда вызывается setDateCalendar()? Если юзер часто меняет то, что тригерит setDataCalendar может случится, что результат первого запроса прийдет позже результата второго запроса, и перепишет эти userPermissions (возможно на устаревшие).
Может это не проблема в данном примере, но об этом надо задумываться.
Именно поэтому и создан ComponentStore:
- во-первых он сам создает ReplaySubject внутри и описывает, когда компонент дестроится
- во-вторых, setDateCalendar() будет еффектом, в котором можно организовать эти race conditions и выбрать правильный оператор для этого - один из switchMap, mergeMap, exhaustMap или concatMap.
и т.д. :)
А так, подписываться в методе - это не страшно. Я бы добавил еще
Возможная проблема в коде, как он сейчас написан, это race conditions.
Когда вызывается setDateCalendar()? Если юзер часто меняет то, что тригерит setDataCalendar может случится, что результат первого запроса прийдет позже результата второго запроса, и перепишет эти userPermissions (возможно на устаревшие).
Может это не проблема в данном примере, но об этом надо задумываться.
Именно поэтому и создан ComponentStore:
- во-первых он сам создает ReplaySubject внутри и описывает, когда компонент дестроится
- во-вторых, setDateCalendar() будет еффектом, в котором можно организовать эти race conditions и выбрать правильный оператор для этого - один из switchMap, mergeMap, exhaustMap или concatMap.
и т.д. :)
А так, подписываться в методе - это не страшно. Я бы добавил еще
take(1) на всякий случай после map.Но этот метод написан в сервисе, который рут или не страшно?Как я понимаю останутся висеть подписки
AO
Олександр Савуловський
Но этот метод написан в сервисе, который рут или не страшно?Как я понимаю останутся висеть подписки
не страшно.
Кстати, я во здесь затронул тему indirections (потому что push-based такова): https://ngrx.io/guide/component-store/comparison#benefits-and-trade-offs
и там же делал ссылку на статью Томаса, который хорошо описал push-based: https://medium.com/@thomasburlesonIA/push-based-architectures-with-rxjs-81b327d7c32d
Кстати, я во здесь затронул тему indirections (потому что push-based такова): https://ngrx.io/guide/component-store/comparison#benefits-and-trade-offs
и там же делал ссылку на статью Томаса, который хорошо описал push-based: https://medium.com/@thomasburlesonIA/push-based-architectures-with-rxjs-81b327d7c32d
AO
Олександр Савуловський
Но этот метод написан в сервисе, который рут или не страшно?Как я понимаю останутся висеть подписки
Не останутся - они закрываются
ОС
Alex Okrushko
не страшно.
Кстати, я во здесь затронул тему indirections (потому что push-based такова): https://ngrx.io/guide/component-store/comparison#benefits-and-trade-offs
и там же делал ссылку на статью Томаса, который хорошо описал push-based: https://medium.com/@thomasburlesonIA/push-based-architectures-with-rxjs-81b327d7c32d
Кстати, я во здесь затронул тему indirections (потому что push-based такова): https://ngrx.io/guide/component-store/comparison#benefits-and-trade-offs
и там же делал ссылку на статью Томаса, который хорошо описал push-based: https://medium.com/@thomasburlesonIA/push-based-architectures-with-rxjs-81b327d7c32d
Спасибо!
AS
гайз, вопрос по formly
есть ли простой способ очистить значение инпута при его сокрытии (через hideExpression)
что я хочу - иметь 2 инпута (А и В).
видимость (и value) инпута В обнулить при определенном значении инпута А
просто спрятать - ок, без вопросов. А вот с очисткой - ну такое. Когда играешься в примере в доке - значение остаётся. Я пошуршал доку, погуглил, поиграл, есть идеи
- либо сделать кастомный инпут (но это будет слишком жирно, т.к. для каждого предподагаемого любого инпута нуно будет делать.. дополнительный?!)
- либо заюзать схематики. Конкретно - schema_dependencies (https://formly.dev/examples/advanced/json-schema). Не особо хочется, т.к. пошло усложнение
- либо с валидацей чёт мутить. Но этого совершенно не хочется
- https://github.com/ngx-formly/ngx-formly/issues/620#issuecomment-355535192 - видел, но тоже не хочется
есть какой-то более простой способ? может я тупо что-то не увидел в доке?
есть ли простой способ очистить значение инпута при его сокрытии (через hideExpression)
что я хочу - иметь 2 инпута (А и В).
видимость (и value) инпута В обнулить при определенном значении инпута А
просто спрятать - ок, без вопросов. А вот с очисткой - ну такое. Когда играешься в примере в доке - значение остаётся. Я пошуршал доку, погуглил, поиграл, есть идеи
- либо сделать кастомный инпут (но это будет слишком жирно, т.к. для каждого предподагаемого любого инпута нуно будет делать.. дополнительный?!)
- либо заюзать схематики. Конкретно - schema_dependencies (https://formly.dev/examples/advanced/json-schema). Не особо хочется, т.к. пошло усложнение
- либо с валидацей чёт мутить. Но этого совершенно не хочется
- https://github.com/ngx-formly/ngx-formly/issues/620#issuecomment-355535192 - видел, но тоже не хочется
есть какой-то более простой способ? может я тупо что-то не увидел в доке?
N
гайз, вопрос по formly
есть ли простой способ очистить значение инпута при его сокрытии (через hideExpression)
что я хочу - иметь 2 инпута (А и В).
видимость (и value) инпута В обнулить при определенном значении инпута А
просто спрятать - ок, без вопросов. А вот с очисткой - ну такое. Когда играешься в примере в доке - значение остаётся. Я пошуршал доку, погуглил, поиграл, есть идеи
- либо сделать кастомный инпут (но это будет слишком жирно, т.к. для каждого предподагаемого любого инпута нуно будет делать.. дополнительный?!)
- либо заюзать схематики. Конкретно - schema_dependencies (https://formly.dev/examples/advanced/json-schema). Не особо хочется, т.к. пошло усложнение
- либо с валидацей чёт мутить. Но этого совершенно не хочется
- https://github.com/ngx-formly/ngx-formly/issues/620#issuecomment-355535192 - видел, но тоже не хочется
есть какой-то более простой способ? может я тупо что-то не увидел в доке?
есть ли простой способ очистить значение инпута при его сокрытии (через hideExpression)
что я хочу - иметь 2 инпута (А и В).
видимость (и value) инпута В обнулить при определенном значении инпута А
просто спрятать - ок, без вопросов. А вот с очисткой - ну такое. Когда играешься в примере в доке - значение остаётся. Я пошуршал доку, погуглил, поиграл, есть идеи
- либо сделать кастомный инпут (но это будет слишком жирно, т.к. для каждого предподагаемого любого инпута нуно будет делать.. дополнительный?!)
- либо заюзать схематики. Конкретно - schema_dependencies (https://formly.dev/examples/advanced/json-schema). Не особо хочется, т.к. пошло усложнение
- либо с валидацей чёт мутить. Но этого совершенно не хочется
- https://github.com/ngx-formly/ngx-formly/issues/620#issuecomment-355535192 - видел, но тоже не хочется
есть какой-то более простой способ? может я тупо что-то не увидел в доке?
M
а кто-то пользуется в энтерпрайзе UI либами?
напр., bootstrap/material/primeng/kendo
напр., bootstrap/material/primeng/kendo
2020 August 19
DG
а кто-то пользуется в энтерпрайзе UI либами?
напр., bootstrap/material/primeng/kendo
напр., bootstrap/material/primeng/kendo
Думаю все)
AS
а кто-то пользуется в энтерпрайзе UI либами?
напр., bootstrap/material/primeng/kendo
напр., bootstrap/material/primeng/kendo
Материал, ионик
M
Думаю все)
почему?
мы - нет
я думал, дизайнеры не пользуются никакими либами
мы - нет
я думал, дизайнеры не пользуются никакими либами
E
почему?
мы - нет
я думал, дизайнеры не пользуются никакими либами
мы - нет
я думал, дизайнеры не пользуются никакими либами
Ещё как , особенно когда нужно "на вчера" показать функциональный прототип
SS
почему?
мы - нет
я думал, дизайнеры не пользуются никакими либами
мы - нет
я думал, дизайнеры не пользуются никакими либами
Я на різних проектах стикався з primeng, material, materialize, kendoui.
І як досвід написання своїх компонентів? На матеріал СДК пишете чи зовсім з нуля?
І як досвід написання своїх компонентів? На матеріал СДК пишете чи зовсім з нуля?
DМ
почему?
мы - нет
я думал, дизайнеры не пользуются никакими либами
мы - нет
я думал, дизайнеры не пользуются никакими либами
некоторые дизайнеры перед тем как что-то делать спрашивают пожелания девов, как было в моем случае. пришли к одному общему что будет наресовано +- как табличка с материалов
I
некоторые дизайнеры перед тем как что-то делать спрашивают пожелания девов, как было в моем случае. пришли к одному общему что будет наресовано +- как табличка с материалов
это так классно, когда спрашивают, а не когда делают как видят и потом приходится компонент перепиливать чтоб кнопку влепить
N
всем привет. к себе в комманду ищем разработчиков уровня мидл/синьйор, проект практически с нуля, angular, nx, все дела, продукт, компания на рынке 13 лет, работа удаленка/офис(шулявка) 50/50