Hola
Recientemente comencé a trabajar con Discourse y, por mi experiencia de 1 semana, puedo decir definitivamente que el nivel de entrada es bastante alto para un desarrollador que realmente necesita modificar cosas centrales, esto se debe a la falta de documentación/información real, especialmente si hablamos de las opciones más recientes, ya que solo puedo encontrar algo que ya no funciona para la versión 3.6.0 en lugar del nuevo enfoque e incluso si encontré algo, el nivel de detalle es bajo, no hay ejemplos de la vida real o explicaciones más detalladas de cómo usar las cosas.
Sin embargo, necesito modificar el componente second-factor-add-totp.gjs y simplemente no pude hacerlo ya que no hay información sobre cómo hacer esto correctamente en mi tema personalizado.
Encontré que existe algo llamado PluginOutlet que está diseñado para funcionar como un gancho que puedes usar para inyectar tu código personalizado o incluso modificar la salida si el elemento está envuelto en PluginOutlet (no estoy seguro, hay algo como api.renderInOutlet, pero no encontré ninguna información normal sobre cómo usarlo). Al observar esos componentes de Ember, no veo allí PluginOutlet que posiblemente podría ayudar a hacer al menos algunas manipulaciones con la estructura usando al menos JS puro.
¿Puedes aclarar si es algo que se puede agregar allí y si podría usarlo para modificar la estructura de la ventana modal o al menos usar JS puro para mover algunos elementos a su lugar?
Además, tal vez no lo encontré, pero ¿hay documentación con ejemplos para los nuevos enfoques?
Por supuesto.
Así que, según la versión “modificada” que tengo, necesito actualizar un poco el diseño del Modal MFA (cuando el usuario deba configurar una aplicación de autenticación para MFA).
Por actualizar me refiero, por ejemplo, a mover el código QR en la estructura HTML, para ser más específicos, en el texto del sitio “js.user.second_factor.enable_description”, el código QR debería estar en algún lugar entre el nuevo texto proporcionado (marcado HTML).
Otro ejemplo es asegurarse de que “Ingresar manualmente” muestre en su lugar el código real que se puede copiar al hacer clic en él (manualmente a través de un disparador JS para que aparezca y simplemente moverlo).
Todo esto se puede lograr utilizando manipulaciones JS regulares, sin una reconstrucción real de la estructura del componente original, pero el principal desafío para mí es encontrar un lugar donde se pueda colocar este JS para que se active cuando se abra el modal, lo cual aún no he podido averiguar.
Aclaración adicional: Estoy utilizando un tema personalizado que se almacena utilizando la opción GIT.
Hola @Yan_Rudenko, los mejores documentos para empezar son probablemente este tutorial:
Como mencionaste, los Plugin Outlets son la mejor manera de personalizar la interfaz de usuario. Pero estos no están disponibles en todas partes. Solo ciertas partes de la interfaz de usuario están diseñadas para ser personalizadas.
Manipular el DOM usando JS regular causará errores, porque nuestro framework de renderizado perderá el control de los elementos que renderizó en la pantalla. Es mejor ceñirse a los plugin outlets compatibles y otras APIs de JS de Discourse (también cubiertas en el tutorial).
Hola @david, gracias por el enlace al tutorial, pero ya lo revisé y no encontré ninguna respuesta a lo que estaba buscando. Los ejemplos en sí son básicos y no cubren, por ejemplo, cómo obtener una categoría específica (en lugar de hacer una llamada ajax) o cómo usar la API de Discourse en el código (mencionada en https://docs.discourse.org/), que está presente por lo que sé y veo. Por eso escribí aquí para obtener más detalles de las personas que trabajan con Discourse a diario y conocen muchas cosas que no están presentes en la documentación.
Entiendo perfectamente que usar JS puro pueda causar problemas, pero es lo único que se me ocurrió por ahora. Quizás en el futuro pueda modificar algunas cosas de una manera más apropiada si las hay.
Entonces, si entiendo esto correctamente, en la versión actual de Discourse que estoy usando, que es 3.6.0.beta2-latest, ¿los cambios que mencioné no se podrán realizar con las herramientas integradas de Discourse? ¿Debido a la falta de PluginOutlets en esos componentes?
¿El equipo de desarrollo considera agregar estos a los componentes mencionados en futuras versiones, ya que supongo que no hay problemas técnicos con eso, sino una cuestión de decisión de algunas personas que trabajan en esto?
@david, gracias por la propuesta, la consideraré cuando tenga tiempo real para hacerlo, pero debes entender que para alguien que acaba de empezar con Discourse, esto puede llevar tiempo, ya que necesito averiguar cómo preparar uno con los cambios correctos + como mencionaste la etapa de aprobación + el tiempo antes de que entre en la próxima versión.
Esperaba que el equipo de desarrollo, que está mucho más cualificado, pudiera prepararlo en 1 hora si solo se trata de añadir un envoltorio PluginOutlet y algunos dentro de los componentes en diferentes lugares (puede que me equivoque), lo que reduciría el tiempo necesario para que esto se incorpore a la nueva versión.
No obstante, como mencioné anteriormente, consideraré tu propuesta.
Aún así, no he recibido respuesta a mi pregunta, si es posible hacer las cosas que mencioné dentro de la versión actual de Discourse o si los cambios que mencioné deben añadirse/contribuirse primero (añadiendo el PluginOutlet en esos componentes).
La razón por la que pregunto esto es porque tengo un alcance de trabajo que debe realizarse, pero no puedo hacerlo y necesito proporcionar una explicación al equipo de por qué no puedo hacerlo, por lo que o bien el alcance de trabajo se cambiará para hacer cosas que podamos o tendré que contribuir a esto con la esperanza de que se añada al núcleo y se publique en la próxima versión. Por lo tanto, necesito una confirmación del equipo de desarrollo de Discourse sobre si esto es posible o no.
Las cosas rotas van a Bug, las características que faltan a Feature (o en el caso de, por ejemplo, los puntos de conexión de plugins a Dev)
¿Utilizas la rama estable? Entonces hay bastante tiempo hasta la próxima versión estable, pero de lo contrario no necesitas esperar a que se añadan los commits a la última rama después de que se fusione la PR.
Uso la configuración de Docker para Discourse y has planteado una buena sugerencia sobre la rama, sí, podría cambiarla una vez que se fusione la PR y no esperar hasta el lanzamiento real.
Al revisar app.yml puedo ver que utiliza la versión (rama) tests-passed, que, al mirar GIT, supongo que no es la mejor para usar en cuanto a estabilidad. ¿Cuál se prefiere usar, main o cambiar a la última etiqueta? ¿Es posible cambiar a una etiqueta en absoluto para la configuración de Docker?
@david , @Falco He creado un PR, por favor revísalo y hazme saber si falta algo. Necesito que esto progrese lo antes posible, así que si puedes priorizarlo de alguna manera, te lo agradecería mucho.