Trampas en la documentación de Promise
Evitando problemas de la documentación popular
Detectando anti‑patrones de Promesas en resultados de búsqueda de Google y bibliotecas populares.
Comienzo con una confesión: soy culpable de escribir los mismos “anti‑patrones” que critico a continuación, al igual que muchos desarrolladores de JS. Nada de lo expuesto pretende ser personal ni dirigido a los autores originales. Simplemente estoy haciendo una revisión de código sobre patrones comunes; espero transmitir mi forma de priorizar y mi proceso de pensamiento crítico.
Con suerte podrás identificar las señales de alerta de Promesas mal diseñadas después de analizar este proyecto.
CallbackHell.com
CREDIT: http://callbackhell.com/
StrongLoop
CRÉDITO:
https://strongloop.com/strongblog/node-js-callback-hell-promises-generators/
RisingStack
CRÉDITO: https://blog.risingstack.com/node-js-async-best-practices-avoiding-callback-hell-node-js-at-scale/
Este artículo está bastante sólido. Sólo tengo una observación:
Q Library
CRÉDITO: https://github.com/kriskowal/q
La biblioteca Q es una de las más usadas y antiguas asociadas a “Promesas”. Por eso padece ejemplos desactualizados y la necesidad de mantener compatibilidad retroactiva.
Digo “asociada a ‘Promesas’” porque considero que Q trata realmente del patrón deferred.
Puede parecerse a Promesas, sin embargo insisto en que no lo es. Tiene una superficie de API excesivamente grande por todas las razones equivocadas. Además, la convención de nombres abrevia de forma inconsistente, lo que dificulta memorizar la interfaz. Métodos como when y done son innecesarios.
Conclusión: el patrón deferred es un anti‑patrón doloroso; apenas mejora algo respecto al enfoque típico de callbacks.
Por favor, revisa (& estrella) el proyecto complementario en Github de este artículo, Escape From Callback Mountain
Objetivo del proyecto: investigar y desarrollar mejores patrones funcionales en JavaScript.