Выглядит ужасно, зачем это нужно, если логику для шаблона можно инкапсулировать в пары, структурные директивы или на худой конец оставить в классе компонента, мне непонятно.
Если взять пайп, то ему можно дать человекочитаемое название, что облегчает понимание шаблона, можно написать юнит тест к нему, в отличие от предложенного мракобесия.
По поводу обработки ошибок в 5 пункте - из catchError лучше возвращать не пустой массив, а EMPTY из rxjs. Стратегия обработки ответа может быть разная. Представим что мы получаем массив комментариев к посту и у нас есть три варианта отображения данных:
успех - список комментариев
успех, пустой массив - текст "комментариев пока нет"
ошибка - текст "комментарии временно недоступны"
В вашем случае, даже в случае ошибки будет выполняться код из subscribe и в нем нужно будет проверять значение сигнала ошибки - это действительно пустой список или это ошибка на самом деле. Да и просто нагляднее это, что все что касается ошибки обрабатывается в catch. А ещё это хорошо если вы как в примере работаете с массивом, а если вам в ответе приходит объект, что тогда возвращать из catchError? Нужно будет городить что в observable может вернуться объект вашего типа или null какой-нибудь или возвращать объект вашего типа, но с дефолтными или пустыми полями. С EMPTY таких проблем нет.
Выглядит ужасно, зачем это нужно, если логику для шаблона можно инкапсулировать в пары, структурные директивы или на худой конец оставить в классе компонента, мне непонятно.
Если взять пайп, то ему можно дать человекочитаемое название, что облегчает понимание шаблона, можно написать юнит тест к нему, в отличие от предложенного мракобесия.
По поводу обработки ошибок в 5 пункте - из catchError лучше возвращать не пустой массив, а EMPTY из rxjs. Стратегия обработки ответа может быть разная. Представим что мы получаем массив комментариев к посту и у нас есть три варианта отображения данных:
успех - список комментариев
успех, пустой массив - текст "комментариев пока нет"
ошибка - текст "комментарии временно недоступны"
В вашем случае, даже в случае ошибки будет выполняться код из subscribe и в нем нужно будет проверять значение сигнала ошибки - это действительно пустой список или это ошибка на самом деле. Да и просто нагляднее это, что все что касается ошибки обрабатывается в catch. А ещё это хорошо если вы как в примере работаете с массивом, а если вам в ответе приходит объект, что тогда возвращать из catchError? Нужно будет городить что в observable может вернуться объект вашего типа или null какой-нибудь или возвращать объект вашего типа, но с дефолтными или пустыми полями. С EMPTY таких проблем нет.