Creo que necesitamos una forma general de hacer esto, que sea específica y agnóstica al Componente de Tema, como la que tenemos ahora.
Tengo otro Componente de Tema que utiliza esta técnica:
Así que son al menos dos por mi parte, y puede que haya más.
Estoy de acuerdo. He creado una colección de componentes de bloques, cada uno independiente, en lugar de agruparlos en un solo paquete: Blocks · GitLab.
Ahora mismo puedo poner estos bloques en una página de inicio dedicada con mi componente Homepage Blocks, al igual que puedo usarlos con Right Sidebar Blocks, o en Bars.
Recientemente hice una prueba con el tema Central donde necesitaba un diseño de barra lateral personalizado. Podría construir fácilmente un marco de bloques para una barra lateral personalizada y poner componentes de bloques en él: https://central.kostka.studio (además de poner el componente Powered-by-discourse en la barra lateral, simplemente haciendo referencia a él por su nombre)
Los componentes de bloques independientes son realmente la herramienta más útil que tengo ahora mismo para construir personalizaciones para clientes de una manera flexible y mantenible. Sería genial tener un camino general para apoyar esto.
Me gustaría reactivar este tema, ya que estoy intentando averiguar la mejor manera de manejar mis componentes. Actualmente veo dos opciones que tienen inconvenientes importantes: podría crear un registro por componente de tema que renderice bloques, pero eso anula el propósito modular. O añadir uno globalmente a través de un plugin, pero entonces mis componentes dependerían de que ese plugin esté instalado.
Por lo tanto, parece que tener una API de registro de bloques global en el núcleo ayudaría mucho. Algo que los componentes de tema podrían usar para invocar la renderización de bloques y también para registrar nuevos bloques.
Me encanta trabajar con el enfoque de bloques porque me permite separar las preocupaciones entre el diseño de la aplicación y el contenido del componente. El componente de bloque solo se encarga de renderizar su contenido, y luego es renderizado por otro componente en la aplicación. Puedo eliminar toda la lógica de rutas y outlets del componente de bloque, y puedo reutilizar fácilmente el mismo bloque varias veces en un diseño e incluso en toda la aplicación.
Encuentro que hace que todo sea más ágil y reutilizable, y es un enfoque elegante en general. Sería genial tener un soporte sólido para este patrón en Discourse.
David, ¿sería factible tener una API discrecional para registrar componentes de “temas/plugins cruzados” para su uso en otro plugin/componente?
Eso evitaría registrar todo, pero aún proporcionaría la flexibilidad para hacerlo explícitamente posible.
No estoy seguro de una API genérica para esto. Hay demasiadas formas de usar los componentes, y todas tienen expectativas diferentes con respecto a los argumentos y el momento de la carga.
Para su caso de uso, ¿funcionaría un registro específico de temas/plugins? Como la maqueta anterior para right-sidebar-blocks?
Si no es así, proporcionar algunos ejemplos concretos podría ayudarnos a determinar exactamente qué tipo de API se necesita. Todos los temas y plugins mantenidos por CDCK han sido migrados a gjs, y este no es un problema que hayamos encontrado (excepto por los casos específicos como right-sidebar-blocks).
Sí, de hecho, al releer más atentamente lo que escribiste en el Draft PR me lleva a creer que esta es una solución suficientemente buena, específicamente:
“Este commit introduce una lista dedicada de componentes de Right Sidebar Blocks, y permite que otros temas/plugins registren componentes adicionales.”
Creo que eso es clave: poder registrarse remotamente como compatible con otro tema y luego permitir que el tema “maestro” incorpore los elementos registrados remotamente es exactamente lo que busco, así que creo que ya has demostrado que esto es posible.
¡Genial!
En casos muy simples, incluso podrías arreglártelas añadiendo un PluginOutlet en el tema “maestro”, y luego otros temas pueden usar renderInOutlet (o poner un archivo en connectors/...).
También es cierto. Sin embargo, me gusta mucho tu patrón de registro, muy bueno. Sería bueno mantener la compatibilidad con RSB en realidad (Bars ya utiliza el mismo sistema de parámetros) para que todo el sistema sea interoperable (aunque tener dos inicializadores podría ser un desafío, o potencialmente no necesitaría uno adicional si pudiera desactivar la capa de diseño de RSB, por lo que podría simplemente cargar RSB en su totalidad y reutilizarla 
)