¿Podemos agregar complementos de Ember a un plugin de Discourse? (como Ember Power Select)

Me gustaría agregar algunos complementos de Ember a un plugin.

Aquí tienes un ejemplo: Power Select de Ember.

(Esto ayuda con los menús desplegables. Discourse utiliza select-kit, que sé que también es potente, pero me resulta difícil de personalizar porque está muy abstraído en la base de código. Por lo tanto, me gustaría probar Power Select).

En una aplicación normal de Rails/Ember, creo que solo agregaría el complemento con:

$ ember install ember-power-select

Luego, agregaría cosas como las siguientes:

plantilla hbs:

<PowerSelect @options={{this.names}} @onChange={{this.foo}} as |name|>
  {{name}}
</PowerSelect>

archivo de JavaScript que va junto con él:

    import Controller from '@ember/controller';
    export default class extends Controller {
      names = ['Stefan', 'Miguel', 'Tomster', 'Pluto']
      foo() { }
    }

Pero un plugin de Discourse no es una aplicación estándar de Rails. ¿Hay algo especial que deba hacer para que funcione?

Bueno, vi esto preguntándome si obtendrías alguna pista, pero aquí estamos 4 días después.

Soy bastante novato en Ember, pero estoy bastante seguro de que te irá mucho mejor si logras lidiar con lo de “muy abstraído” y sigues esas reglas. No solo es difícil entender cómo integrar otros complementos, sino que también será difícil de mantener.

Estamos actualizando Discourse a EmberCLI y ya estamos muy cerca:

Gracias a todos.

Ya había visto eso antes, pero me alegra tener la confirmación de que no es posible agregar complementos (add-ons) de Ember hasta que se complete esa actualización. Parece, entonces, que pronto será posible añadir complementos de Ember, una vez finalizada la migración. Eso suena genial.


Creo que esa es una pregunta interesante. Aquí van mis dos centavos:

En cuanto al uso de lo “abstraído” de Discourse frente a complementos de Ember: podría estar equivocado, pero creo que utilizar complementos de Ember para tareas específicas en plugins podría ser más fácil de mantener, en los casos en los que intentas hacer algo diferente a lo que ya hace Discourse. Esta es mi reflexión:


Un ejemplo aquí sería querer agregar un nuevo menú desplegable en un plugin. Esa distinción es probablemente importante: estoy hablando de intentar hacer cosas nuevas en un plugin que no existen en el código base de Discourse, y la pregunta es si comenzar con los métodos de Discourse o con un complemento independiente.

A menudo realmente no tienes opción. Por ejemplo, si quisiera agregar un campo personalizado a los temas, siempre lo haría sobre la base de los métodos y el código predefinidos de Discourse.

Pero si se trata de una funcionalidad específica, como un menú desplegable para un nuevo propósito, ya estaría en una situación en la que, si uso los métodos de Discourse, tendría que adaptarlos a cosas para las que no fueron diseñados originalmente.

Opción 1: Podría intentar tomar el código de select-kit que veo, por ejemplo, en category-chooser, e insertarlo en un nuevo lugar (que no tiene que ver con categorías), y luego tratar de personalizarlo para que se ajuste a lo que quiero que haga ese menú desplegable, en lugar de categorías. Esta es la tarea que describí anteriormente como complicada.

Y podría ser difícil de mantener: porque si el equipo de Discourse cambia algo en la forma en que funciona el código de select-kit de category-chooser, eso podría afectar mi nuevo menú desplegable personalizado, pero de formas que podrían ser inesperadas (ya que lo había personalizado para que funcione de manera ligeramente diferente al menú desplegable real de category-chooser).

Opción 2: Podría insertar algo de Ember que sea robusto pero que también esté diseñado para ser personalizado, donde pueda ver con bastante claridad cómo funciona realmente el código. En ese caso, podría perderme algunas nuevas características interesantes que Discourse agregue a sus menús desplegables, pero podría mantener un control más fácil sobre el funcionamiento de mi menú desplegable. Así que esta es probablemente la mejor opción, creo, si es posible.

Opción 3: Programarlo desde cero. Es a lo que he tendido a llegar. Cuando se termina de programar, es agradable tener un código que entiendo completamente y puedo personalizar. Pero, por supuesto, lleva más tiempo, y (al menos las versiones iniciales) es poco probable que sean tan potentes y robustas como lo que ha construido el equipo de Discourse o el equipo de Ember.

Bump, y sería genial agregar soporte para complementos de Ember en los componentes de tema…

Subir.
Si añadimos un complemento a Discourse así:
cd app/assets/javascripts/ && yarn add LIB_NAME
¿Cómo estará disponible este complemento en el plugin?

Solo me pregunto si esto es posible hoy en día (¿y si es así, cómo?).

Me temo que no. Los complementos de Ember se pueden agregar al núcleo de Discourse, pero no a través de complementos. Eventualmente podríamos agregar alguna forma para que los complementos/temas especifiquen dependencias de npm, pero no está en el plan inmediato.

Estaba buscando literalmente lo mismo.

– Pregunta secundaria para @david, aunque no está disponible a través de complementos, ¿podríamos teóricamente agregar un complemento al núcleo y luego usarlo en un complemento si nos autoalojamos? Si es así, ¿cómo? (Intenté agregarlo a package.json en app/assets/javascripts/discourse pero no tuve suerte al cargarlo, imagino que porque me falta algo simple.

sí, pero realmente no quieres bifurcar Discourse y luego intentar incorporar todos los commits. Todos los que lo han hecho lamentan mucho haberlo hecho.

Hmm. Pero si es solo un archivo, podrías concebiblemente hacer que tu app.yml copie el archivo de algún lugar a /var/www/discourse justo después de haber clonado Discourse. Creo que he hecho eso antes para cambiar los límites en la configuración del sitio.

Sí, como mencionó @pfaffman, podrías lograr que funcione mediante algunas modificaciones en app.yml. Tendrías que asegurarte de que la modificación se realizara antes de los pasos yarn install y assets:precompile.

Pero esto no tiene ningún soporte y podría romper cosas inesperadamente. No lo recomendaría.

Por curiosidad, ¿qué complemento esperabas usar?

Aún no había llegado tan lejos, sin embargo, he descubierto que la mayoría de los complementos populares tienen funcionalidades que ya existen dentro del propio Discourse. El atractivo de los complementos es que, en general, la documentación es un poco mejor y los recursos disponibles si te atascas están bastante bien desarrollados. Por ejemplo, hay una riqueza de documentación y problemas que se han "resuelto" con ember-concurrency, por lo que si eres un nuevo desarrollador, tener acceso a ese complemento generalmente significaría que puedes ponerte en marcha un poco más fácilmente.

Pero como dije, fue más una curiosidad que una necesidad.

Así que literalmente estás buscando problemas. Te recomiendo que no consideres ningún complemento hasta que descubras que los recursos existentes no satisfacen tus necesidades.

Pero no sabes si va a ser compatible con la forma en que Discourse resuelve ese problema hoy o en el futuro. Si quieres desarrollar para Discourse, mirar ejemplos de cómo funcionan las cosas en Discourse será el camino a seguir.

No seas el tipo que busca sus llaves debajo de la lámpara en lugar de debajo del coche donde las dejó caer porque se ve mejor debajo de la lámpara.