Hubo una discusión de alguien hace un tiempo sobre el desarrollo en un tema vs un plugin. La parte de Rails de https://www.pfaffmanager.com/ está empezando a ser bastante estable, y lo que me gustaría hacer es mover el desarrollo de la parte de Rails a un componente de tema. Esto está funcionando bastante bien, y los cambios en las plantillas e inicializadores en el componente de tema están anulando el plugin como se esperaba. Pero, los cambios en javascripts/discourse/components/server-item.js.es6 en el tema no están anulando los mismos archivos en el plugin.
Supongo que podría eliminar por completo las cosas de Ember del plugin y que solo existan en el tema, pero eso parece un día de trabajo para mover, probar y enviar todas esas piezas al servidor. ¿Podría estar pasando por alto algo tonto? ¿Debería aguantarme y eliminar por completo las cosas que me gustaría tener en el componente del tema del plugin? ¿Debería mantenerlo todo en el plugin?
Tener el mismo código tanto en el componente del tema como en el plugin me parece un poco extraño. En mi opinión, sería mejor decidir entre el componente del tema/plugin y luego apostar por ello por completo. Sobrescribir archivos completos no es algo que hagamos nosotros mismos, y no es algo que recomendemos. Para sobrescribir el comportamiento del núcleo/plugin, tu componente del tema debería usar métodos como api.modifyClass.
Sospecho que la causa raíz aquí es que los módulos ES6 de los plugins se prefijan de manera diferente a los módulos del núcleo/tema. Al ejecutar esto en tu sitio, veo que los módulos se prefijan con plugin. Sospecho que si habilitaras el componente del tema, veríamos otra entrada, pero con un prefijo diferente.
Estoy de acuerdo en general, sin embargo, hay algunos casos extremos:
Donde el volumen de cambios en javascript supera con creces los cambios en el backend, en cuyo caso los Componentes Temáticos son una excelente manera de implementar y probar implementaciones de código RÁPIDAMENTE.
Donde la mayor parte de la funcionalidad se puede entregar en el Componente Temático base, pero agregar un plugin complementario puede agregar características adicionales que no son posibles solo en Javascript. Empleo esta técnica en las Vistas Previas de la Lista de Temas, donde el Componente hace el 90% de lo que es capaz el complemento, pero si también agregas el plugin, obtienes algunas cosas geniales adicionales.
Dicho esto, empaquetar todo en un plugin tiene sentido, ya que hay menos confusión en la configuración y la instalación, y todo se mantiene siempre sincronizado.
Pero incluso en tu escenario de plugin+tema, no duplicaría el código de Ember tanto en el plugin como en el tema. Así que necesitaría extraer al menos la mayoría de las plantillas, inicializadores y componentes del plugin y tenerlos solo en el componente del tema.
Dado que soy el único que se confundirá con la configuración, eso no es un gran problema. Me gusta mucho la idea de poder probar algunas cosas nuevas de front-end en el sitio en vivo cambiando a la versión beta del tema.
El otro problema que veo son las pruebas de qunit. (Fingiré que puedo averiguar cómo agregar alguna, lo cual es otro problema por completo; creo que mi problema es que no sé cómo sembrar las pruebas con datos para que se muestre el contenido…). Creo que si tengo pruebas de qunit en mi plugin, se ejecutarán cuando haga push a GitHub (porque estoy bastante seguro de que he visto fallar las mías).
¿Puedo obtener un componente temático para hacer lo mismo?
Técnicamente debería ser posible, pero no creo que todavía tengamos flujos de trabajo de GitHub Actions listos para temas. Las pruebas de temas están experimentando una revisión actualmente (para la transición de ember-cli), pero después de eso, tal vez podamos agregar algunas plantillas de flujo de trabajo de pruebas de temas a GitHub - discourse/.github.
Escenario: Quiero sobrescribir una plantilla implementada en un plugin. Pero quiero sobrescribirla de una manera controlada por código.
Así que intenté enviar la nueva plantilla en un componente de tema. El mismo archivo existe en un plugin (pero es diferente).
Esto parece funcionar en mi instalación de nube de desarrollo, pero no en una instalación de producción estándar.
Entonces, ¿es justo decir que no se puede predecir si esto tendrá éxito o no con las plantillas? Es decir, el pipeline de activos es tal que no se puede predecir qué ‘plantilla’ prevalecerá ya que no hay una precedencia predefinida o predecible.
He estado trabajando con una suposición extraña de que existía una jerarquía, algo como:
núcleo
plugin
componente de tema
cambios locales del sitio
Y si colocabas un “archivo” con la misma ruta y nombre en un nivel posterior de esa jerarquía, sobrescribiría cualquier definición “anterior”.
¿Pero mi suposición probablemente no es segura?
¿Es la única solución “empaquetada” (descartando los cambios locales del sitio) bifurcar el plugin y hacer los cambios directamente dentro de él?
Eso en algunos sentidos sería una pena, ya que aumentaría el esfuerzo de mantenimiento para las personalizaciones, ya que tendrías que fusionar los cambios del repositorio principal del plugin periódicamente…
La mejor manera sería actualizar el plugin existente y darle una salida de plugin y/o una API de personalización que el componente del tema pueda usar.
Mi comentario anterior se refería específicamente a la anulación de archivos JS completos (es decir, módulos es6). Eso no es posible. El pipeline de activos antepone automáticamente los módulos de plugin/tema con el nombre/ID del plugin/tema, por lo que es imposible crear un conflicto con el núcleo.
Para las plantillas, sabemos que la gente (incluidos nosotros, en algunas situaciones) las anula, por lo que probablemente mantendremos ese sistema funcionando. Pero recuerde que es un hack. Si el componente/controlador original cambia su comportamiento, su plantilla anulada probablemente hará que el sitio se rompa.
En general, creo que la jerarquía que mencionó (núcleo, plugin, tema) debería ser cierta; por lo tanto, si está viendo algo diferente, comparta los detalles de las rutas de los archivos en el plugin y el tema.
