Ich sehe, dass die APIs ziemlich umfangreich sind, aber bevor ich diesen Weg einschlage, wollte ich wissen, ob es möglich ist, eine benutzerdefinierte Flutter-App ausschließlich mit den APIs zu erstellen, die Discourse unterstützt?
Wir sind derzeit auf XenForo und würden zuerst zu Discourse migrieren und dann mit der Arbeit an der benutzerdefinierten App-Benutzererfahrung beginnen.
Gibt es sonst noch etwas, worauf wir achten sollten?
Haben Sie vor, eine Webansicht zu verwenden?
Wenn nicht:
Hallo Robert,
Nein, ich habe nicht vor, die Webansicht zu verwenden. Das würde den Zweck einer benutzerdefinierten Benutzererfahrung zunichtemachen.
Doppelarbeit ist gegeben und akzeptabel.
Was meinen Sie mit Inkompatibilität mit dem Theme-Komponenten- und Plugin-Ökosystem? Meinen Sie, dass Plugins die APIs nicht verfügbar machen und daher nicht in der benutzerdefinierten mobilen App verwendet werden können. Die Theme-Komponente ist spezifisch für das Frontend-Framework, daher können Ember-Komponenten verständlicherweise nicht in Flutter verwendet werden.
Ich habe diesen Thread gelesen, bevor ich das hier gepostet habe. In diesem Thread ging es um die PWA-vs.-Native-Debatte, und der ursprüngliche Poster ist nie zurückgekehrt.
Meine Frage bezieht sich sowieso nicht speziell auf Flutter, auch wenn ich es im Titel erwähnt habe.
Die eigentliche Frage ist, ob es möglich ist, ein voll funktionsfähiges benutzerdefiniertes Frontend mit den bereitgestellten umfangreichen APIs zu erstellen. Oder gibt es Lücken, die uns daran hindern würden, dies zu tun.
Die Frontend-Elemente dieser (Theme-Komponenten sind 100% Frontend) sind in EmberJS geschrieben und verwenden die JavaScript-API von Discourse.
Sie werden sich mit ziemlicher Sicherheit von all diesen Anpassungen abschneiden.
Nein, aber ziemlich nutzlos ohne die Frontend-Änderungen.
Siehe meinen Beitrag:
(Das Thema ist oben verlinkt)
Grundsätzlich ein großer Spaß für ein Projekt, aber es macht wirtschaftlich und technisch wenig Sinn.
Wenn Sie in App Stores bereitstellen möchten, gibt es eine viel bessere Option.
Ja, das ist absolut möglich, da Discourse nur eine Ember-App auf der Rails-API ist.
Ich halte das für eine schreckliche Idee, da Sie Tausende von Arbeitsstunden duplizieren würden. Nichtsdestotrotz hatte ich einen Kunden, der genau das getan hat, und er schien damit zufrieden zu sein. Ich habe seit langem nichts mehr von ihm gehört; ich weiß nicht, warum.
Das Gute an diesem Ansatz ist, dass Sie sich jederzeit entscheiden könnten, auf das Discourse-Frontend umzusteigen. Bearbeitung: Oder vielleicht Discourse nach der Migration verwenden und dann nie Ihre App gut genug bekommen, um einen Umzug dorthin zu rechtfertigen, oder den Benutzern die Wahl lassen, welches Frontend sie bevorzugen.
Danke Jay, deine Antwort ist genau das, wonach ich gesucht habe. Tatsächlich könnte ich das Discourse-Frontend für meine Power-User nutzen und eine minimalistische mobile App entwickeln, um Gelegenheitsnutzer anzusprechen, die sich engagieren möchten, ohne überfordert zu werden. Du weißt schon, die, die gerne Reddit und Facebook nutzen.
Oh Mann, ich bin nach Jahren zu Discourse zurückgekehrt und die Entwicklung hier ist erstaunlich. Sehr aufgeregt.
Meine Community hat 75.000 Mitglieder und 2,5 Millionen Beiträge, daher würde die Migration etwas Arbeit erfordern. Das ist mein erstes Ziel im Moment.
Wir haben einige Themes, mit denen man experimentieren kann, die vielleicht weniger zeitaufwendig sind als “eine Discourse-Oberfläche in Flutter von Grund auf neu zu erstellen”.
Du kannst diese Themes auf deiner Website installieren und Benutzer können sie selbst auswählen.
Ich möchte mit einem tatsächlichen Beispiel eines unabhängigen Frontends widerlegt werden. Ich möchte auch korrigiert werden, wenn etwas, das ich hier sage, nicht korrekt ist! 
Nur nach meinem Verständnis gibt es bei diesem Thema tatsächlich eine Fehleinschätzung, im Sinne von: Discourse hat eine API und eine unabhängige Frontend-Schicht, warum also nicht einfach ein anderes Frontend dort ausprobieren?
Die Fehleinschätzung, die ich sehe, ist, dass
Vielen Dank, das ist wahrscheinlich etwas, das ich entdeckt hätte, als ich tiefer gegraben hätte. Es ist schade, wenn all die Statistiken im Frontend ausgelöst und berechnet werden, anstatt zum Beispiel Warteschlangen im Backend zu verwenden. Damit ist es dann auch nicht mehr Headless.
Danke Natalie, ich habe mir die Themes bereits angesehen und würde sagen, dass FKB Pro dem näher kommt, was wir wollen würden.
Sehen Sie sich dieses Konzept-UI für die mobile App an.
Hmmm … da bin ich mir nicht so sicher?
Likes werden im Backend gezählt, Post- und Topic-Zählungen sind Backend …
Ich denke, die Lesezeit basiert auf Front-End-Code, aber das ist nicht überraschend …
Ja, ich werde zu „Leseverfolgung“ wechseln. Aber das ist immer noch mein Punkt: Viele fortgeschrittene Funktionen basieren auf der Leseverfolgung.
Sieht für mich nur wie ein Theme aus.
Verschwenden Sie Ihr Geld nicht für eine vollständig native App.
Dem würde ich zustimmen. Einige Komponenten, die bereits die Hauptarbeit dafür leisten könnten:
Ja, basierend auf den hilfreichen Antworten hier werden wir zuerst versuchen, so weit wie möglich mit dem Thema selbst zu gehen. Die erste Priorität ist die Migration mit all den Anpassungen, die wir haben, einschließlich eines geschäftigen Marktplatzes und eines Handelssystembewertungssystems.
Ok, eine weitere Frage. Können sich Benutzer für Kategorien anmelden, um nur Threads aus diesen Kategorien in ihren Feeds anzuzeigen? Das ist eine Sache, die ich mit den APIs im Sinn hatte.
Gibt es eine Möglichkeit, empfohlene Inhalte im Feed basierend auf Bewertungen und Relevanz für einen Benutzer anzuzeigen?
Ich würde das eher in ein eigenes Thema aufteilen.
Beachten Sie, dass bei Discourse ein Thread = Thema ist.
Hierfür gab es eine Funktionsanfrage:
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
