Je pense que nous avons besoin d’un moyen général de faire cela, qui soit indépendant des composants de thème spécifiques – comme nous l’avons maintenant.
J’ai un autre composant de thème qui utilise cette technique :
Donc, il y en a au moins deux de mon côté, et il peut y en avoir d’autres.
Je suis d’accord. J’ai créé une collection de composants de blocs, chacun autonome, plutôt que regroupés dans un seul package : Blocks · GitLab.
Pour l’instant, je peux placer ces blocs sur une page d’accueil dédiée avec mon composant Homepage Blocks, tout comme je peux les utiliser avec Right Sidebar Blocks, ou sur Bars.
J’ai récemment fait une expérimentation sur le thème Central où j’avais besoin d’une disposition de barre latérale personnalisée. Je pouvais facilement créer un framework de blocs pour une barre latérale personnalisée et y placer des composants de blocs : https://central.kostka.studio (ainsi que placer le composant Powered-by-discourse sur la barre latérale, simplement en le référençant par son nom).
Les composants de blocs autonomes sont vraiment l’outil le plus utile dont je dispose actuellement pour créer des personnalisations client de manière flexible et maintenable. Ce serait formidable d’avoir une voie générale pour soutenir cela.
J’aimerais relancer ce sujet car j’essaie de trouver la meilleure façon de gérer mes composants. Actuellement, je vois deux options qui ont toutes deux des inconvénients majeurs : je pourrais créer un registre par composant de thème qui rend des blocs, mais cela va un peu à l’encontre de l’objectif modulaire. Ou en ajouter un globalement via un plugin, mais alors mes composants deviendraient dépendants de l’installation de ce plugin.
Il semble donc qu’une API d’enregistrement de blocs globale dans le cœur serait très utile. Quelque chose que les composants de thème pourraient utiliser pour invoquer le rendu de blocs et également pour enregistrer de nouveaux blocs.
J’adore travailler avec l’approche par blocs car elle me permet de séparer les préoccupations entre la disposition de l’application et le contenu du composant. Le composant de bloc gère simplement le rendu de son contenu, puis est rendu par un autre composant de l’application. Je peux supprimer toute la logique de routage et d’outlet du composant de bloc, et je peux facilement réutiliser le même bloc plusieurs fois dans une disposition et même dans toute l’application.
Je trouve que cela rend tout plus léger et plus réutilisable, et c’est une approche élégante dans l’ensemble. Un support solide pour ce modèle dans Discourse serait formidable.
David, serait-il faisable d’avoir une API discrétionnaire pour enregistrer des composants « cross theme/plugins » pour une utilisation dans un autre plugin/composant ?
Cela éviterait d’enregistrer tout, mais offrirait toujours la flexibilité de le rendre explicitement possible.
Je ne suis pas sûr d’une API générique pour cela. Il y a tout simplement trop de façons d’utiliser les composants, et elles ont toutes des attentes différentes concernant les arguments et le moment du chargement.
Pour votre cas d’utilisation, un registre spécifique au thème/plugin fonctionnerait-il ? Comme la maquette ci-dessus pour right-sidebar-blocks ?
Sinon, fournir des exemples concrets pourrait nous aider à déterminer exactement le type d’API nécessaire. Tous les thèmes et plugins maintenus par CDCK ont été migrés vers gjs, et ce n’est pas un problème que nous ayons rencontré (sauf pour les cas spécifiques comme right-sidebar-blocks).
Oui, en fait, en relisant plus attentivement ce que vous avez écrit sur la Pull Request (PR) de brouillon, je pense que c’est une solution suffisamment bonne, spécifiquement :
« Cet commit introduit une liste dédiée de composants de blocs de la barre latérale droite, et permet à d’autres thèmes/plugins d’en enregistrer d’autres. »
Je pense que c’est la clé : être capable de s’enregistrer à distance comme compatible avec un autre thème et ensuite permettre au thème « maître » d’incorporer les éléments enregistrés à distance est exactement ce que je recherche, donc je pense que vous avez déjà démontré que c’est possible.
Génial !
Dans des cas très simples, vous pourriez même vous en sortir en ajoutant un PluginOutlet dans le thème « master », et d’autres thèmes peuvent alors utiliser renderInOutlet (ou placer un fichier dans connectors/...).
C’est vrai aussi. Cependant, j’aime beaucoup votre modèle d’enregistrement, très joli. Il serait bon de conserver la compatibilité avec RSB en fait (Bars utilise déjà le même système de paramètres) afin que l’ensemble du système devienne interopérable (bien qu’avoir deux initialisateurs puisse être un défi - ou potentiellement ne nécessitera pas d’initialiseur supplémentaire si je pouvais désactiver la couche de disposition RSB, je pourrais donc simplement charger RSB dans son intégralité et réutiliser 
)