Size: a a a

2020 August 01

IK

Igor Kurkov in Angular Kyiv
Короче все сложно)) в любом случае всем большое спасибо за дискуссию, мне кажется это довольно животрепещущий вопрос, возможно ктото захочет осветить его полнее сделав стрим с примерами обусловленной миграции на риал кейсах, думаю многим было бы интересно
источник

AK

Aliaksei Kuncevič in Angular Kyiv
если интересно, я рассказывал как мегрировать с Реактивных Сервисов на NGXS с примерами кода и тп 👉https://youtu.be/sDrAzRyCo8U&t=2663
источник

IK

Igor Kurkov in Angular Kyiv
Aliaksei Kuncevič
если интересно, я рассказывал как мегрировать с Реактивных Сервисов на NGXS с примерами кода и тп 👉https://youtu.be/sDrAzRyCo8U&t=2663
404 отдает, только у меня?
источник

Denis Мовляйко... in Angular Kyiv
Igor Kurkov
404 отдает, только у меня?
Тоже 404
источник

AK

Aliaksei Kuncevič in Angular Kyiv
источник

G

George in Angular Kyiv
Igor Kurkov
По тестированию надо отдельную дискуссию, думаю за тестирование пока бессмысленно говорить в нашем флоу разработки, последний опрос Алекса это подтвердил, мало кто тесты пишет в связи с бардачным менеджментом приходящим в снг, особенно в свете вопроса о повышении быстроты/удобства разработки. Тем более, тестирование стейтовых rx цепочек в любом случае сложнее чем простой testbed с di. Опять же просто фича, даже бесплатная, требующая стейта не должна влиять на архитектуру в глобальном плане, или нет?
Не совсем согласен. По моему опыту, тесты не пишут потому что кодовая база такая, что сложно их писать. Упоминавшийся tight coupling в том числе. И получается что бы что-то протестировать нужно писать сложные ассерты, стабы и т.д.
источник

AK

Aliaksei Kuncevič in Angular Kyiv
Aliaksei Kuncevič
если интересно, я рассказывал как мегрировать с Реактивных Сервисов на NGXS с примерами кода и тп 👉https://youtu.be/sDrAzRyCo8U&t=2663
если че слайды тут https://speakerdeck.com/kuncevic/progressive-state-management-with-ngxs а все ссылки на код и тп в дескрипшине
источник

IK

Igor Kurkov in Angular Kyiv
Aliaksei Kuncevič
если че слайды тут https://speakerdeck.com/kuncevic/progressive-state-management-with-ngxs а все ссылки на код и тп в дескрипшине
Спасибо 👍
источник

AO

Alex Okrushko in Angular Kyiv
Из-за другого часового пояса мне не довелось принять участие в прямой переписке, поэтому я сейчас попытаюсь вернуться с некоторым затронутым темам, но, по-первых, хочу сказать следующее:

Огромное спасибо за цивильную и аргументированную дискуссию - большое удовольствие почитать 👍👍👍
источник

SS

Sasha Savych in Angular Kyiv
+1 до попереднього повідомлення
источник

AO

Alex Okrushko in Angular Kyiv
Как уже было подмечено, какие стейт решения нужно и нужны ли они вообще зависит от многих факторов. У меня нет заранее подготовленного списка, но если на вскидку, то:
- размер аппликации - сколько комнонентов
- насколько эта аппликация связана - либо она состоит из множества отдельных групп независимых компонентов
- насколько грубока аппликация
- насколько "завершена" бизнес задача - сделали и отдали, либо многое часто меняется
- насколько долго надо поддерживать - сделали и забыли, либо годами поддерживать
- есть ли контроль над API с бэкендов - множли ли вообще туда graphQL засунуть

последнии два пункта вообще интересные. На пример в Firebase Console, нам уже не раз надо было переходить на другие API к другим бэкендам (которые не заменяли один к одному существующие), при этом UI не должен был меняться

и т.д. этот список явно не полный, но это что я сейчас мог собрать
источник

AO

Alex Okrushko in Angular Kyiv
Sergey Фrolov
Просто мы смотрим на свершившиеся проекты, которые выросли и были переписаны на такой подход. А те, что которые разрабатывались с начала на ивентах, не факт что вообще было нужно применять такой подход.
использовать event-based стейт менеджмент (как ngrx/strore) посто потому что он "популярный" конечно же я бы не рекомендовал. Действительно, надо обозначить преимущества и недостатки такого подхода, и потом решать.

Из больших недостатков, это extra indirection, которую создают Экшены (они же Ивенты). Их сложно отследить (даже с теми изменениями, которые мы сделали createAction).

Из преимуществ, это то, что один ивент может вызвать изменения в разных частях аппликации - во многих эффектах и редусерах. Это и делает его более глобальным стейт менеджментом.
источник

AK

Aliaksei Kuncevič in Angular Kyiv
Alex Okrushko
Как уже было подмечено, какие стейт решения нужно и нужны ли они вообще зависит от многих факторов. У меня нет заранее подготовленного списка, но если на вскидку, то:
- размер аппликации - сколько комнонентов
- насколько эта аппликация связана - либо она состоит из множества отдельных групп независимых компонентов
- насколько грубока аппликация
- насколько "завершена" бизнес задача - сделали и отдали, либо многое часто меняется
- насколько долго надо поддерживать - сделали и забыли, либо годами поддерживать
- есть ли контроль над API с бэкендов - множли ли вообще туда graphQL засунуть

последнии два пункта вообще интересные. На пример в Firebase Console, нам уже не раз надо было переходить на другие API к другим бэкендам (которые не заменяли один к одному существующие), при этом UI не должен был меняться

и т.д. этот список явно не полный, но это что я сейчас мог собрать
✅ нармальна, завтра утром как проснусь почитаю все что будет ниже 😂 😴 zZzZZZz
источник

AO

Alex Okrushko in Angular Kyiv
Igor Filippov
Судя по вопросам которые я читаю в ангуляр чатах. Все эти решения отличные от дефолтных сабджектов в сервисах несут только лишний гемор
сервисы с сабджектами - это хорошие решения, но они очень часто не структурированы, и часто не решают проблем с race conditions.

мы (NgRx команда) на следующей неделе планируем выпустить v10, который будет включать ngrx/component-store, который как раз и является более структурированной заменой для Сервиса с Сабджектом.

Я его презентовал уже на нескольких митапап за последние 2 недели, и так же буду о нем рассказывать на ngKharkiv 11 августа - присоединяйтесь 😀

Если хотите послушать раньше, то я думаю вот та хорошо вышла: https://youtu.be/H9EZZDREMEk?t=2807
источник

AO

Alex Okrushko in Angular Kyiv
я еще вернусь чуть позже с поднятым темам - сейчас пора с семьей время провести :)
источник

AO

Alex Okrushko in Angular Kyiv
Aliaksei Kuncevič
еще можно юзать сервисы с BehaviorSubject например и тогда можно до какого то порога юзать просто такие сервисы - если это подходит под проект
их как раз ComponentStore и пытается заменить.

Но простой замены сервисов мало. Очень важно ⚠️ понимать где именно должен жить стейт. Это зависит от:
- где этот стейт нужнет в самой аппликации - найти самый нижний узел/нод в дереве компонентов, к которому можно "прикрепить" это
- какие APIs есть. Иногда они возвращают более "общие" результаты

Так же важно не копировать/дуплицировать этот стейт в нижние компоненты (derived state называется), а использовать pipe или селекторы для трансформации или объедининия нескольких "потоков" (streams) данных.
источник

AO

Alex Okrushko in Angular Kyiv
Опять же, есть исключения 😆 но сейчас не о них
источник

Sergey Фrolov in Angular Kyiv
Почему не копировать? По факту стейт компонента его ответственность и может меняться или иметь свои доп переменные
источник

Sergey Фrolov in Angular Kyiv
Ситуации бывают разные, не всегда можно просто закинуть стрим через переменную
источник

AO

Alex Okrushko in Angular Kyiv
Это так, если это не "persisted state", который:
- потом надо все равно передать назад на бэкенд
- используется в других конпонентах в той или иной форме - получится разсинхронихованность

Есть этот стейт становится Local UI State, до, на пример, нажатия на Save кнопку, и только потом он посылается наверх, то да, тогда ок.
источник