J’ai déjà posé la question sur la façon de configurer l’environnement local pour coder plus rapidement lors de la création d’un plugin, et je sais que d’autres l’ont fait aussi.
J’utilise un nouveau flux de travail qui fonctionne très bien, et j’ai pensé le partager au cas où il serait utile à d’autres. Il ne résout pas tout, mais rend les choses beaucoup plus agréables. Voici les détails :
Tout d’abord, mon problème précédent :
Pour développer un plugin, je devais coder à partir d’une instance locale de Discourse, et c’était très lent car : 1) tout changement de fichier nécessitait de recharger la page, et mon ordinateur le faisait très lentement lorsqu’il exécutait Discourse (environ 30 secondes par rechargement de page), 2) le site Discourse local pour le développement sur lequel je testais était très lent (lent à naviguer, etc.), et 3) tout changement dans le code backend du plugin nécessitait d’arrêter le serveur et de le redémarrer - et cela pouvait prendre quelques minutes. Pendant tout ce temps, le ventilateur de mon ordinateur tournait à plein régime.
En conséquence, il me fallait probablement une heure de codage pour faire ce que je pouvais normalement coder en 10 minutes avec un flux de travail fluide.
Ma Solution
Contrairement au développement d’un plugin, le flux de travail pour coder un composant de thème est génial, grâce au Discourse theme CLI. (Mes étapes pour l’utiliser sont ici.) C’est rapide et fluide.
Pourquoi coder un thème ou un composant de thème est tellement plus rapide et plus facile
Avec l’outil theme CLI, vous pouvez coder un thème localement, mais le “surveiller” (c’est-à-dire exécuter le thème) sur un site en direct (soit votre site réel, votre site réel mais juste en mode aperçu, soit un site de test en direct que vous avez configuré).
Vous n’avez donc pas besoin d’exécuter Discourse lui-même sur votre machine - et par conséquent, ma machine ne ralentit pas comme elle le ferait avec un plugin. Et chaque fois que vous apportez une modification, il vous suffit de rafraîchir le site en direct auquel vous êtes lié, et la modification est là.
Alors, j’ai réalisé : la plupart du temps lorsque je code un plugin, il s’agit en fait de choses côté front-end (fichiers hbs, fichiers javascript, etc.). Et seulement une petite partie est consacrée aux choses côté backend (configuration des routes, création de champs personnalisés, etc.).
Au lieu de tout coder ensemble, déplacez donc tout le codage front-end vers un composant de thème, pour profiter du flux de travail des composants de thème.
Lorsque je dois mettre à jour les choses côté backend dans le plugin, alors je dois à nouveau coder dans le plugin - mais cela ne représente qu’environ 20 % du temps (dans mon développement de plugin en tout cas). Me permettant ainsi de passer 80 % de mon temps avec le flux de travail beaucoup plus agréable des composants de thème.
Quand il sera temps de tout déplacer en production, je pourrai :
-garder le composant de thème et le plugin séparés, et les utiliser tous les deux sur le site Discourse pertinent, ou
-s’il est important d’avoir tout le code au même endroit, déplacer à ce moment-là le code du composant de thème dans le plugin. Certes, cela peut être un peu fastidieux, mais vous n’auriez à le faire qu’une fois que vous êtes prêt à mettre à jour pour la production, tout en profitant du flux de travail plus rapide des composants de thème.
C’est tout.
Ce n’est pas révolutionnaire. Mais cela a beaucoup amélioré quelque chose qui m’avait bloqué pendant un certain temps.