Merci à tous.
J’avais déjà vu cela, mais je suis rassuré d’avoir la confirmation qu’il n’est pas possible d’ajouter des add-ons Ember tant que cette migration n’est pas terminée. Il semble donc que l’ajout d’add-ons Ember sera bientôt possible, une fois la mise à niveau achevée. Cela semble excellent.
Je pense que c’est une question intéressante. Voici mon avis :
En ce qui concerne l’utilisation des éléments « abstraits » de Discourse par rapport aux add-ons Ember : je pourrais me tromper, mais je pense que l’utilisation d’add-ons Ember pour des tâches spécifiques dans les plugins pourrait être plus facile à maintenir, dans les cas où vous essayez de faire quelque chose de différent de ce que Discourse fait déjà. Voici mon raisonnement :
Un exemple ici serait de vouloir ajouter un tout nouveau menu déroulant dans un plugin. Cette distinction est probablement importante — je parle ici d’essayer de faire de nouvelles choses dans un plugin qui ne sont pas réalisées dans la base de code de Discourse, et la question est de savoir s’il faut commencer par les méthodes de Discourse ou par un add-on séparé.
Souvent, vous n’avez vraiment pas le choix. Par exemple, si je voulais ajouter un champ personnalisé aux sujets, je personnaliserais toujours en me basant sur les méthodes et le code préconstruits de Discourse.
Mais s’il s’agit d’une fonctionnalité ciblée — comme un menu déroulant pour un nouveau besoin — je serais déjà dans une situation où, si j’utilise les méthodes de Discourse, je devrais les adapter à des usages pour lesquels elles n’ont pas été conçues.
Option 1 : Je pourrais essayer de prendre le code select-kit que je vois, par exemple, dans category-chooser, et l’insérer à un nouvel endroit (qui ne concerne pas les catégories), puis essayer de le personnaliser pour qu’il corresponde à ce que je veux que le menu déroulant fasse, au lieu de gérer les catégories. C’est la tâche que j’ai décrite plus tôt comme étant délicate.
Et cela pourrait être difficile à maintenir — car si l’équipe de Discourse modifie quelque chose dans le fonctionnement du code select-kit de category-chooser, cela pourrait modifier mon nouveau menu déroulant personnalisé, mais de manière surprenante (car je l’avais personnalisé pour qu’il fonctionne légèrement différemment du menu déroulant réel de category-chooser).
Option 2 : Je pourrais insérer quelque chose provenant d’Ember qui est robuste mais aussi conçu pour être personnalisé, où je peux voir assez clairement comment le code fonctionne réellement. Dans ce cas, je pourrais manquer des fonctionnalités intéressantes que Discourse pourrait ajouter à ses menus déroulants, mais je pourrais mieux maîtriser le fonctionnement de mon propre menu déroulant. Donc, c’est probablement la meilleure option, je pense, si c’est possible.
Option 3 : Le coder entièrement à partir de zéro. C’est là que j’ai tendance à finir. Une fois le codage terminé, c’est agréable d’avoir un code que je comprends entièrement et que je peux personnaliser. Mais bien sûr, cela prend plus de temps, et (les versions initiales en tout cas) seront probablement moins puissantes et robustes que ce que l’équipe de Discourse ou l’équipe d’Ember ont construit.