Penso che abbiamo bisogno di un modo generale per farlo, che sia specifico e indipendente dal componente del tema, come abbiamo ora.
Ho un altro componente del tema che utilizza questa tecnica:
Quindi ce ne sono almeno due da parte mia, e potrebbero essercene altri.
Sono d’accordo. Ho creato una raccolta di componenti a blocchi, ognuno autonomo, anziché raggruppato in un unico pacchetto: Blocks · GitLab.
Al momento posso inserire questi blocchi su una homepage dedicata con il mio componente Homepage Blocks, così come posso usarli con Right Sidebar Blocks, o su Bars.
Recentemente ho fatto una prova sul tema Central in cui avevo bisogno di un layout di barra laterale personalizzato. Potrei facilmente costruire un framework di blocchi per una barra laterale personalizzata e inserirci componenti a blocchi: https://central.kostka.studio (oltre a inserire il componente Powered-by-discourse nella barra laterale, semplicemente facendovi riferimento per nome)
I componenti a blocchi autonomi sono davvero lo strumento più utile che ho al momento per creare personalizzazioni per i clienti in un approccio flessibile e manutenibile. Sarebbe fantastico avere un percorso generale per supportare questo.
Vorrei sollecitare questo punto perché sto cercando di capire il modo migliore per gestire i miei componenti. Al momento vedo due opzioni che hanno entrambe notevoli svantaggi: potrei creare un registro per ogni componente del tema che renderizza blocchi, ma ciò vanifica in parte lo scopo modulare. Oppure aggiungerne uno globalmente tramite un plugin, ma poi i miei componenti diventano dipendenti dall’installazione di quel plugin.
Quindi sembra che avere un’API di registrazione globale dei blocchi nel core aiuterebbe molto. Qualcosa che i componenti del tema potrebbero usare per invocare il rendering dei blocchi e anche per registrare nuovi blocchi.
Mi piace lavorare con l’approccio a blocchi perché mi permette di separare le preoccupazioni tra il layout dell’app e il contenuto del componente. Il componente blocco gestisce semplicemente il rendering del suo contenuto, quindi viene renderizzato da un altro componente nell’app. Posso eliminare tutta la logica di route e outlet dal componente blocco e posso facilmente riutilizzare lo stesso blocco più volte in un layout e persino in tutta l’app.
Trovo che renda tutto più snello e riutilizzabile ed è un approccio elegante nel complesso. Avere un solido supporto per questo pattern in Discourse sarebbe fantastico.
David, sarebbe fattibile avere un’API discrezionale per registrare componenti “cross theme/plugin” da utilizzare in un altro plugin/componente?
Ciò eviterebbe di registrare tutto, ma fornirebbe comunque la flessibilità per renderlo esplicitamente possibile.
Non sono sicuro di una API generica per questo. Ci sono troppi modi per usare i componenti, e tutti hanno aspettative diverse riguardo agli argomenti e ai tempi di caricamento.
Per il tuo caso d’uso, un registro specifico per temi/plugin funzionerebbe? Come la simulazione sopra per right-sidebar-blocks?
In caso contrario, fornire alcuni esempi concreti potrebbe aiutarci a capire esattamente che tipo di API è necessaria. Tutti i temi e i plugin mantenuti da CDCK sono stati migrati a gjs, e questo non è un problema che abbiamo riscontrato (ad eccezione dei casi specifici come right-sidebar-blocks).
Sì, in effetti, rileggendo più attentamente ciò che hai scritto nella bozza di PR mi porta a credere che questa sia una soluzione sufficientemente buona, in particolare:
“Questa commit introduce un elenco dedicato di componenti Right Sidebar Blocks e consente ad altri temi/plugin di registrarne di aggiuntivi.”
Penso che questo sia fondamentale: essere in grado di registrarsi da remoto come compatibile con un altro tema e quindi consentire al tema “master” di incorporare gli elementi registrati da remoto è esattamente ciò che sto cercando, quindi penso che tu abbia già dimostrato che questo è possibile.
Fantastico!
In casi molto semplici, potresti persino riuscire ad aggiungere un PluginOutlet nel tema “master”, e quindi altri temi possono usare renderInOutlet (o inserire un file in connectors/...).
Vero anche questo. Mi piace molto il vostro schema di registrazione, molto bello. Sarebbe bene mantenere la compatibilità con RSB in realtà (Bars usa già lo stesso sistema di parametri) in modo che l’intero sistema diventi interoperabile (anche se avere due inizializzatori potrebbe essere una sfida - o potenzialmente non ne servirà uno aggiuntivo se potessi disattivare lo strato di layout RSB, così potrei semplicemente caricare RSB nella sua interezza e riutilizzarlo 
)