В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

Angular Kyiv

509 membersпожаловаться на группу
2019 December 11

S

Serhii in Angular Kyiv
Alex S
почему бы не всунуть это дело в эффекты?
возвал запрос, обработал ответ и норм ответ записал в стор. Если чёт не то, то записал стейт ошибку..
а селекторы потом просто сделают свою работу

+ селекторы пересчитываются при обновлении стейта. Это нуно учесть в калькуляции
Вопрос в том, чтоб просто залогировать ошибку (и потом смотреть уже в бекенд, почему что неправильно сработало), а не упасть полностью.
Почему не эффекты? Потому что тогда вообще проще перейти обратно в pull-based архитектуру и полностью все рассчеты проводить в сервисах.

Плюс, суть использования селекторов именно в том, чтоб сохранять только оригинальные данные и не дублировать выполнение кода.
источник
15:25пожаловаться#1

S

Serhii in Angular Kyiv
Гм, подумал тут чуть больше.
Возможно вариант в селекторах возвращать тип данных с оберткой. А-ля WithLogs<SomeType>. И в него писать, если были какие-то ошибки. А потом уже на компоненте/фасаде, где эти селекторы вызываются, обрабатывать полученные сообщения.
Вроде бы и чистая функция выходит (как минимум по определению). Но по факту так тоже не нравится.
источник
15:28пожаловаться#2

DG

Danil Gudz in Angular Kyiv
Serhii
Гм, подумал тут чуть больше.
Возможно вариант в селекторах возвращать тип данных с оберткой. А-ля WithLogs<SomeType>. И в него писать, если были какие-то ошибки. А потом уже на компоненте/фасаде, где эти селекторы вызываются, обрабатывать полученные сообщения.
Вроде бы и чистая функция выходит (как минимум по определению). Но по факту так тоже не нравится.
с ErrorHandler'ом не пробовал? мне тот вариант ментально нравится
источник
15:29пожаловаться#3

СБ

Сергій Бабіч in Angular Kyiv
Serhii
Гм, подумал тут чуть больше.
Возможно вариант в селекторах возвращать тип данных с оберткой. А-ля WithLogs<SomeType>. И в него писать, если были какие-то ошибки. А потом уже на компоненте/фасаде, где эти селекторы вызываются, обрабатывать полученные сообщения.
Вроде бы и чистая функция выходит (как минимум по определению). Но по факту так тоже не нравится.
і це прям да
источник
15:30пожаловаться#4

S

Serhii in Angular Kyiv
Danil Gudz
с ErrorHandler'ом не пробовал? мне тот вариант ментально нравится
Не то, чтоб не пробовал. Но throw означает, что ты прерываешь выполнение функции.
источник
15:30пожаловаться#5

S

Serhii in Angular Kyiv
Сергій Бабіч
і це прям да
Ти про останній абзац "да", чи про саму ідею? :)
источник
15:30пожаловаться#6

СБ

Сергій Бабіч in Angular Kyiv
Serhii
Ти про останній абзац "да", чи про саму ідею? :)
про ідею.
источник
15:31пожаловаться#7

СБ

Сергій Бабіч in Angular Kyiv
так є можливість закумулювати всі помилки і обробити їх деінде, в залежності від контекста.
Плюс можна безпечно їх на юайці вивести в разі чого
источник
15:32пожаловаться#8

S

Serhii in Angular Kyiv
Якщо сильно упоротись, то це навіть можна назвати монадичною функцією 🥶
источник
15:32пожаловаться#9

S

Serhii in Angular Kyiv
Одна проблема тут - дуже вже багато оверхеду з точки зору коду виходить.
источник
15:33пожаловаться#10

AS

Alex S in Angular Kyiv
Serhii
Вопрос в том, чтоб просто залогировать ошибку (и потом смотреть уже в бекенд, почему что неправильно сработало), а не упасть полностью.
Почему не эффекты? Потому что тогда вообще проще перейти обратно в pull-based архитектуру и полностью все рассчеты проводить в сервисах.

Плюс, суть использования селекторов именно в том, чтоб сохранять только оригинальные данные и не дублировать выполнение кода.
ну ок
ты выполняешь, какой-то рассчёт в эффекте
отлавливаешь ошибку в catchError, который смотрит в твой LoggerService
и остальные вычисления/операции добиваешь в finalize, чтоб “не упасть на ошибке”

а оригинальные данные, допустим, ты можешь сохранить дополнительно, если они ну 100% нужны (TBD)
источник
15:46пожаловаться#11

AS

Alex S in Angular Kyiv
при желании, ты можешь и из сервиса получить селектор, написать пайп на него и будет чуть ли не то же самое. Но сам селектор останется чист - получил стейт и отдал тому кто попросит. А дальше в сервисе, в пайпе, обработал результат
источник
15:47пожаловаться#12

AS

Alex S in Angular Kyiv
или каким-то образом, если не подходит finalize, то вынести в tap() логгирование ошибки (соответственно, обойтись и без catchError() ). Раньше видел синтаксисы, что tap принимает success + error callback. Последние версии, скажу честно, не смотрел
источник
15:48пожаловаться#13

DG

Danil Gudz in Angular Kyiv
Alex S
ну ок
ты выполняешь, какой-то рассчёт в эффекте
отлавливаешь ошибку в catchError, который смотрит в твой LoggerService
и остальные вычисления/операции добиваешь в finalize, чтоб “не упасть на ошибке”

а оригинальные данные, допустим, ты можешь сохранить дополнительно, если они ну 100% нужны (TBD)
помнится мне finalize выполняет колбэк без параметров)
источник
16:10пожаловаться#14

AS

Alex S in Angular Kyiv
Danil Gudz
помнится мне finalize выполняет колбэк без параметров)
блин. Точн
источник
16:16пожаловаться#15

M

Malikov in Angular Kyiv
а чем вы руководствуетесь, когда решаете, внедрять store в приложение или нет?
источник
16:16пожаловаться#16

AS

Alex S in Angular Kyiv
Malikov
а чем вы руководствуетесь, когда решаете, внедрять store в приложение или нет?
эм.. ну у меня всё просто: ответ 100% да, т.к. приложения большие и без грамотного стейт менеджемента не комельфо


+ шарить даты через сервисы - ну такое.. на это не стоит)
источник
16:18пожаловаться#17

SФ

Sergey Фrolov in Angular Kyiv
Alex S
эм.. ну у меня всё просто: ответ 100% да, т.к. приложения большие и без грамотного стейт менеджемента не комельфо


+ шарить даты через сервисы - ну такое.. на это не стоит)
Чем тебе сервисы не стор? )
источник
16:19пожаловаться#18

SФ

Sergey Фrolov in Angular Kyiv
Ну примитивный
источник
16:19пожаловаться#19

SФ

Sergey Фrolov in Angular Kyiv
А то привет event-модель управления
источник
16:19пожаловаться#20