Nos gustaría migrar el pipeline de activos de Discourse para que utilice EmberCLI. EmberCLI es la forma estándar de desarrollar aplicaciones Ember y el enfoque de Discourse ha sido durante mucho tiempo una fuente de confusión para quienes se acercan a nuestro proyecto con experiencia en Ember.js.
Antecedentes
Discourse lleva tanto tiempo en el mercado que existía antes de que apareciera EmberCLI; de hecho, en aquel momento se consideraba una buena práctica utilizar algo como el pipeline de activos de Rails. A lo largo de los años hemos ido añadiendo más y más a nuestra aplicación Ember, incluyendo módulos de JavaScript, Babel.js y mapas de origen, pero sentimos que hemos llevado el pipeline de activos de Rails hasta donde nos ha sido posible. Algunas nuevas características, como async/await, son muy difíciles de integrar en nuestro sistema actual.
En la próxima versión mayor de Discourse (2.5) planeamos migrar a EmberCLI. Esto llevará bastante tiempo, por lo que haremos todo lo posible para mantener funcionando dos versiones de nuestra aplicación frontend. Los usuarios más aventureros podrán optar por activar EmberCLI, mientras que los demás podrán seguir utilizando la aplicación “tal cual” hasta que lleguemos a un punto en el que consideremos que todo está estable.
Hoja de ruta
-
Migrar los patrones existentes a los patrones de EmberCLI: Ya hemos hecho un poco de esto en la versión 2.4. Básicamente, el objetivo es migrar gradualmente nuestro código JavaScript a un formato que se ajuste estrechamente a lo que espera Ember-CLI. Esto implica:
- importar todo desde las mismas rutas
- utilizar extensiones diferentes para handlebars raw / handlebars de Ember
- eliminar las advertencias de propiedades calculadas
- cambiar al módulo
Locationde Ember desde nuestro módulo personalizado
-
Iniciar Discourse mediante EmberCLI: Esto probablemente implicará encontrar nuevos problemas a medida que se solucionen los puntos de (1) y repetir el mismo enfoque.
-
Integrar componentes de temas y complementos: Necesitaremos investigar aquí para integrar las extensiones existentes de Discourse de la manera más transparente posible.
-
Identificar cualquier cuello de botella de rendimiento (u otros): debería ser tan rápido como nuestro sistema actual, o incluso más rápido.
-
Establecer un cronograma para el cambio: deberá ser generoso para que las personas tengan mucho tiempo para probar la función en fase beta y proporcionar comentarios.
Ventajas
Cuando hayamos completado la migración, muchas cosas que actualmente están rotas o son difíciles de realizar, como los mapas de origen y async/await, deberían funcionar sin problemas.
Además, para algunos desarrolladores que solo quieren trabajar en las partes frontend de Discourse, podríamos configurar las cosas de modo que puedan ejecutar EmberCLI apuntando a un servidor como try.discourse.org para modificar la aplicación frontend sin necesidad de ejecutar un servidor completo de Ruby/Rails con Redis/Postgres.
Este será un proyecto grande, pero al final nuestra aplicación estará mucho mejor gracias a ello.
Hay tantos generadores que Rails proporciona de forma predeterminada para complementos. Además, Discourse es la aplicación Rails de código abierto más grande, así que quizás sería bueno unir esfuerzos.
