Estoy construyendo un juego usando Angular que tiene la siguiente mecánica:
request.respond(response) . Necesitaba encontrar una clase de solicitud adecuada para estos requisitos. Como las solicitudes se resuelven de una vez por todas, decidí evitar basarlo en RxJs Observable e intenté usar JavaScript Promise en su lugar. Las promesas se pueden esperar fácilmente con la sintaxis async / await , y el requisito (4) me llevó a conocer el patrón diferido . Construí esta clase base para todo tipo de solicitudes:
abstract class Request<T> { private _resolve: (value: T) => void = () => {}; private _response: Promise<T> = new Promise<T>(resolve => { this._resolve = resolve; }); public get response(): Promise<T> { return this._response; } public respond(response: T) { this._resolve(response); } }No agregué el manejo del rechazo ya que no se me ocurrió una situación en la que la solicitud pudiera fallar. Ni siquiera parece ser necesario un tiempo de espera, ya que el juego requiere una respuesta para continuar.
Esto funcionó perfectamente para mis propósitos, pero luego comencé a encontrar discusiones que trataban esto como un antipatrón (por ejemplo,esto y esto ). No estoy acostumbrado a trabajar con promesas, por lo que no entiendo completamente los riesgos de exponer la función de resolución, no puedo discernir situaciones en las que este patrón sea legítimo, ni puedo imaginar otra forma de cumplir con mis requisitos usando Promesa.
Me gustaría saber entonces si esta es una forma legítima de usar el patrón Diferido y, en caso de que no lo sea, si hay otra forma de lograr lo que necesito.
El problema del antipatrón diferido no está en exponer la función de resolve en sí misma, sino en exponerla junto con (o peor aún, como parte de) la promesa. No hay razón para que su clase de solicitud deba contener la promesa. En su lugar, todo lo que necesita hacer es simplemente
const response = await new Promise(resolve => { mediator.send({ respond: resolve }); }); El mediador no necesita nada más que este objeto, y el componente que maneja la solicitud aún puede simplemente llamar a request.respond(response) . Esto es mucho más simple que hacer
const request = new Request(); mediator.send(request); const response = await request.response; Esto puede ser innecesariamente complicado (con todo el código en la clase Request ), pero el uso aún no es problemático. Donde realmente se convierte en un antipatrón es si lo hiciste
function sendRequest() { const request = new Request(); mediator.send(request); return request; }porque ahora alguien tiene un "objeto diferido", no solo una promesa para la respuesta. Podrían abusar de la función:
const request = sendRequest(); request.respond("Ooops"); const response = await request.response; Este es el peligro real: devolver un código diferido que no se supone que resuelva la promesa. Sin embargo, está totalmente bien entregar la función de resolve al componente que se supone que debe responder.