Je vois que les API sont assez étendues, mais avant de m’engager dans cette voie, je voulais savoir s’il était possible de construire une application Flutter personnalisée entièrement à l’aide des API prises en charge par Discourse ?
Nous sommes actuellement sur XenForo et nous migrerons d’abord vers Discourse, puis nous commencerons à travailler sur l’expérience utilisateur de l’application personnalisée.
Y a-t-il autre chose à surveiller ?
Comptez-vous utiliser une vue web ?
Si non :
Salut Robert,
Non, je n’envisage pas d’utiliser la vue Web. Cela irait à l’encontre de l’objectif d’une expérience utilisateur personnalisée.
La duplication du travail est une évidence et est acceptable.
Qu’entendez-vous par incompatibilité avec l’écosystème des composants thématiques et des plugins ? Voulez-vous dire que les plugins n’exposeront pas les API et ne pourront donc pas être utilisés sur l’application mobile personnalisée. Le composant thématique est spécifique au framework front-end, donc il est compréhensible que les composants Ember ne puissent pas être utilisés sur Flutter.
J’ai lu ce fil de discussion avant de poster ici. Ce fil de discussion a abordé le débat PWA vs natif et l’auteur original n’est jamais revenu.
Ma question ne porte pas spécifiquement sur Flutter, même si je l’ai mentionné dans le titre.
La question est en fait, étant donné qu’il existe une liste étendue d’API exposées, est-il possible de créer un frontend personnalisé entièrement fonctionnel en utilisant celles-ci. Ou y a-t-il des lacunes qui nous empêcheraient de le faire.
Les éléments front-end de ceux-ci (les composants de thème sont 100% front-end) sont écrits en EmberJS et utilisent l’API JavaScript de Discourse
Vous vous couperez presque certainement de toutes ces personnalisations.
Non, mais ils seront assez inutiles sans les changements front-end.
Voir mon post :
(Le sujet est lié ci-dessus)
En gros, c’est très amusant pour un projet, j’en suis sûr, mais cela n’a aucun sens économique ni technique.
Si vous voulez déployer sur les magasins d’applications, il existe une bien meilleure option.
Oui, c’est tout à fait possible, car Discourse est juste une application Ember construite sur l’API Rails.
Je pense que c’est une idée terrible, car vous ne feriez que dupliquer des milliers d’heures de travail. Cela dit, j’ai eu un client qui a fait exactement cela et il semblait satisfait. Je n’ai pas eu de nouvelles de lui depuis longtemps ; je ne sais pas pourquoi.
Le bon côté de cette approche est qu’à tout moment, vous pourriez simplement décider de passer à l’interface utilisateur de Discourse. Édition : Ou, peut-être, utiliser Discourse après la migration, puis ne jamais rendre votre application suffisamment performante pour justifier le passage à Discourse, ou permettre aux utilisateurs de choisir l’interface utilisateur qu’ils préfèrent.
Merci Jay, votre réponse est exactement ce que je cherchais. En fait, je pourrais utiliser l’interface de Discourse pour mes utilisateurs expérimentés et construire une application mobile minimaliste pour attirer les utilisateurs occasionnels qui voudraient s’engager sans être submergés. Vous savez, ceux qui aiment utiliser Reddit et Facebook.
Oh là là, je suis revenu à Discourse après des années et l’évolution ici est incroyable. Très enthousiaste.
Ma communauté compte 75 000 membres et 2,5 millions de messages, il faudrait donc un peu de travail pour migrer. C’est mon premier objectif pour le moment.
Nous avons quelques thèmes avec lesquels jouer qui pourraient être moins chronophages que « construire une interface Discourse en flutter à partir de zéro ».
Vous pouvez installer ces thèmes sur votre site et les utilisateurs pourront les sélectionner eux-mêmes.
J’aimerais être contredit avec un exemple concret de frontend indépendant. J’aimerais aussi être corrigé si quelque chose que j’énonce ici n’est pas exact ! 
Dans ma compréhension, il y a en fait un jugement erroné chaque fois que ce sujet surgit, dans le sens où : Discourse a une API et une couche frontend indépendante, alors pourquoi ne pas simplement essayer un frontend différent ?
Le jugement erroné que je vois est que :
Merci, c’est probablement quelque chose que j’aurais découvert en approfondissant. C’est dommage alors si toutes les statistiques sont déclenchées et calculées côté client au lieu d’utiliser des files d’attente côté serveur, par exemple. Loin d’être headless alors.
Merci Natalie, j’ai regardé les thèmes plus tôt et je dirais que FKB Pro est plus proche de ce que nous voudrions.
Voici ce concept d’interface utilisateur pour l’application mobile.
Hmmm… Je ne suis pas sûr que nous puissions dire cela ?
Les J’aime sont comptés dans le backend, les comptes de Posts et de Sujets sont dans le backend…
Je pense que le temps de lecture est basé sur le code front-end, mais ce n’est pas surprenant…
Oui, je vais changer pour « suivi de lecture »… Mais mon point reste le même : de nombreuses fonctionnalités avancées sont basées sur le suivi de lecture.
Cela ressemble juste à un thème pour moi.
Ne gaspillez pas votre argent pour une application entièrement native.
Je serais d’accord avec cela. Certains composants qui pourraient déjà faire le gros du travail pour cela :
Oui, d’après les réponses utiles ici, nous allons d’abord essayer d’aller aussi loin que possible avec le thème lui-même. La première priorité est de migrer avec toutes les personnalisations que nous avons en place, qui comprennent une place de marché animée et un système de notation des échanges.
Ok, une autre requête. Les utilisateurs peuvent-ils s’abonner à des catégories pour ne voir que les fils de discussion de ces catégories dans leurs flux ? C’est une chose à laquelle je pensais avec les API.
Existe-t-il un moyen de proposer du contenu recommandé dans le flux en fonction de la notation et de la pertinence pour un utilisateur ?
Je séparerais cela dans un autre sujet si j’étais vous.
Notez que sur Discourse, thread = Topic
Il y a eu une demande de fonctionnalité pour cela :
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
