Trabajando con datos en Angular

Hola a todos, mi nombre es Sergey y soy desarrollador web. Perdóname Dmitry Karlovsky por la introducción prestada, pero fueron sus publicaciones las que me inspiraron a escribir este artículo.

Hoy me gustaría hablar sobre trabajar con datos en aplicaciones angulares en general y modelos de dominio en particular.

Supongamos que tenemos una lista de usuarios que recibimos del servidor en el formulario

[ { "id": 1, "first_name": "James", "last_name": "Hetfield", "position": "Web developer" }, { "id": 2, "first_name": "Elvis", "last_name": "", "position": "Project manager" }, { "id": 3, "first_name": "Steve", "last_name": "Vai", "position": "QA engineer" } ] 

y necesitas mostrarlo como en la imagen

Parece fácil, intentémoslo. Por supuesto, para obtener esta lista, tendremos un servicio de UserService siguiente. Tenga en cuenta que el enlace al avatar del usuario no aparece inmediatamente en la respuesta, sino que se forma en función de la id usuario.

 // UserService import {Injectable} from '@angular/core'; import {HttpClient} from '@angular/common/http'; import {Observable} from 'rxjs'; import {UserServerResponse} from './user-server-response.interface'; @Injectable() export class UserService { constructor(private http: HttpClient) { } getUsers(): Observable<UserServerResponse[]> { return this.http.get<UserServerResponse[]>('/users'); } getUserAvatar(userId: number): string { return `/users/${userId}/avatar`; } } 

El componente UserListComponent será responsable de mostrar la lista de usuarios.

 // UserListComponent import {Component} from '@angular/core'; import {UserService} from '../services/user.service'; @Component({ selector: 'app-user-list', template: ` <div *ngFor="let user of users | async"> <img [src]="userService.getUserAvatar(user.id)"> <p><b>{{user.first_name}} {{user.last_name}}</b>, {{user.position}}</p> </div> ` }) export class UserListComponent { users = this.userService.getUsers(); constructor(public userService: UserService) { } } 

Y aquí ya teníamos un problema definido . Presta atención a la respuesta del servidor. El campo last_name puede estar vacío y si dejamos el componente en este formulario, recibiremos espacios no deseados antes de la coma. ¿Cuáles son las opciones de solución?

1. Puede corregir ligeramente la plantilla de visualización

   
   

    <p> <b>{{[user.first_name, user.last_name].filter(el => !!el).join(' ')}}</b>, {{user.position}} </p> 

   
   

   Pero de esta manera, sobrecargamos la plantilla con lógica, y se vuelve poco legible incluso para una tarea tan simple. Pero la aplicación todavía tiene que crecer y crecer ...

   
   

2. Extraiga el código de una plantilla a una clase de componente agregando un método de tipo

   
   

    getUserFullName(user: UserServerResponse): string { return [user.first_name, user.last_name].filter(el => !!el).join(' '); } 

   
   

   Ya es mejor, pero lo más probable es que el nombre de usuario completo no se muestre en un lugar de la aplicación, y tendremos que duplicar este código. Puede llevar este método del componente al servicio. De esta manera, eliminaremos la posible duplicación de código, pero tampoco me gusta esta opción. Y no me gusta porque resulta que alguna entidad más general ( UserService ) debería saber sobre la estructura de la entidad de User más pequeña que se le pasa. No es su nivel de responsabilidad, me parece.

   
   

En mi opinión, el problema surge principalmente del hecho de que tratamos la respuesta del servidor únicamente como un conjunto de datos. Aunque, de hecho, es una lista de entidades del área temática de nuestra aplicación, una lista de usuarios. Y si estamos hablando de trabajar con entidades, entonces vale la pena usar las herramientas más adecuadas para esto: los métodos de programación orientada a objetos.

Comencemos creando la clase Usuario

 // User export class User { readonly id; readonly firstName; readonly lastName; readonly position; constructor(userData: UserServerResponse) { this.id = userData.id; this.firstName = userData.first_name; this.lastName = userData.last_name; this.position = userData.position; } fullName(): string { return [this.firstName, this.lastName].filter(el => !!el).join(' '); } avatar(): string { return `/users/${this.id}/avatar`; } } 

El constructor de la clase es un deserializador de respuesta del servidor. La lógica para determinar el nombre de usuario completo se convierte naturalmente en un método de un objeto de la clase User , así como la lógica para obtener un avatar. Ahora UserService el UserService para que nos devuelva objetos de la clase User como resultado del procesamiento de la respuesta del servidor

 // UserService import {Injectable} from '@angular/core'; import {HttpClient} from '@angular/common/http'; import {map} from 'rxjs/operators'; import {UserServerResponse} from './user-server-response.interface'; import {User} from './user.model'; @Injectable() export class UserService { constructor(private http: HttpClient) { } getUsers(): Observable<User[]> { return this.http.get<UserServerResponse[]>('/users') .pipe(map(listOfUsers => listOfUsers.map(singleUser => new User(singleUser)))); } } 

Como resultado, el código de nuestro componente se vuelve mucho más limpio y más legible. Todo lo que se puede llamar lógica de negocios está encapsulado en modelos y es completamente reutilizable.

 import {Component} from '@angular/core'; import {UserService} from '../services/user.service'; @Component({ selector: 'app-user-list', template: ` <div *ngFor="let user of users | async"> <img [src]="user.avatar()"> <p><b>{{user.fullName()}}</b>, {{user.position}}</p> </div> ` }) export class UserListComponent { users = this.userService.getUsers(); constructor(private userService: UserService) { } } 

Expandamos ahora las capacidades de nuestro modelo. En teoría (en este contexto, me gusta la analogía con el patrón ActiveRecord ), los objetos del modelo de usuario deben ser responsables no solo de obtener datos sobre sí mismos, sino también de cambiarlos. Por ejemplo, podemos cambiar la imagen de perfil del usuario. ¿Cómo se verá el modelo de usuario ampliado con tal funcionalidad?

 // User export class User { // ... constructor(userData: UserServerResponse, private http: HttpClient, private storage: StorageService, private auth: AuthService) { // ... } // ... updateAvatar(file: Blob) { const data = new FormData(); data.append('avatar', file); return this.http.put(`/users/${this.id}/avatar`, data); } } 

Se ve bien, pero el modelo de User ahora usa el servicio HttpClient y, en términos generales, puede conectarse y usar varios otros servicios, en este caso, AuthService y AuthService (no se usan, sino que se agregan solo, por ejemplo). Resulta que si queremos usar el modelo de User en algún otro servicio o componente, tendremos que conectar todos los servicios asociados con él para crear objetos de este modelo. Parece muy inconveniente ... Puede usar el servicio de Injector (por supuesto, también tendrá que implementarse, pero se garantizará que sea solo uno) o incluso crear una entidad de inyector externo que no tenga que implementar, pero veo la forma más correcta de delegar la creación de objetos de clase de User al servicio UserService servicio de UserService misma manera él es responsable de obtener la lista de usuarios.

 // UserService import {Injectable} from '@angular/core'; import {HttpClient} from '@angular/common/http'; import {Observable} from 'rxjs'; import {map} from 'rxjs/operators'; import {UserServerResponse} from './user-server-response.interface'; import {User} from './user.model'; @Injectable() export class UserService { constructor(private http: HttpClient, private storage: StorageService, private auth: AuthService) { } createUser(userData: UserServerResponse) { return new User(userData, this.http, this.storage, this.auth); } getUsers(): Observable<User[]> { return this.http.get<UserServerResponse[]>('/users') .pipe(map(listOfUsers => listOfUsers.map(singleUser => this.createUser(singleUser)))); } } 

Por lo tanto, trasladamos el método de creación de usuarios a UserService , que ahora es más apropiado para llamar a la fábrica, y cambiamos todo el trabajo de implementar dependencias a los hombros de Angular: solo necesitamos conectar el UserService en el constructor.

Al final, eliminemos la duplicación de los nombres de los métodos e introduzcamos convenciones para los nombres de las dependencias inyectadas. La versión final del servicio en mi visión debería verse así.

 import {Injectable} from '@angular/core'; import {HttpClient} from '@angular/common/http'; import {Observable} from 'rxjs'; import {map} from 'rxjs/operators'; import {UserServerResponse} from './user-server-response.interface'; import {User} from './user.model'; @Injectable() export class UserFactory { constructor(private http: HttpClient, private storage: StorageService, private auth: AuthService) { } create(userData: UserServerResponse) { return new User(userData, this.http, this.storage, this.auth); } list(): Observable<User[]> { return this.http.get<UserServerResponse[]>('/users') .pipe(map(listOfUsers => listOfUsers.map(singleUser => this.create(singleUser)))); } } 

Y se propone implementar UserFactory bajo el nombre de User

 import { Component } from '@angular/core'; import {HttpClient} from '@angular/common/http'; import {UserFactory} from './services/user.service'; @Component({ selector: 'app-root', templateUrl: './app.component.html', styleUrls: ['./app.component.css'] }) export class AppComponent { title = 'app'; users = this.User.list(); constructor(private User: UserFactory) { } } 

En este caso, un objeto de la clase UserFactory parece a una clase User con métodos estáticos para obtener una lista de usuarios y un método especial para crear nuevas entidades, y sus objetos contienen todos los métodos de lógica de negocios necesarios asociados con una entidad en particular.

Sobre esto, le dije todo lo que quería. Espero discutir en los comentarios.

Actualización

Quería expresar mi gratitud a todos los que comentan. Usted notó correctamente que para resolver el problema de mostrar el nombre, valdría la pena usar Pipe . Estoy completamente de acuerdo y me sorprende que no haya tomado esta decisión. Sin embargo, el objetivo principal del artículo es mostrar un ejemplo de creación de un modelo de dominio (en este caso, User ), que podría encapsular convenientemente toda la lógica de negocios asociada con su esencia. Paralelamente, traté de resolver el problema que lo acompaña con la inyección de dependencia.