Il y a eu une discussion il y a quelque temps sur le développement dans un thème par rapport à un plugin. La partie Rails de https://www.pfaffmanager.com/ commence à être assez stable, et ce que j’aimerais faire est de déplacer le développement de la partie Rails dans un composant de thème. Cela fonctionne assez bien, et les changements dans les templates et les initializers du composant de thème remplacent le plugin comme prévu. Mais, les changements dans javascripts/discourse/components/server-item.js.es6 dans le thème ne remplacent pas les mêmes fichiers dans le plugin.
Je suppose que je pourrais supprimer entièrement le code Ember du plugin et ne le faire exister que dans le thème, mais cela semble être une journée de travail pour déplacer, tester et déployer toutes ces pièces sur le serveur. Pourrais-je manquer quelque chose de simple ? Devrais-je l’accepter et supprimer complètement du plugin les éléments que j’aimerais avoir dans le composant de thème ? Devrais-je tout garder dans le plugin ?
Avoir le même code dans le composant de thème et le plugin me semble un peu étrange - à mon avis, il serait préférable de choisir entre le composant de thème/plugin, puis de s’y consacrer entièrement. Redéfinir des fichiers entiers n’est pas quelque chose que nous faisons nous-mêmes, et ce n’est pas quelque chose que nous recommandons. Pour redéfinir le comportement du cœur/plugin, votre composant de thème devrait utiliser des méthodes comme api.modifyClass.
Je soupçonne que la cause première ici est que les modules ES6 des plugins sont préfixés différemment des modules du cœur/thème. En exécutant ceci sur votre site, je vois que les modules sont préfixés par plugin. Je soupçonne que si vous activiez le composant de thème, nous verrions une autre entrée, mais avec un préfixe différent.
Je suis d’accord en général, cependant, il existe quelques cas limites :
Lorsque le volume de changements apportés au javascript dépasse de loin les changements apportés au backend, auquel cas les composants de thème sont un excellent moyen de déployer et de tester rapidement le code.
Lorsque la plupart des fonctionnalités peuvent être livrées dans le composant de thème de base, mais l’ajout d’un plugin complémentaire peut ajouter des fonctionnalités supplémentaires impossibles en javascript seul. J’emploie cette technique dans les aperçus de listes de sujets, où le composant fait 90 % de ce dont le module complémentaire est capable, mais si vous ajoutez également le plugin, vous obtenez des fonctionnalités supplémentaires intéressantes.
Cela dit, regrouper tout dans un plugin a du sens car il y a moins de confusion concernant la configuration et l’installation, et tout est toujours synchronisé.
Mais même dans votre scénario plugin+thème, je ne dupliquerais pas le code Ember dans le plugin et le thème. J’aurais donc besoin de retirer au moins la plupart des modèles, initialisations, composants, du plugin pour les avoir uniquement dans le composant du thème.
Comme je suis le seul à être confus au sujet de la configuration, ce n’est pas un gros problème. J’aime beaucoup l’idée de pouvoir tester de nouvelles choses front-end sur le site en direct en passant à la version bêta du thème.
L’autre problème que je vois concerne les tests qunit. (Je vais prétendre que je peux trouver comment en ajouter, ce qui est un autre problème en soi ; je pense que mon problème est que je ne sais pas comment amorcer les tests avec des données pour ce qui doit être affiché…). Je pense que si j’ai des tests qunit dans mon plugin, ils seront exécutés lorsque je pousserai sur GitHub (parce que je suis à peu près sûr d’avoir vu mes tests échoués).
Puis-je obtenir un composant de thème pour faire de même ?
Techniquement, cela devrait être possible, mais je ne pense pas que nous ayons encore de workflows d’actions GitHub prêts à l’emploi pour les thèmes. Les tests de thèmes font actuellement l’objet d’une refonte (pour la transition vers ember-cli), mais après cela, nous pourrons peut-être ajouter des modèles de workflow de test de thèmes à GitHub - discourse/.github.
Scénario : Je veux remplacer un modèle déployé dans un plugin. Mais je veux le remplacer d’une manière contrôlée par le code.
J’ai donc essayé d’expédier le nouveau modèle dans un composant de thème. Le même fichier existe dans un plugin (mais il est différent).
Cela semble fonctionner sur mon installation cloud de développement, mais pas sur une installation de production standard.
Est-il donc juste de dire que vous ne pouvez pas prédire si cela réussira ou non avec les modèles ? C’est-à-dire que le pipeline d’assets est tel que vous ne pouvez pas prédire quel « modèle » sera conservé car il n’y a pas de précédence prédéfinie ou prévisible ?
J’ai travaillé avec une hypothèse étrange selon laquelle il y avait une hiérarchie, quelque chose comme :
cœur
plugin
composant de thème
modifications du site local
Et si vous placiez un « fichier » avec le même chemin et le même nom dans un niveau ultérieur de cette hiérarchie, il remplacerait toute définition « précédente ».
Mais mon hypothèse n’est probablement pas sûre ?
La seule solution « packagée » (en excluant les modifications du site local) est donc de forker le plugin et de faire les modifications directement à l’intérieur ?
Ce serait dommage dans un sens, car cela augmenterait l’effort de maintenance pour les personnalisations, car vous devriez fusionner périodiquement les modifications du dépôt principal du plugin…
La meilleure façon serait de mettre à jour le plugin existant et de lui donner un point d’extension de plugin et/ou une API de personnalisation que le composant de thème peut utiliser.
Mon commentaire ci-dessus concernait spécifiquement le remplacement de fichiers JS entiers (c’est-à-dire les modules es6). Ce n’est pas possible. Le pipeline d’assets préfixe automatiquement les modules de plugin/thème avec le nom/ID du plugin/thème, il est donc impossible de créer un conflit avec le cœur.
Pour les modèles, nous savons que les gens (y compris nous, dans certaines situations) les remplacent, nous continuerons donc probablement à faire fonctionner ce système. Mais n’oubliez pas que c’est un hack. Si le composant/contrôleur d’origine modifie son comportement, votre modèle remplacé provoquera probablement une panne du site.
En général, je pense que la hiérarchie que vous avez mentionnée (cœur, plugin, thème) devrait être vraie - donc si vous voyez quelque chose de différent, veuillez partager les détails des chemins de fichiers dans le plugin et le thème.
