Veo que las API son bastante extensas, pero antes de adentrarme en esta dirección, quería saber si es posible crear una aplicación Flutter personalizada utilizando completamente las API que admite Discourse.
Actualmente estamos en XenForo y primero migraremos a Discourse y luego comenzaremos a trabajar en la experiencia de usuario de la aplicación personalizada.
¿Hay algo más de lo que debamos tener cuidado?
¿Tiene la intención de usar una vista web?
Si no:
Hola Robert:
No, no planeo usar la vista web. Eso iría en contra del propósito de una experiencia de usuario personalizada.
La duplicación de trabajo es un hecho y es aceptable.
¿A qué te refieres con incompatibilidad con el ecosistema de componentes temáticos y complementos? ¿Quieres decir que los complementos no expondrán las API y, por lo tanto, no se podrán usar en la aplicación móvil personalizada? El componente temático es específico del framework de front-end, por lo que, comprensiblemente, los componentes de Ember no se pueden usar en Flutter.
Leí ese hilo antes de publicarlo aquí. Ese hilo se centró en el debate PWA vs. nativo y el autor original nunca regresó.
Mi consulta no es específicamente sobre Flutter de todos modos, aunque lo mencioné en el título.
La consulta en realidad es, dado que hay una lista extensa de APIs expuestas, ¿es posible crear un front-end personalizado completamente funcional utilizando esas APIs? ¿O hay algunas lagunas que nos impedirían hacerlo?
Los elementos del front-end de estos (los componentes temáticos son 100% front-end) están escritos en EmberJS y utilizan la API de JavaScript de Discourse.
Casi con toda seguridad te cortarás de todas esas personalizaciones.
No, pero son bastante inútiles sin los cambios en el front-end.
Mira mi publicación:
(El tema está enlazado arriba)
Básicamente, es muy divertido para un proyecto, estoy seguro, pero no tiene ningún sentido económico ni técnico.
Si quieres desplegar en las tiendas de aplicaciones, hay una opción mucho mejor.
Sí, es totalmente posible, ya que Discourse es solo una aplicación Ember sobre la API de Rails.
Creo que es una idea terrible, ya que simplemente duplicarás miles de horas de trabajo. Dicho esto, tuve un cliente que hizo exactamente eso y parecían contentos con ello. No he sabido de ellos en mucho tiempo; no sé por qué.
Lo bueno del enfoque es que en cualquier momento podrías decidir cambiar al frontend de Discourse. Edición: O, quizás, usar Discourse después de la migración y luego nunca conseguir que tu aplicación sea lo suficientemente buena como para justificar el cambio a ella, o permitir a los usuarios elegir qué frontend prefieren.
Gracias Jay, tu respuesta es realmente lo que estaba buscando. De hecho, podría usar el front end de Discourse para mis usuarios avanzados y construir una aplicación móvil minimalista para atraer a los usuarios ocasionales que querrían interactuar sin sentirse abrumados. Ya sabes, los que les gusta usar Reddit y Facebook.
¡Vaya, he vuelto a Discourse después de años y la evolución aquí es asombrosa! Muy emocionado.
Mi comunidad tiene 75.000 miembros y 2,5 millones de publicaciones, por lo que llevaría algo de trabajo migrar. Ese es mi primer objetivo por ahora.
[quote=“SubStrider, post:8, topic:342554”]Sabes, los que les gusta usar reddit y facebook.
[/quote]
Tenemos algunos temas para jugar que pueden consumir menos tiempo que “construir un frontend de Discourse en flutter desde cero”
Puedes instalar estos temas en tu sitio y los usuarios podrán seleccionarlos por sí mismos.
Me gustaría que me demostraran lo contrario con un ejemplo real de un frontend independiente. ¡También me gustaría que me corrigieran si algo de lo que digo aquí no es exacto! 
Según mi entendimiento, hay un error de cálculo cada vez que surge este tema, en el sentido de: Discourse tiene una API y una capa de frontend independiente, así que, ¿por qué no probar simplemente un frontend diferente allí?
El error de cálculo que veo es que
Gracias, eso es probablemente algo que habría descubierto si hubiera profundizado más. Es una pena entonces si todas las estadísticas se activan y calculan en el frontend en lugar de, por ejemplo, usar colas en el backend. Nada que ver con headless entonces.
Gracias Natalie, ya miré los temas antes y diría que FKB Pro está más cerca de lo que querríamos.
Mira este concepto de interfaz de usuario para la aplicación móvil.
Hmmmm… ¿estás seguro de que podemos decir eso?
Los “Me gusta” se cuentan en el backend, los recuentos de publicaciones y temas son del backend…
Creo que el tiempo de lectura se basa en el código del frontend, pero eso no es sorprendente…
Sí, cambiaré a “seguimiento de lectura”… Pero sigo en mi punto: muchas funciones avanzadas se basan en el seguimiento de lectura.
Me parece que es solo un tema.
No malgastes tu dinero en una aplicación totalmente nativa.
Estaría de acuerdo con eso. Algunos componentes que ya podrían hacer el trabajo pesado para esto:
Sí, basándonos en las útiles respuestas aquí, primero intentaremos llegar lo más lejos posible con el tema en sí. La primera prioridad es migrar con toda la personalización que tenemos implementada, que incluye un mercado bullicioso y un sistema de calificación comercial.
Ok, otra consulta. ¿Los usuarios pueden suscribirse a categorías para ver solo hilos de esas categorías en sus feeds? Eso es algo que tenía en mente con las API.
¿Hay alguna forma de mostrar contenido recomendado en el feed basado en puntuaciones y relevancia para un usuario?
Lo separaría en otro Tema si fuera tú.
Ten en cuenta que en Discourse, hilo = Tema
Hubo una solicitud de funcionalidad para esto:
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
