Hola, realmente estoy cuestionando el uso de una llamada "asObserveable ()" en el tema.
En mi opinión, crea una gran sobrecarga innecesaria. En mi opinión, la prevención de llamadas como "next()" o "complete()" son inútiles.
¿Puedes nombrarme una buena razón por la que deberías hacer esto?
Solo compara estos dos
export class TestService { public get test$(): Observable<test> { return this.test$.asObservable(); } public get test2$(): Observable<test> { return this.test2$.asObservable(); } public get test3$(): Observable<test3> { return this.test3$.asObservable(); } public get test4$(): Observable<test4> { return this.test4$.asObservable(); } private readonly _test1$ = new ReplaySubject<test1>(1); private readonly _test2$ = new ReplaySubject<test2>(1); private readonly _test3$ = new ReplaySubject<test3>(1); private readonly _test4$ = new ReplaySubject<test4>(1); } export class TestService { public readonly test1$ = new ReplaySubject<test1>(1); public readonly test2$ = new ReplaySubject<test2>(1); public readonly test3$ = new ReplaySubject<test3>(1); public readonly test4$ = new ReplaySubject<test4>(1); }Puedo dar una buena razón. Suponga que desea emitir algún evento execCompleted$ basado en cierta acción. Así es como se implementa
export class TestService { private readonly execCompleted$ = new Subject<string>(); public async makeServerCall(userData){ const resp = await this.http.post('...').toPromise(); this.execCompleted$.next(resp.data.id); return resp; } public getUpdatedId(){ this.execCompleted$.asObservable(); } } Ahora, este servicio es utilizado por dos Componentes -> Admin y UserInfo .
El componente de Admin puede actualizar alguna información de usuario usando makeServerCall() y actualizar algunos datos de usuario. Este evento debe ser capturado por UserInfoComponent para que pueda escuchar y actualizar la información (una vez que se haya realizado alguna actualización).
Al exponer el Sujeto usando getUpdatedId() , está restringiendo cualquier otro componente para que envíe por error el evento next() en execCompleted$ . Este Asunto solo se activará cuando makeServerCall(userData) .
Este es solo un ejemplo simple. Hay casos más complejos pero todos tienen la misma intención subyacente.
No permitir que se emitan o cancelen eventos no deseados. Solo la fuente prevista debe hacerlo.
Esta es una práctica estándar en la programación en la que desea algunas restricciones sobre lo que otros pueden extender y lo que no. Un poco como director abierto-cerrado.
Algún código repetitivo. No mucho más.
En mi opinión, crea una gran sobrecarga innecesaria.
¿Lo has medido? Los sujetos extienden Observables, todo lo que hace es crear una copia superficial. Me sorprendería si encontrara una aplicación en la que la diferencia sea mayor que la varianza (efectivamente, no se puede medir).
Una arquitectura más limpia significa que es más fácil encontrar errores y/o más fácil evitar que se creen errores en primer lugar.
La encapsulación es uno de los fundamentos de una arquitectura limpia. Debido a que la encapsulación oculta una parte de nuestro programa de otras partes, hace que cada parte sea un poco más fácil de razonar. Por lo tanto, es más fácil de entender, escribir, ampliar y mantener.
Si hay un error en un sistema bien diseñado, el área de superficie es mucho menor.
En general, los beneficios de este tipo de decisiones tienden a darse a conocer en proyectos más grandes con equipos más grandes. Si está escribiendo un proyecto de pasatiempo en casa o está haciendo un producto mínimo viable por sí mismo o un equipo pequeño, puede tener sentido renunciar a la planificación excesiva para apresurarse. Tal proyecto podría necesitar una reescritura/revisión una vez que crezca, pero para entonces el esfuerzo adicional valdrá la pena.
Si tiene un verificador de tipo estático configurado de manera relativamente estricta (TypeScript, Elm, PureScript, ClojureScript, etc.), puede devolver el Sujeto como un Observable sin realizar ningún cambio en la representación del tipo en tiempo de ejecución.
Obtiene la encapsulación sin costo de tiempo de ejecución.