Vedo che le API sono piuttosto estese, ma prima di intraprendere questa direzione, volevo sapere se è possibile creare un’app Flutter personalizzata interamente utilizzando le API supportate da Discourse?
Attualmente siamo su XenForo e migreremo prima a Discourse e poi inizieremo a lavorare sull’esperienza utente dell’app personalizzata.
C’è qualcos’altro di cui dobbiamo stare attenti?
Hai intenzione di utilizzare una web view?
Se no:
Ciao Robert,
No, non ho intenzione di utilizzare la web view. Ciò vanificherebbe lo scopo di un’esperienza utente personalizzata.
La duplicazione del lavoro è un dato di fatto e accettabile.
Cosa intendi per incompatibilità con il componente del tema e l’ecosistema dei plugin? Intendi dire che i plugin non esporranno le API, quindi non potranno essere utilizzati sull’app mobile personalizzata. Il componente del tema è specifico per il framework front-end, quindi è comprensibile che i componenti Ember non possano essere utilizzati su Flutter.
Ho letto quella discussione prima di pubblicare qui. Quella discussione è scivolata nel dibattito PWA vs nativo e l’autore originale non è più tornato.
La mia domanda non riguarda specificamente Flutter, anche se l’ho menzionato nel titolo.
La domanda in realtà è: dato che c’è un elenco esteso di API esposte, è possibile creare un frontend personalizzato completamente funzionale utilizzando quelle. O ci sono delle lacune che non ci permetterebbero di farlo.
Gli elementi front-end di questi (i componenti tema sono al 100% front-end) sono scritti in EmberJS e utilizzano l’API JavaScript di Discourse
Ti taglierai quasi certamente da tutte quelle personalizzazioni.
No, ma piuttosto inutili senza le modifiche al front-end.
Vedi il mio post:
(L’argomento è collegato sopra)
Fondamentalmente è molto divertente per un progetto, ne sono sicuro, ma non ha alcun senso economico né tecnico.
Se vuoi distribuire sugli app store c’è un’opzione molto migliore
Sì, è assolutamente possibile, dato che Discourse è solo un’app Ember sopra l’API Rails.
Penso che sia una pessima idea, poiché duplicheresti migliaia di ore di lavoro. Detto questo, ho avuto un cliente che ha fatto proprio questo e sembrava soddisfatto. Non ho più sentito parlare di loro da molto tempo; non so perché.
La cosa buona di questo approccio è che in qualsiasi momento potresti semplicemente decidere di passare al frontend di Discourse. Modifica: Oppure, forse, usare Discourse dopo la migrazione e poi non riuscire mai a rendere la tua app abbastanza valida da giustificare il passaggio ad essa, o permettere agli utenti di scegliere quale frontend preferiscono.
Grazie Jay, la tua risposta è proprio quello che stavo cercando. Infatti potrei usare il front-end di discourse per i miei utenti esperti e costruire un’app mobile minimalista per attrarre gli utenti occasionali che vorrebbero interagire senza sentirsi sopraffatti. Sai, quelli a cui piace usare reddit e facebook.
Oh mamma, sono tornato a discourse dopo anni e l’evoluzione qui è oltre il fantastico. Molto emozionato.
La mia community ha 75.000 membri e 2,5 milioni di post, quindi ci vorrebbe un po’ di lavoro per migrare. Questo è il mio primo obiettivo al momento.
Abbiamo alcuni temi con cui giocare che potrebbero richiedere meno tempo rispetto a “costruire un frontend Discourse in flutter da zero”
Puoi installare questi temi sul tuo sito e gli utenti potranno selezionarli da soli.
Mi piacerebbe essere smentito con un esempio concreto di frontend indipendente. Mi piacerebbe anche essere corretto se qualcosa di ciò che affermo qui non è accurato! :abbracci: Solo nella mia comprensione c’è in realtà un errore di valutazione ogni volta che questo argomento viene fuori, nel senso di: Discourse ha un’API e uno strato frontend indipendente, quindi perché non provare semplicemente un frontend diverso lì?
L’errore di valutazione che vedo è che
Grazie, probabilmente è qualcosa che avrei scoperto scavando più a fondo. È un peccato allora se tutte le statistiche vengono attivate e calcolate nel front-end invece di usare, ad esempio, le code nel back-end. Non è affatto headless, quindi.
Grazie Natalie, ho già esaminato i temi e direi che FKB Pro è più vicino a ciò che vorremmo.
Ecco questo concept UI per l’app mobile.
Mmm… non sono sicuro che possiamo dirlo?
I Mi piace vengono conteggiati nel backend, i conteggi di Post e Topic sono nel backend…
Penso che il tempo di lettura si basi sul codice front-end, ma non è sorprendente…
Sì, cambierò in “monitoraggio delle letture”.. Ma il mio punto rimane: molte funzionalità avanzate si basano sul monitoraggio delle letture.
Sembra solo un tema.
Non sprecare i tuoi soldi per un’app completamente nativa.
Sarei d’accordo. Alcuni componenti che potrebbero già fare il grosso del lavoro per questo:
Sì, basandoci sulle risposte utili qui, tenteremo prima di andare il più lontano possibile con il tema stesso. La prima priorità è migrare con tutte le personalizzazioni che abbiamo in atto, che includono un vivace marketplace e un sistema di valutazione del commercio.
Ok, un’altra domanda. Gli utenti possono iscriversi alle categorie per vedere solo i thread di quelle categorie nei loro feed? È una cosa che avevo in mente con le API.
C’è un modo per mostrare contenuti consigliati nel feed in base al punteggio e alla pertinenza per un utente?
Lo separerei in un altro argomento se fossi in te.
Nota che su Discourse, thread = Topic
C’è stata una richiesta di funzionalità per questo:
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
