He preguntado anteriormente sobre cómo configurar el entorno local para codificar más rápido al crear un plugin, y sé que otros también lo han hecho.
He estado utilizando un nuevo flujo de trabajo que ha funcionado muy bien y pensé en compartirlo por si es útil para otros. No lo resuelve todo, pero hace las cosas mucho más agradables. Aquí están los detalles:
Primero, mi problema anterior:
Para desarrollar un plugin, tenía que codificar desde una instancia local de Discourse, y esto era muy lento porque: 1) cualquier cambio en los archivos requería recargar la página, y mi computadora lo hacía muy lentamente cuando ejecutaba Discourse (unos 30 segundos por recarga de página), 2) el sitio local de Discourse para desarrollo en el que probaba sería muy lento (lento para navegar, etc.), y 3) cualquier cambio en el código del plugin del backend requeriría detener el servidor y reiniciarlo, lo que podía llevar unos minutos. Todo el tiempo, el ventilador de mi computadora estaría a toda potencia.
Como resultado, probablemente me llevaría una hora de codificación hacer lo que normalmente podría codificar en unos 10 minutos con un flujo de trabajo fluido.
Mi Solución
En contraste con el desarrollo de un plugin, el flujo de trabajo para codificar un componente de tema es increíble, gracias a la CLI de temas de Discourse. (Mis pasos para usarla están aquí.) Es rápido y fluido.
Por qué codificar un tema o componente de tema es mucho más rápido y fácil
Con la herramienta CLI de temas, puedes codificar un tema localmente, pero “vigilarlo” (es decir, ejecutar el tema) en un sitio en vivo (ya sea tu sitio real, tu sitio real pero solo en modo de vista previa, o un sitio de prueba en vivo que hayas configurado).
Así que en realidad no necesitas ejecutar Discourse en tu máquina, y por lo tanto mi máquina no se ralentiza como lo haría con un plugin. Y cada vez que haces un cambio, simplemente actualizas el sitio en vivo al que estás conectado, y el cambio está ahí.
Entonces, me di cuenta: la mayor parte del tiempo cuando codifico un plugin, en realidad es en el código del lado del cliente (archivos hbs, archivos javascript, etc.). Y solo una pequeña parte se dedica a las cosas del lado del servidor (configurar rutas, crear campos personalizados, etc.).
En lugar de codificar todo junto, entonces, simplemente mueve toda la codificación del lado del cliente a un componente de tema, para aprovechar el flujo de trabajo del componente de tema.
Cuando tenga que actualizar las cosas del lado del servidor en el plugin, entonces tendré que codificar en el plugin nuevamente, pero eso es solo alrededor del 20% del tiempo (en mi desarrollo de plugins de todos modos). Lo que me permite pasar el 80% de mi tiempo con el flujo de trabajo mucho más agradable del componente de tema.
Cuando llegue el momento de mover todo a producción, puedo:
- Mantener el componente de tema y el plugin separados, y simplemente usarlos ambos en el sitio de Discourse relevante, o
- Si es importante tener todo el código en un solo lugar, en ese momento mover el código del componente de tema al plugin. Admito que puede ser un poco tedioso, pero solo tendrías que hacerlo una vez que estés listo para actualizar para producción, mientras disfrutas del flujo de trabajo más rápido del componente de tema.
Eso es todo.
No es revolucionario. Pero ha hecho las cosas mucho mejor en algo que me ha frenado durante un tiempo.