Vejo que as APIs são bastante extensas, mas antes de seguir nessa direção, eu queria saber se é possível construir um aplicativo Flutter personalizado inteiramente usando as APIs que o Discourse suporta?
Atualmente estamos no XenForo e migraríamos para o Discourse primeiro e depois começaríamos a trabalhar na experiência do usuário do aplicativo personalizado.
Algo mais com que devemos ter cuidado?
Você pretende usar uma web view?
Se não:
Olá Robert,
Não, não pretendo usar a visualização da web. Isso iria contra o propósito de uma experiência de usuário personalizada.
A duplicação de trabalho é esperada e aceitável.
O que você quer dizer com incompatibilidade com o ecossistema de componentes de tema e plugins? Você quer dizer que os plugins não exporão as APIs, portanto, não poderão ser usados no aplicativo móvel personalizado. O componente de tema é específico do framework de front-end, então, compreensivelmente, os componentes Ember não podem ser usados no Flutter.
Eu li aquele tópico antes de postar isso aqui. Aquele tópico entrou no debate PWA vs. nativo e o autor original nunca mais voltou.
Minha pergunta não é especificamente sobre Flutter, mesmo que eu o tenha mencionado no título.
A pergunta na verdade é: como existe uma lista extensa de APIs expostas, é possível criar um front-end personalizado totalmente funcional usando-as? Ou existem algumas lacunas que não nos permitiriam fazer isso.
Os elementos de front-end destes (Componentes de Tema são 100% front-end) são escritos em EmberJS e usam a API JavaScript do Discourse
Você quase certamente se cortará de todas essas customizações.
Não, mas bastante inútil sem as alterações de front-end.
Veja minha postagem:
(O Tópico está vinculado acima)
Basicamente, é muito divertido para um projeto, com certeza, mas totalmente sem sentido econômico nem técnico.
Se você quiser implantar nas lojas de aplicativos, há uma opção muito melhor
Sim, é totalmente possível, pois o Discourse é apenas um aplicativo Ember em cima da API Rails.
Acho que é uma ideia terrível, pois você estará apenas duplicando milhares de horas de trabalho. Dito isso, tive um cliente que fez exatamente isso e eles pareciam felizes com isso. Não ouço falar deles há muito tempo; não sei por quê.
A coisa boa sobre a abordagem é que, a qualquer momento, você pode simplesmente decidir mudar para o front-end do Discourse. Editar: Ou, talvez, usar o Discourse após a migração e, em seguida, nunca conseguir que seu aplicativo seja bom o suficiente para justificar a mudança para ele, ou permitir que os usuários escolham qual front-end eles preferem.
Obrigado, Jay, sua resposta é realmente o que eu estava procurando. Na verdade, eu poderia usar o front-end do discourse para meus usuários avançados e construir um aplicativo móvel minimalista para atrair usuários casuais que gostariam de se envolver sem se sobrecarregar. Sabe aqueles que gostam de usar reddit e facebook.
Nossa, voltei ao discourse depois de anos e a evolução aqui é incrível. Muito animado.
Minha comunidade tem 75 mil membros e 2,5 milhões de posts, então levaria algum trabalho para migrar. Esse é meu primeiro objetivo no momento.
Nós temos alguns temas com os quais podemos brincar, que podem consumir menos tempo do que “construir um frontend do Discourse em flutter do zero”.
Você pode instalar esses temas em seu site e os usuários podem selecioná-los por si mesmos.
Gostaria de ser provado errado com um exemplo real de um frontend independente. Também gostaria de ser corrigido se algo que afirmo aqui não for preciso! 
Apenas no meu entendimento, há na verdade um equívoco sempre que este tópico surge, no sentido de: o Discourse tem uma API e uma camada de frontend independente, então por que não tentar um frontend diferente lá?
O equívoco que vejo é que
Obrigado, isso provavelmente é algo que eu teria descoberto se tivesse investigado mais a fundo. É uma pena, então, se todas as estatísticas estão sendo acionadas e computadas no front-end em vez de usar filas no back-end, por exemplo. Nem um pouco headless, então.
Obrigado Natalie, eu olhei os temas mais cedo e diria que o FKB Pro está mais próximo do que gostaríamos.
Veja este conceito de UI para o aplicativo móvel.
Hmmm… não tenho certeza se podemos dizer isso?
Curtidas são contadas no backend, contagens de Posts e Tópicos são no backend…
Acho que o tempo de leitura é baseado no código front-end, mas isso não é surpreendente…
Sim, mudarei para “rastreamento de leitura”… Mas o meu ponto é o mesmo: muitos recursos avançados são baseados no rastreamento de leitura.
Parece apenas um Tema para mim.
Não gaste seu dinheiro em um aplicativo totalmente nativo.
Concordaria com isso. Alguns componentes que já poderiam fazer o trabalho pesado para isso:
Sim, com base nas respostas úteis aqui, tentaremos primeiro ir o mais longe possível com o tema em si. A primeira prioridade é migrar com todas as personalizações que temos em vigor, que incluem um mercado movimentado e um sistema de classificação de comércio.
Ok, outra consulta. Os usuários podem se inscrever em categorias para ver apenas tópicos dessas categorias em seus feeds? Essa é uma coisa que eu tinha em mente com as APIs.
Existe uma maneira de exibir conteúdo recomendado no feed com base em pontuação e relevância para um usuário?
Eu separaria isso em outro Tópico, se fosse você.
Note que no Discourse, thread = Tópico
Houve uma solicitação de recurso para isso:
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
