online convertir coffee coffeescript jquery-deferred iced-coffeescript

convertir - IcedCoffeeScript o jQuery diferido



js to coff (4)

Creo que IcedCoffeeScript llegó para quedarse.

Planeo apoyarlo indefinidamente, y soy bastante regular en parcharlo contra la línea principal. Lo uso en casi todos mis proyectos personales, y el sitio Combosaurus.com, un proyecto de OkCupid Labs a punto de llegar a la versión general, está escrito en IcedCoffeeScript.

Recientemente, mientras trabajaba en un proyecto Backbone.JS / jQuery / CoffeeScript, me encontré en un lío de problemas de devolución de llamada y sincronización. Tenía que esperar a que se completara algo antes de continuar y me encontré en un lío de devoluciones de llamada anidadas ... que es confuso y difícil de depurar. Luego encontré 2 soluciones posibles jQuery diferido o IcedCoffeeScript

IcedCoffeeScript ve muy fácil, simplemente agrega await y defer . Sin embargo, me pregunto si está allí para quedarse? ¿Solo 2 preguntas aquí en StackOverflow? No se habla mucho de eso en comparación con CoffeeScript

Otra cosa es ¿cuál es la diferencia entre los 2 métodos, que parecen hacer más o menos lo mismo? Excepto en IcedCoffeeScript, se parece más al código de procedimiento, y en jQuery diferido, no resuelve tanto mi error de devoluciones de llamada


Escribí una publicación en el blog sobre las diferencias entre las devoluciones de llamada de eventos estándar, pub sub y diferidos, que podrían ayudarlo:

Event Emitter, Pub Sub o Deferred Promises ... ¿cuál elegir?

La introducción lee:

La respuesta obvia a la pregunta "si elige un Emisor de eventos, Pub Sub o Deferred / Promises" es que depende de lo que esté haciendo.

En esta publicación, exploraré un poco sobre cómo funciona cada patrón con implementaciones (muy) básicas, y luego veré las razones por las que puede elegir una sobre otra.

Y el resumen es:

Event Emitter es un clásico real, y permite buenas prácticas y control sobre las cosas que suceden; Pub Sub es más flexible para eventos de componentes cruzados; Deferred y Promises ofrecen una forma poderosa de gestionar las devoluciones de llamada.

Aplicando el resumen a su problema - Sugeriría que Deferred''s and Promises probablemente lo ayuden mucho.

No sé ustedes, pero descubrí que cómo implementaría Deferred realmente me ayudó a comprender las complejidades de su uso. También he incluido un código de muestra en la publicación, que al ser (extremadamente) simple, podría ayudarte cuando mires el intento más robusto de otra persona.


Estas son tecnologías muy diferentes:

  • IcedCoffeeScript es un precompilador que amplía CoffeeScript con la opción de await y defer palabras clave que transforman el código para que pueda escribir código en un estilo sincrónico. En el JavaScript generado, await y defer producir funciones anidadas.

  • jQuery Deferred (también conocido como Promesas ) son una forma de devolución de llamada lateral por completo: en lugar de tomar una devolución de llamada, una función asíncrona puede devolver una Promesa. Luego adjuntas devoluciones de llamada a la Promesa. Es una técnica simple pero poderosa. Le dedico un capítulo en mi libro, Async JavaScript .

Cada una de estas tecnologías funciona mejor con cierto tipo de API. await y defer esperan que una función tome una sola devolución de llamada como último argumento. Las promesas funcionan mejor cuando tienes muchas otras promesas en tu aplicación.

No hay una solución mágica para lidiar con el comportamiento asíncrono en JavaScript. Necesita comprender las devoluciones de llamada, Promises y PubSub (también EventEmitter como EventEmitter s) y elegir la mejor herramienta para cada trabajo. Incluso si usa IcedCoffeeScript (que es genial), todavía hay momentos en que Promises le ahorrará una gran cantidad de trabajo.

Espero que eso ayude. Echa un vistazo a mi libro, Async JavaScript , para obtener más información.


Oh, definitivamente confiaría en IcedCoffeeScript. Si te gusta y usas la sintaxis de CoffeeScript, descubrirás que simplemente "se mezcla" naturalmente con ella ...

Respecto al futuro del proyecto, tuve el mismo dilema hace un tiempo, pero parece que Maxwell Krohn lo está manteniendo activamente y hay una creciente comunidad y conciencia sobre ello (vale, quizás no aquí en todavía).

Empecé a usarlo el año pasado y ahora no podía imaginarme la codificación de aplicaciones de la "vida real" sin await y defer .

Puede encontrar una breve "protuberancia" sobre el elegante flujo de control asincrónico con ICS aquí y también escribí un artículo de 5 partes irónicamente titulado sobre el uso de Node.js para proyectos web genéricos aquí que mencionan ICS.