APIは非常に広範囲にわたりますが、この方向で進む前に、DiscourseがサポートするAPIのみを使用してカスタムFlutterアプリを構築できるかどうかを知りたいと思いました。
現在XenForoを使用しており、まずDiscourseに移行してから、カスタムアプリのユーザーエクスペリエンスの開発を開始する予定です。
他に注意すべき点はありますか？
「いいね！」 1
Webビューを使用する予定ですか？
そうでない場合：
- フロントエンド作業の膨大な量の重複の可能性
- （継続的なメンテナンスの重複を含む）
- テーマコンポーネントおよびプラグインエコシステムとの非互換性により、それを活用できない。
「いいね！」 1
「いいね！」 1
ロバート様
いいえ、Webビューを使用する予定はありません。それはカスタムユーザーエクスペリエンスの目的を損なうことになります。
作業の重複は避けられず、許容されます。
テーマコンポーネントとプラグインエコシステムとの非互換性とはどういう意味ですか？ プラグインがAPIを公開しないため、カスタムモバイルアプリで使用できないということですか？ テーマコンポーネントはフロントエンドフレームワークに固有のものであるため、EmberコンポーネントをFlutterで使用できないことは理解できます。
「いいね！」 1
投稿する前にそのスレッドを読みました。そのスレッドはPWA対ネイティブの議論に陥り、元の投稿者は二度と現れませんでした。
私の質問は、タイトルで言及したにもかかわらず、具体的にはFlutterに関するものではありません。
実際には、公開されているAPIの広範なリストがあるので、それらを使用して完全に機能するカスタムフロントエンドを作成することは可能ですか？それとも、そうすることを許可しないギャップはありますか？
これら（テーマコンポーネントは100％フロントエンドです）のフロントエンド要素はEmberJSで記述されており、DiscourseのJavaScript APIを使用しています。
これらのカスタマイズのすべてからほぼ確実に切り離されることになります。
いいえ、しかしフロントエンドの変更なしではほとんど役に立ちません。
私の投稿を参照してください：
（トピックは上記でリンクされています）
基本的に、プロジェクトとしてはきっと楽しいでしょうが、経済的にも技術的にもほとんど意味がありません。
アプリストアに展開したい場合は、はるかに良い選択肢があります。
「いいね！」 2
はい、完全に可能です。なぜなら、Discourse は Rails API の上に構築された Ember アプリだからです。
それはひどいアイデアだと思います。なぜなら、何千時間もの作業を重複させるだけだからです。とはいえ、クライアントがまさにそれを実行し、満足しているようでした。長い間連絡がありません。理由はわかりません。
このアプローチの良い点は、いつでも Discourse のフロントエンドに切り替えられることです。編集：あるいは、移行後に Discourse を使用し、アプリを十分に良くできずに移行する価値がないと判断したり、ユーザーがお好みのフロントエンドを選択できるようにしたりすることもできます。
「いいね！」 6
ジェイさん、ありがとうございます。まさに探していた答えでした。実際、パワーユーザーにはDiscourseのフロントエンドを使い、カジュアルユーザーを引き付けるためのミニマリストなモバイルアプリを構築できます。彼らは、圧倒されることなく参加したいと思うでしょう。RedditやFacebookを使っているようなユーザーです。
いやー、何年も経ってDiscourseに戻ってきましたが、ここの進化は驚くべきものがあります。とても興奮しています。
私のコミュニティには75,000人のメンバーと250万件の投稿があるので、移行するにはかなりの作業が必要です。それが今の私の最初の目標です。
「DiscourseのフロントエンドをFlutterでゼロから構築する」よりも時間の浪費が少ない、いくつか試せるテーマがあります。
これらのテーマをサイトにインストールすれば、ユーザーは自分で選択できます。
独立したフロントエンドの実際の例で、私の考えが間違っていることを証明していただけると嬉しいです。また、ここに記載した内容で正確でない点があれば訂正していただけると幸いです！
私の理解では、この話題が出ると常に誤解が生じているようです。つまり、「DiscourseにはAPIと独立したフロントエンド層があるので、別のフロントエンドを試してみてはどうだろうか？」という考え方です。
私が認識している誤解は以下の通りです。
- スケールだけで見ると、実際のインターフェース要素とビューの量が適切に評価されていません。トピックリストやトピックビューだけでなく、二次的と思われるものが他にもたくさんあり、それらも設計する必要があります。ユーザーページを見るだけでも、すべての異なるビューを複製するか、代替構造を考案する必要があります。
- より概念的には、Discourseのフロントエンドは単なる表示層ではなく、高度に機能的な層です。すべての既読追跡はEmberに基づいており、それがなければDiscourseの洗練された機能の多くは動作しません。ユーザー追跡をフロントエンドで複製せず、バックエンドと慎重に連携させなければ、ユーザーが読み取り、投稿し、いいねできるだけの非常にシンプルなアプリになってしまいます。このようなシンプルなアプリを、Discourseのような複雑な基盤ではなく、シンプルな基盤上に構築する方がはるかに簡単でしょう。
「いいね！」 3
ありがとうございます。おそらく、さらに深く掘り下げていれば発見したでしょう。統計がバックエンドのキューを使用するのではなく、フロントエンドでトリガーおよび計算されているとしたら残念です。ヘッドレスとは程遠いですね。
うーん…そう言えるかどうか分かりません。
いいねはバックエンドでカウントされ、投稿とトピックのカウントもバックエンドです…
読書時間はフロントエンドコードに基づいていると思いますが、それは驚くことではありません…
「いいね！」 1
はい、「読み取り追跡」に変更します。しかし、私の言いたいことは変わりません。多くの高度な機能は読み取り追跡に基づいています。
テーマにしか見えません。
完全にネイティブなアプリにお金を無駄にしないでください。
「いいね！」 1
それに同意します。すでにこのための重い作業を行うことができるいくつかのコンポーネントがあります。
- リストビューを調整するためのトピックカード、トピックリストサムネイル、またはトピックリストプレビューテーマコンポーネントのいずれか
- フッターナビゲーション用のF NAV - モバイルナビゲーションタブ
「いいね！」 2
はい、ここでの役立つ回答に基づいて、まずテーマ自体をできる限り進めていきます。最初の優先事項は、活気のあるマーケットプレイスと取引評価システムを含む、現在適用されているすべてのカスタマイズを移行することです。
「いいね！」 2
ユーザーはカテゴリを購読して、フィードでそのカテゴリのスレッドのみを表示できますか？それがAPIについて考えていたことの1つです。
スコアリングとユーザーへの関連性に基づいて、フィードにおすすめのコンテンツを提示する方法はありますか？
そうですね、別のトピックに分けた方が良いと思います。
Discourseでは、スレッドはトピックと同義です。
これに関する機能リクエストがありました。
「いいね！」 1
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.