Avantages et inconvénients d'utiliser un thème plutôt qu'un plugin pour la personnalisation

J’ai remarqué que pour la personnalisation du design, il est recommandé d’utiliser des thèmes plutôt que des plugins. Quels sont les avantages ?

Du point de vue du développement, je trouve les thèmes trop lourds. J’ai besoin d’un outil supplémentaire pour voir les modifications de code en temps réel : la console CLI des thèmes.

Je comprends aussi que les thèmes puissent être sélectionnables par l’utilisateur (je n’ai pas besoin de cette fonctionnalité).

Quels sont les avantages des thèmes par rapport aux plugins en production ?

Mon avis :

  1. Décision au moment de l’exécution lors de l’installation plutôt qu’au moment de la compilation, sans interruption de service.
  2. Plus facile à désactiver et à supprimer.
  3. Utilisable par des clients hébergés qui n’ont pas accès à la console.

Mais je suis d’accord pour dire que, selon moi, les plugins sont généralement plus faciles à naviguer du point de vue des développeurs.

Avec l’ajout de la division du JavaScript du thème en plusieurs fichiers, vous pouvez désormais accomplir tout ce qu’un plugin peut faire avec Ember via un thème.

Ainsi, si vous n’avez pas besoin de créer des routes, de modifier des sérialiseurs ou de stocker des données personnalisées, vous pourrez probablement atteindre votre objectif uniquement avec un thème.

Le principal défi que nous rencontrons avec les plugins personnalisés, du point de vue du support, concerne les pannes de site. Cela est généralement dû au fait que le plugin patche une classe ou une méthode Rails dans le noyau qui a été modifiée, et que le plugin n’a pas encore été mis à jour pour en tenir compte. Si quelque chose change côté Ember et que cela brise le thème ou un composant de thème, le site peut ne pas s’afficher correctement, mais il peut être rapidement désactivé en utilisant /safe-mode.

Je comprends votre point de vue. Je dirais aussi que cette gemme vous permet de développer votre thème localement et de le synchroniser avec n’importe quel site Discourse auquel vous avez une clé API, y compris theme-creator.discourse.org. Vous n’avez même pas besoin d’un environnement de développement local configuré si cette gemme est en cours d’exécution.

Wow, les réponses ici sont en or, j’ai très peu à ajouter.

La seule chose que je pense important d’ajouter, c’est qu’au sein de Discourse, nous faisons des progrès pour séparer certains plugins en « plugin pour le backend » et « thème pour le frontend ». Nous réfléchissons à ce défi de « distribution » lorsque les choses sont mélangées de cette façon.

Dans l’ensemble, ma recommandation extrêmement forte est de ne recourir à la création de plugins que si vous en avez absolument besoin. Lorsque vous devez modifier le backend Ruby, vous n’avez pas le choix. Un plugin qui ne modifie que le frontend est fortement déconseillé. Il est plus difficile à maintenir à jour et beaucoup moins flexible en termes d’utilisation.