Insidie nella Documentazione delle Promise
Evitare problemi da documentazione comune
Individuare anti-pattern delle Promise nei risultati di ricerca Google e nelle librerie popolari.
Inizio con una confessione: sono colpevole di aver scritto gli stessi “anti-pattern” che criticano qui sotto, come probabilmente molti sviluppatori JS hanno fatto anch’essi. Nulla di ciò che ho esposto è inteso come personale né diretto agli autori originali. Sto semplicemente effettuando una revisione di codice su pattern comuni - spero di trasmettere una comprensione delle mie priorità e del mio processo di pensiero critico.
Spero che, dopo aver compreso questo progetto, sarete in grado di riconoscere i segnali d’allarme delle cattive Promises.
CallbackHell.com
CREDIT: http://callbackhell.com/
StrongLoop
CREDIT:
https://strongloop.com/strongblog/node-js-callback-hell-promises-generators/
RisingStack
CREDIT: https://blog.risingstack.com/node-js-async-best-practices-avoiding-callback-hell-node-js-at-scale/ Questo è un articolo abbastanza solido. Ho un solo problema:
Q Library
CREDIT: https://github.com/kriskowal/q
La libreria Q è una delle più utilizzate e antiche ad essere associata alle “Promises”. Per questo motivo soffre di esempi datati e della necessità di mantenere la compatibilità con le versioni precedenti.
Dico “associata alle ‘Promises’” perché ritengo che Q si basi veramente sul pattern deferred.
Potrebbe assomigliare alle Promises, ma insisto: non lo è. Ha una superficie di API troppo estesa per tutti i motivi sbagliati. Inoltre, la convenzione di denominazione abbrevia i nomi in modo inconsistente, rendendo più difficile memorizzare l’interfaccia. Metodi come when e done non sono necessari.
In sintesi: il pattern differito è un anti-pattern doloroso - migliora virtualmente nulla rispetto all’approccio tipico basato su callback.
Guarda (& stellal) il progetto GitHub associato a questo articolo, Escape From Callback Mountain
Obiettivo del progetto: ricerca e sviluppo di meglio pattern linguistici funzionali in JavaScript.