Salut @leighno5,
D’après mon expérience personnelle, je pense que pour faire ce que tu fais dans ton « fork », il est beaucoup plus simple d’écrire un plugin Ruby, à condition de bien comprendre Ruby et Rails pour pouvoir facilement créer un plugin pour Discourse (ou modifier n’importe quelle classe Rails).
Si nous ne maîtrisons pas assez Rails et Ruby pour écrire un plugin Discourse, mon expérience me dit que forké Discourse et bidouiller le cœur du système est « malavisé ».
Je dirais que l’analogie est la suivante (désolé pour cette idée simple) :
« Quelqu’un trouve difficile de marcher ; alors il décide de courir à la place. »
Laisse-moi t’expliquer, si tu n’y vois pas d’inconvénient :
Avant de commencer à écrire des applications Rails (rien à voir avec Discourse) et d’essayer d’écrire des plugins pour Discourse, j’étais un peu perdu ; je me suis même senti un peu agacé par Discourse, je crois. C’est comme quand on veut frapper une balle de golf pour la première fois ; elle ne va pas tout droit et il faut beaucoup d’efforts pour la faire atterrir au milieu du fairway. Forker Discourse, c’est comme sortir le gros driver sur le range avant même de savoir faire des chips et des putts avec les fers courts !
J’ai pris une pause dans la bidouille de Discourse (il y a plusieurs mois) et j’ai travaillé pendant un certain temps à construire réellement plusieurs applications Rails de zéro ; et ensuite (et seulement ensuite) j’ai commencé à développer une connaissance « instinctive » de Rails. Après cela, quand j’ai décidé de modifier Discourse (je fais actuellement tourner 6 plugins personnalisés que j’ai écrits en production pour Discourse), tout est devenu intuitif et les plugins modifiant le cœur de Ruby sont devenus trop simples.
Ruby est très flexible. Nous pouvons surcharger n’importe quelle classe, n’importe quel objet. Nous pouvons redéfinir chaque aspect de Ruby. Avec un peu d’expérience, on commence à se dire « WAOUH », je ne savais pas que Ruby était aussi flexible (et puissant), et on commence à « devenir dangereux » parce qu’on peut voler comme Superman avec Ruby et Rails. Nous sommes alors au début de notre voyage avec Ruby et Rails, pas à la fin !
Avec les connaissances en Ruby et Rails que j’ai acquises en 2020, sachant ce que je sais maintenant, je ne forkerais jamais Discourse pour modifier le cœur de Ruby et Rails comme tu le proposes, car les plugins sont tout simplement trop faciles pour surcharger et modifier les classes Ruby, dès qu’on comprend les bases des classes Ruby et les bases de la méta-programmation.
Ce que je veux dire, désolé d’être si direct, c’est que si quelqu’un pense avoir besoin de bidouiller le cœur de Discourse pour apporter quelques modifications mineures en Ruby, alors il ne comprend pas assez Ruby et Rails ; car s’il les comprenait, il ne bidouillerait pas le cœur et écrirait simplement un plugin rapide pour surcharger les classes et adorerait le monkey-patching.
D’un autre côté, si je voulais faire quelque chose de fou et me mettre dans une situation misérable, comme remplacer EmberJS de Discourse par React et Ant Design, alors le fork serait la seule voie à suivre ! Cependant, à mon avis, « Discourse » n’est pas défini par les « librairies Javascript ». Discourse est défini par les compétences de l’équipe de développement principale (les personnes) et leur attention aux détails, leur service client, leur approche d’équipe du développement de code open source, leur pipeline de fonctionnalités SPA, et tout leur travail acharné ! Ce serait un peu fou (à mon sens) de jeter tout ce capital intellectuel simplement parce qu’on pourrait préférer Ant Design (avec React) ou VueJS à Ember.
C’est tout aussi vrai, voire encore plus, si nous comptons simplement modifier le cœur de Discourse ici et là ! Ce serait un peu « dingue » de le forké pour cela, en jetant les « personnes » qui sont le « vrai » Discourse (et pas le code).
Je ne parle que de mon parcours personnel en 2020 pour apprendre Ruby et Rails. Maintenant, les bases deviennent faciles et je suis « dangereux », LOL. Je peux « bidouiller n’importe quoi avec du monkey-patching », ce qui n’est pas toujours bon ; et c’est là que les plugins Discourse interviennent.
Gardez le cœur solide comme un roc, et amusez-vous à « bidouiller » Discourse avec des plugins.
J’espère que cela t’aidera.
Note : en écrivant cette réponse, tu as écrit :
Cela prouve un peu mon point, n’est-ce pas ?
Écrire un « plugin » dans Discourse, c’est écrire du « code Ruby » (à un niveau), et pour d’autres, cela va beaucoup plus loin (en EmberJS).
Avant de commencer à écrire des plugins pour Discourse, mon conseil amical, qui peut sembler sans valeur à tes yeux, est de commencer par développer quelques applications Ruby on Rails. Apprends tes marques en Ruby et Rails, au moins les bases ; après cela, tu auras répondu toi-même à ta question ci-dessus.
Le chemin le plus court pour écrire des plugins Discourse, à mon avis, est d’apprendre Rails en premier.
J’espère que cela t’aidera !
