Suite à une suggestion sur un autre sujet, je viens de commencer à apprendre les composants Glimmer à partir de la documentation Ember. En fait, ils sont vraiment agréables à utiliser et meilleurs que de construire en React, à mon avis. Je suis surpris qu’Ember ne soit pas plus populaire. Quoi qu’il en soit, ma question est la suivante : d’après ce que je peux voir, vous pouvez créer n’importe quel plugin de thème dans Discourse en utilisant des composants Glimmer et vous semblez avoir accès à tout ce qu’Ember offre nativement. Donc, ne pouvez-vous pas, en théorie, personnaliser n’importe quelle partie de Discourse en créant des composants Glimmer ? Quelle est la limite ici ? Toutes les fonctionnalités d’Ember/Glimmer sont-elles disponibles sur Discourse et il vous suffit ensuite de trouver un point de sortie de plugin pour le composant et de l’initialiser correctement ? Par exemple, j’ai eu besoin de compléter certains de mes sujets dans ma communauté avec des données de produits connexes provenant d’un site de commerce électronique externe. Mon idée est donc de créer un composant de thème Glimmer dans Discourse pour exécuter un fetch afin d’obtenir les données du produit, puis de les afficher à la fin de la publication. C’est assez simple avec Glimmer, mais je me demande si cette voie est la bonne dans Discourse car je ne suis pas sûr jusqu’où je peux aller avec les composants Ember/Glimmer. Merci pour vos commentaires.
Je pense que vous comprenez les choses correctement.
Tant que les paramètres de script intersites le permettent, vous devriez être en mesure d’extraire des données du site distant (et vous n’avez pas besoin d’utiliser une clé API secrète, qui sera accessible à l’utilisateur).
Cela fonctionnerait,
Bien que vous devriez être conscient que cela récupérerait les données du produit du site Web externe à chaque vue de page et que cela pourrait ne pas être quelque chose que vous - ou eux - souhaitez. Il serait donc préférable de créer un plugin, de lui demander de récupérer les données de votre propre contrôleur, et que ce contrôleur demande les données du site distant. Cela permettrait de mettre en cache le résultat et vous permettrait également d’utiliser des API non publiques.
S’il y a un lien vers un produit et que les données sont obsolètes, vous pourriez également créer un plugin qui « onebox » le produit et y ajoute les données supplémentaires.
Merci. Je pensais qu’EmberData était disponible, et il semble qu’il dispose d’une mise en cache intégrée. Je n’ai pas encore testé EmberData dans Discourse, mais y a-t-il une raison pour laquelle cela ne fonctionnerait pas ?
Ce serait côté client (c’est-à-dire spécifique à l’utilisateur) et cela résoudrait le problème si vous aviez un utilisateur effectuant la (même) requête 1000 fois.
Mais si vous avez 1000 utilisateurs, effectuant la requête une seule fois chacun, alors cela ne fonctionnerait pas, car ils ont tous un cache séparé.
Merci pour la clarification. Oui, c’est le côté client qui me préoccupe le plus, car l’API a des limites basées sur une adresse IP. Donc, tant que le client lui-même est mis en cache, je devrais être tranquille car je n’ai pas beaucoup d’utilisateurs simultanés qui affecteraient les contraintes de l’API externe.
Ma seule réticence avec Ember est qu’il semble que plus personne ne l’utilise vraiment, à l’exception de Discourse. Je ne l’apprends que parce que Discourse devient de plus en plus populaire et que la plateforme continue de s’améliorer. Mais y a-t-il un avenir pour Ember en dehors de Discourse, et Discourse s’appuiera-t-il dessus pendant longtemps ? Je trouve étrange qu’Ember ne soit pas plus populaire. J’ai développé en React pendant des années et après avoir installé Ember l’autre jour, j’ai été surpris de voir à quel point c’était bien. Il est très utile d’avoir un framework opinionné.
Seul CDCK peut répondre pleinement à cela, mais mon avis :
- Il semble pleinement investi
- C’est un excellent framework complet.
- Il serait très coûteux de le réécrire (et n’aurait presque certainement aucun sens commercial)
- C’est Ember depuis plus d’une décennie, faites vos jeux.
Une énorme liste d’entreprises utilise EmberJS :
Discourse n’utilise pas EmberData.
Bien qu’il ait été plus populaire à l’époque, lorsque des entreprises comme Apple, LinkedIn et Twitch l’utilisaient, il compte toujours des utilisateurs comme nous, Intercom, Hashicorp, CrowdStrike.
Nous avons rejoint Ember Initiative | Mainmatter car Discourse y est pleinement investi.
Pour revenir au titre de ce sujet. Je pense qu’il est assez clair que les composants Glimmer évoluent bien, car CDCK était enfin à l’aise pour autoriser l’ajout de composants à la liste des sujets, ce qui exige que le framework fonctionne à grande échelle, voir : Upcoming topic-list changes - how to prepare themes and plugins
À l’origine, les extensions s’appuyaient sur le système de widgets désormais obsolète, qui a été créé pour relever les défis du rendu de nombreux éléments de liste de sujets, même sur de vieux téléphones Android.