DT
Тому що сервіс зберігає данні. Цього не має бути.
а кто сказал что этого не должно быть?
Size: a a a
2021 January 12
SФ
Alex Okrushko
Кеш тоже Injectable class, толькуо @alexchugaev не называет его "сервисом"
Ну под это как раз неплохо подходят Store
DT
Тому що сервіс зберігає данні. Цього не має бути.
контекст приложения не предусматривает универсальный пример под любой вкус
J
Дискусійна тема. Думаю в не великих апках (та і може в великих якщо зберігається певна архітектура в контексті даного проекта) можна спокійно називати statfull сервіс сервісом а не стором і ніхто від того не пострадає 🙂
А взагалі як уже писали погоджусь що тут ще й де мова про те що ангулярі називають сервісом. По суті якщо взяти всі базові гайди то саме в контексті ангуляра майже все injectable називають сервісом
А взагалі як уже писали погоджусь що тут ще й де мова про те що ангулярі називають сервісом. По суті якщо взяти всі базові гайди то саме в контексті ангуляра майже все injectable називають сервісом
J
Банальний приклад якщо тобі з якоїсь певної причини треба створити 1 behaviour subject в сервісі який належить до певної фічі. Я би не створював FeatureStore клас заради одного BehaviourSubject
DT
Дискусійна тема. Думаю в не великих апках (та і може в великих якщо зберігається певна архітектура в контексті даного проекта) можна спокійно називати statfull сервіс сервісом а не стором і ніхто від того не пострадає 🙂
А взагалі як уже писали погоджусь що тут ще й де мова про те що ангулярі називають сервісом. По суті якщо взяти всі базові гайди то саме в контексті ангуляра майже все injectable називають сервісом
А взагалі як уже писали погоджусь що тут ще й де мова про те що ангулярі називають сервісом. По суті якщо взяти всі базові гайди то саме в контексті ангуляра майже все injectable називають сервісом
Если стоит injectable это не означает что это сервис, также если сервис, который имеет injectable не предусматривает к себе подпись сервиса, не означает, что он по сути не может быть сервисом, потому как резолверы и интерсепторы тоже сервисы которые работают на другом уровне абстракции
J
Та це зрозуміло, основна суть що я не бачу глобальної проблеми в тому що клас який зберігає певний стейт називається сервісом 🙂
DT
Та це зрозуміло, основна суть що я не бачу глобальної проблеми в тому що клас який зберігає певний стейт називається сервісом 🙂
тоже самое...
видимо коллеге по цеху кто-то на собесе сказал что это не сервисы, ибо сервис не может хранить дату
видимо коллеге по цеху кто-то на собесе сказал что это не сервисы, ибо сервис не может хранить дату
DT
а component-store вообще придумали еретики выходит:)
AO
Denchik Tymokhin
а component-store вообще придумали еретики выходит:)
Кстати, интересная статистика: component-store очень быстро набирает обороты - уже 1/3 от download от akita и 1/5 от NGXS.
До популярности ngrx/store еще далеко, но траектория хорошая и адаптация идет.
https://www.npmtrends.com/@ngrx/component-store-vs-@datorama/akita-vs-@ngxs/store
До популярности ngrx/store еще далеко, но траектория хорошая и адаптация идет.
https://www.npmtrends.com/@ngrx/component-store-vs-@datorama/akita-vs-@ngxs/store
DT
Alex Okrushko
Кстати, интересная статистика: component-store очень быстро набирает обороты - уже 1/3 от download от akita и 1/5 от NGXS.
До популярности ngrx/store еще далеко, но траектория хорошая и адаптация идет.
https://www.npmtrends.com/@ngrx/component-store-vs-@datorama/akita-vs-@ngxs/store
До популярности ngrx/store еще далеко, но траектория хорошая и адаптация идет.
https://www.npmtrends.com/@ngrx/component-store-vs-@datorama/akita-vs-@ngxs/store
@AlexOkrushko гуру я только за
DT
надо твой митинг посмотреть, все время забываю
J
Alex Okrushko
Кстати, интересная статистика: component-store очень быстро набирает обороты - уже 1/3 от download от akita и 1/5 от NGXS.
До популярности ngrx/store еще далеко, но траектория хорошая и адаптация идет.
https://www.npmtrends.com/@ngrx/component-store-vs-@datorama/akita-vs-@ngxs/store
До популярности ngrx/store еще далеко, но траектория хорошая и адаптация идет.
https://www.npmtrends.com/@ngrx/component-store-vs-@datorama/akita-vs-@ngxs/store
Я працюю з колегами з Німеччини і вони навідріз не хочуть ніякі нові фішки пробувати ngrx. Мол наш старий темплейт роботи з ngrx чудово працює і ми не готові зараз апдейтитись
Пропонував заінтродюсити в новий проект @ngrx/data щоб зменшити в десяткий разів copy&paste код, в ітогі отримав same answer і просто розширив їхній старий темпейт щоб хоч трохи зменшити копіпаст. + замінив action на action creator, що дало певну типізацію і далу змогу прибрати частково якісь мега складні інтерфейси з старого темплейта
Під темплейтом я маю на увазі просто кучу враперів щоб імулювати той самий entityState і тд
Пропонував заінтродюсити в новий проект @ngrx/data щоб зменшити в десяткий разів copy&paste код, в ітогі отримав same answer і просто розширив їхній старий темпейт щоб хоч трохи зменшити копіпаст. + замінив action на action creator, що дало певну типізацію і далу змогу прибрати частково якісь мега складні інтерфейси з старого темплейта
Під темплейтом я маю на увазі просто кучу враперів щоб імулювати той самий entityState і тд
DT
Я працюю з колегами з Німеччини і вони навідріз не хочуть ніякі нові фішки пробувати ngrx. Мол наш старий темплейт роботи з ngrx чудово працює і ми не готові зараз апдейтитись
Пропонував заінтродюсити в новий проект @ngrx/data щоб зменшити в десяткий разів copy&paste код, в ітогі отримав same answer і просто розширив їхній старий темпейт щоб хоч трохи зменшити копіпаст. + замінив action на action creator, що дало певну типізацію і далу змогу прибрати частково якісь мега складні інтерфейси з старого темплейта
Під темплейтом я маю на увазі просто кучу враперів щоб імулювати той самий entityState і тд
Пропонував заінтродюсити в новий проект @ngrx/data щоб зменшити в десяткий разів copy&paste код, в ітогі отримав same answer і просто розширив їхній старий темпейт щоб хоч трохи зменшити копіпаст. + замінив action на action creator, що дало певну типізацію і далу змогу прибрати частково якісь мега складні інтерфейси з старого темплейта
Під темплейтом я маю на увазі просто кучу враперів щоб імулювати той самий entityState і тд
я тебе искренне сочувствую
DT
свою тиму переубеждал полгода, в итоге обновились
AO
Я працюю з колегами з Німеччини і вони навідріз не хочуть ніякі нові фішки пробувати ngrx. Мол наш старий темплейт роботи з ngrx чудово працює і ми не готові зараз апдейтитись
Пропонував заінтродюсити в новий проект @ngrx/data щоб зменшити в десяткий разів copy&paste код, в ітогі отримав same answer і просто розширив їхній старий темпейт щоб хоч трохи зменшити копіпаст. + замінив action на action creator, що дало певну типізацію і далу змогу прибрати частково якісь мега складні інтерфейси з старого темплейта
Під темплейтом я маю на увазі просто кучу враперів щоб імулювати той самий entityState і тд
Пропонував заінтродюсити в новий проект @ngrx/data щоб зменшити в десяткий разів copy&paste код, в ітогі отримав same answer і просто розширив їхній старий темпейт щоб хоч трохи зменшити копіпаст. + замінив action на action creator, що дало певну типізацію і далу змогу прибрати частково якісь мега складні інтерфейси з старого темплейта
Під темплейтом я маю на увазі просто кучу враперів щоб імулювати той самий entityState і тд
Разные аппы требуют разных подходов. Если работает и всех устаивает, тогда зачем менять? :)
Мне нужны были оба подхода (store и component-store), и они хорошо вместе работают
Мне нужны были оба подхода (store и component-store), и они хорошо вместе работают
DT
Alex Okrushko
Разные аппы требуют разных подходов. Если работает и всех устаивает, тогда зачем менять? :)
Мне нужны были оба подхода (store и component-store), и они хорошо вместе работают
Мне нужны были оба подхода (store и component-store), и они хорошо вместе работают
ооо есть концепт поделится ??? как совмещал, или на ютубчике то шо есть хватит?
J
Alex Okrushko
Разные аппы требуют разных подходов. Если работает и всех устаивает, тогда зачем менять? :)
Мне нужны были оба подхода (store и component-store), и они хорошо вместе работают
Мне нужны были оба подхода (store и component-store), и они хорошо вместе работают
Теж правда.
Я на ngrx/data хотів чому перейти. В тому підході що зараз у нас по факту щоб створити entity state потрібно створити api файл, effects файл, reducer (тут правда попроще так як уже кастомні врапери поробили для entity state і async action), плюс можливо selectors (правда ми їх не юзаєм), плюс сервіс чисто для комунікації компонента зі стором і потім ще покрити ці всі файли юніт тестами. При тому що проект - медицина і test coverage має космічний бути 🙂
Думаю з ngrx/data була би можливість кучу аналогічних апішок ефектів і тд замінити меньшою кількістю кода
Я на ngrx/data хотів чому перейти. В тому підході що зараз у нас по факту щоб створити entity state потрібно створити api файл, effects файл, reducer (тут правда попроще так як уже кастомні врапери поробили для entity state і async action), плюс можливо selectors (правда ми їх не юзаєм), плюс сервіс чисто для комунікації компонента зі стором і потім ще покрити ці всі файли юніт тестами. При тому що проект - медицина і test coverage має космічний бути 🙂
Думаю з ngrx/data була би можливість кучу аналогічних апішок ефектів і тд замінити меньшою кількістю кода
AO
Denchik Tymokhin
ооо есть концепт поделится ??? как совмещал, или на ютубчике то шо есть хватит?
Этот самый свежий. Я не рассказываю как я их смешивал, но немного объясняю где бы и использовал что: https://www.youtube.com/watch?v=v5WSUE1_YHM
DT
Alex Okrushko
Этот самый свежий. Я не рассказываю как я их смешивал, но немного объясняю где бы и использовал что: https://www.youtube.com/watch?v=v5WSUE1_YHM
++++