Работа с данными в Angular

[klimentRu]

То что у Вас получилось из User сложно назвать моделью.
А для дополнения модели новыми полями лучше использовать мапер.
Например как на бэке мапятся entity(модель БД) и DTO, так же и на фронте можно сделать прослойку из маперов между приложением и слоем api сервисов.
Как вариант можно использовать библиотеку automapper-ts

[molchanoviv]

А я для этих целкей использую библиотеку json2typescript. Описал класс модели, описал аннотациями декораторами поля json объекта, заинжектил сериалайзер в сервис и дернул там

map(result => this.serializer.deserialize(result, User))

и всё. И никакого бойлерплейта.

[GeneAYak]

А мы вот такую штуку используем, весьма удобно https://github.com/ikasparov/tsmodels

[SergeyMell]

Очень интересно. Я искал нечто подобное, но не попадалось. Спасибо большое.

[slava_brezovsky]

constructor(private User: UserFactory, private http: HttpClient) {
    http.get('/users').subscribe(res => console.log(res));
}

Фабрика писалась чтобы в конечном итоге все равно вызвать http?
Если нет, поправьте пожалуйста.

[SergeyMell]

Спасибо большое. Прощелкал. Сейчас поправлю.

[makseo]

Как на счет варианта пойти angular путем и использовать Pipes.
Например, код конкатенации имени и фамилии вынести в следующий pipe.

@Pipe({ name: 'fullName' })
export class FullName implements PipeTransform {
  transform(value: any): string {
    return value.firstName, value.lastName].filter(el => !!el).join(' ');
  }
}

Таким образом решается проблема перегруженности шаблона логикой, повышается читаемость, плюс решается вопрос переиспользования,
ведь pipes можно вынести в SharedModule и использовать по всему приложению.
{{ user | fullName}}

---

Плюс бросился в глаза следующий фрагмент кода:

<img [src]="userService.getUserAvatar(user.id)">

Вызов функций в шаблонах пагубно сказывается на производительности angular-приложений.
Рекоменую, использовать также pipe + ChangeDetectionStrategy.onPush
Хорошее 5 минутное видео как раз по этому поводу с последней ngconf конференции:
www.youtube.com/watch?v=I6ZvpdRM1eQ

[SergeyMell]

Спасибо. Да, действительно фильтры позволяют решить эту проблему. Но область применимости моделей предметной области значительно шире. Поэтому мне хотелось подвести к ним.

[ksenofobius]

Почему бы вместо сервиса не использовать ngrx? Тут это само собой напрашивается как мне кажется

[SergeyMell]

Возможности «модели предметной области» в общем случае значительно шире, чем может дать ngrx, насколько я понимаю.

[ksenofobius]

Ничего не мешает использовать существующую модель внутри ngrx. Изменится лишь способ доступа и хранения данных

[andres_kovalev]

Компонент UserList изначально следовало разбить на компоненты UserList и UserListItem, а для поставленной задачи отображения полного имени замечательно подойдет соответствующий pipe, который очень легко переиспользовать, не создавая при этом «умные данные».

[XT2]

ссылка на аватарку пользователя не приходит сразу в ответе, а формируется на основе id пользователя

По хорошему, сервер должен отдавать готовую динамическую ссылку на любой статический контент подобного типа. В вашем случае придется заботиться о сбросе кеша, если она изменена и проверить есть ли она вообще; как реализовать приватность доступа к аватаркам; хранить пути к серверу и т.д. — и всё это не разрешимо на фронте. А нужно просто получить ссылку с сервера и всё ;-)

Можно вынести этот метод из компоненты в сервис.

Для этого существуют Пайпы.

мы переместили метод создания пользователя в UserService

Вместо решения проблемы, вы переложили её на плечи бедного сервиса. Ваша первая реализация класса User уже достаточна, далее не нужно было его замусоривать. Внедрив в него кучу сервисов, вы обрекли себя на муки поддержки в будущем (например, в другом месте приложения потребуется просто вывести имя, а у вас ещё вагон зависимостей).

Не бойтесь создавать модели и сервисы при первой необходимости. Вы сами того не замечая удивитесь, что сервис, о котором по началу не думали, уже используется в 10 местах. И рефакторинг в сторону упрощения и объединения всегда проще, чем расковыривать монстра с десятком зависимостей и сотней строк.

А на счет бойлерплейта уже выше вам написали.

[SergeyMell]

По хорошему, сервер должен отдавать готовую динамическую ссылку на любой статический контент подобного типа.

Согласен. Но я сталкивался с API подобным приведенному в публикации и такой формат более отвечал поставленным целям статьи.

Для этого существуют Пайпы.

Полностью согласен и даже добавил небольшой update к статье. Цель статьи была подвести к некоему паттерну модели предметной области. Возможно пример с полным именем не самый удачный в этом контексте.

По поводу сервиса и его использования — я обязательно обдумаю ваши замечания. Пока я не сталкивался с проблемами внедрения такого типа моделей. В целом очень благодарен за расширенный комментарий.