JSX en lugar de la función h (createElement) en widgets y otros lugares

Desarrollador
1

Hola, he estado experimentando con JSX en widgets para mejorar la experiencia del desarrollador en los temas (he creado mi propia configuración para el desarrollo de temas sin header.html, etc.; hablaré más sobre esto en otro tema).

Me preguntaba por qué Discourse no utiliza plugins de Babel dentro de su base de código. En Discourse tenemos disponible el plugin transform-react-jsx de Babel, que puede usarse para transformar JSX en una función createElement personalizada mediante la opción jsxPragma. Todo eso está disponible en Discourse.

Agregar transform-react-jsx aquí https://github.com/discourse/discourse/blob/master/lib/discourse_js_processor.rb#L143-L149 y, de alguna manera, exponer la configuración de Babel para cambiar el jsxPragma aquí https://github.com/discourse/discourse/blob/master/vendor/assets/javascripts/babel.js
podría hacer esto posible.

Ya he implementado la primera parte; la parte de la directiva (pragma) aún requiere más investigación. Lamentablemente, no hay un archivo .babelrc para configurar la configuración individual de los plugins. Obtengo la función React.createElement en lugar de una función personalizada.

Más información sobre el uso de JSX sin React aquí: Using jsx WITHOUT React | r0b blog

¿Alguna idea o quizás ayuda sobre cómo lograr esto?

ACTUALIZACIÓN:
Logré que esto funcione cambiando la configuración de la directiva (pragma) en vendor/assets/javascripts/babel.js, en la línea 26586:

var id = state.opts.pragma || "React.createElement";
// a
var id = state.opts.pragma || "h";
2

¿Has visto esto? Ahora puedes usar plantillas si no te gusta Hyperscript:

3

@merefield sí, conozco hbs, pero no soy “un desarrollador típico de temas de Discourse” :slight_smile:. Me gustaría aprovechar el poder de JSX, que es JavaScript real, en lugar de hbs, cuyas funcionalidades son limitadas.

Y he logrado usar JSX en un tema de Discourse ahora. Pero en mi propia bifurcación de Discourse, por lo que no es muy útil para el desarrollo general de temas.

4

En última instancia, la decisión es de @eviltrout. Sin embargo, puedo compartirte mi opinión. Sí, JSX puede ser agradable de usar y podríamos incluirlo en Discourse, pero no creo que lo hagamos, porque tendríamos que darles soporte y estamos más inclinados a eliminar los widgets en algún momento que a añadir más opciones.

5

Entiendo completamente tu punto. Solo me pregunto, ¿por qué no abrir la configuración de Babel (y de muchas otras cosas) para desarrolladores de temas y plugins?

Por ejemplo, un archivo .babelrc en la carpeta del tema podría usarse para agregar opciones adicionales al transpilador de JS. Si existe un archivo .babelrc, discourse_js_processor podría utilizarlo, ampliar su configuración de Babel y habilitar una serie de características adicionales de JS.

Solo una idea.

6

Simplemente se trata de una ‘API pública’ en un sentido amplio: todo lo que permitamos, tendremos que mantenerlo. Lo que hoy parece fácil de apoyar, mañana podría ser difícil. Definitivamente estamos experimentando con muchas cosas en la tubería y en la parte del lado del cliente de la aplicación recientemente. Veamos qué piensa Robin de todo esto.

7

Por favor, no te sientas presionado, solo soy un desarrollador curioso con algunas preguntas. Llegué a Discourse desde el mundo del desarrollo full stack en JS (Node/Vue), donde Ember simplemente no es una opción, especialmente cuando tienes React o, incluso mejor, Vue.

Ember se siente tan poco natural y handlebars está simplemente desactualizado en cuanto a sus características. El poder de plantillas de JSX y, especialmente, de los SFC de Vue, no puede compararse con algo tan básico como hbs.

8

No estoy de acuerdo en que Ember no sea una opción para el desarrollo full stack en JavaScript. Entiendo el argumento de que Ember no es tan popular como otros frameworks y que, por esa razón, podrías querer elegir otro; pero sin duda hay muchos y muchos sitios que utilizan Node en el backend y Ember en el frontend. Después de todo, todas las herramientas de Ember se basan en Node.

Dicho esto, JSX no forma parte del futuro del núcleo de Discourse, pero si hay cosas que podamos hacer para habilitar su uso en plugins, estaría abierto a ello. ¡Por favor, presenta una propuesta sobre cómo funcionaría!

9

Es una opción, pero en mi desarrollo y en el trabajo relacionado con él no lo es, y personalmente no lo usaría porque Vue parece una elección natural para este tipo de aplicaciones.

Un poco de contexto:

En los últimos meses he estado trabajando en el desarrollo de un tema bastante personalizado para un cliente, donde aprendí un montón de cosas sobre el funcionamiento interno de Discourse, pero eso probablemente sea un porcentaje pequeño.

Actualmente, estoy refactorizando un montón de errores de principiante y tratando de hacer las cosas lo más amigables posible para futuros colegas que podrían terminar manteniendo mi trabajo. Por eso, hice un poco de experimentación con JSX.

Hoy probé el enfoque del primer mensaje del tema. He incluido transform-react-jsx aquí: https://github.com/discourse/discourse/blob/master/lib/discourse_js_processor.rb#L143-L149:

      if opts[:module_name] && !@skip_module
        filename = opts[:filename] || 'unknown'
        "Babel.transform(#{js_source}, { moduleId: '#{opts[:module_name]}', filename: '#{filename}', ast: false, presets: ['es2015'], plugins: [['transform-es2015-modules-amd', {noInterop: true}], 'transform-decorators-legacy', 'transform-react-jsx', exports.WidgetHbsCompiler] }).code"
      else
        "Babel.transform(#{js_source}, { ast: false, plugins: ['check-es2015-constants', 'transform-es2015-arrow-functions', 'transform-es2015-block-scoped-functions', 'transform-es2015-block-scoping', 'transform-es2015-classes', 'transform-es2015-computed-properties', 'transform-es2015-destructuring', 'transform-es2015-duplicate-keys', 'transform-es2015-for-of', 'transform-es2015-function-name', 'transform-es2015-literals', 'transform-es2015-object-super', 'transform-es2015-parameters', 'transform-es2015-shorthand-properties', 'transform-es2015-spread', 'transform-es2015-sticky-regex', 'transform-es2015-template-literals', 'transform-es2015-typeof-symbol', 'transform-es2015-unicode-regex', 'transform-regenerator', 'transform-decorators-legacy', 'transform-react-jsx',exports.WidgetHbsCompiler] }).code"
      end

Y cambié la configuración de pragma en vendor/assets/javascripts/babel.js en la línea 26586:

var id = state.opts.pragma || "React.createElement";
// a
var id = state.opts.pragma || "h";

Eso me permitió usar la función h de virtual-dom en lugar de React.createElement en el código procesado por Babel. h es parte de Discourse y esto me pareció una elección natural.

No conozco la historia del desarrollo de Discourse y probablemente tuvisteis vuestras razones para añadir un archivo completo de babel.js con un montón de plugins útiles en el código. Es una lástima que estos plugins no estén disponibles para el usuario desarrollador final como yo. Por lo tanto, mi propuesta sería:

  1. Utilizar algún tipo de configuración de Babel, .babelrc, .babel.yml, o definir un campo de configuración de Babel en about.json como en package.json Configure Babel · Babel. Esa configuración podría hacer referencia a todos estos plugins en babel.js (o quizás a otros, ver punto 3).

  2. En discourse_js_processor.rb#babel_parse https://github.com/discourse/discourse/blob/master/lib/discourse_js_processor.rb#L138, leer esta configuración y ampliarla con la configuración actual.

  3. Si un desarrollador quiere tener un plugin de Babel personalizado, podría añadirlo a su carpeta vendor/assets/javascripts/babel/plugins (o simplemente a la carpeta babel/plugins) y Discourse lo detectaría y lo utilizaría en el proceso de transpilación.

No tengo experiencia en el desarrollo del backend de Rails, así que esta es mi propuesta meta.

Y otra pregunta, ya que estamos en ello, ¿qué tan difícil sería que Discourse leyera las dependencias de, por ejemplo, el package.json de los temas, las instalara en la primera ejecución y las utilizara (teniéndolas en caché o algo así) dentro del tema? (Si las dependencias cambian, comprobar cuáles han cambiado e instalarlas o eliminarlas, etc.).

Una vez más, estáis haciendo un gran trabajo y vuestro trabajo es increíble. Por favor, no sentís ninguna presión de mi parte, solo estoy aquí para aprender, tener una buena discusión y compartir opiniones e ideas. No espero que implementéis mis peticiones ni nada por el estilo.

10

¿A qué te refieres con eso? ¿Qué no es posible hacer con Handlebars y Ember que sí esté implementado en otro framework?

11

Lo que quiero decir es que JSX es JS, no un lenguaje de plantillas; el hecho de ser JS por sí mismo lo hace más potente (por ejemplo, el operador ternario, la función map, etc.). Puedes hacer lo que quieras en Ember/Handlebars, pero JSX es más conveniente y amigable para el desarrollador, en mi opinión.

12

¿Y funcionó? ¿Pudiste agregar JSX y todo salió bien?

Ahora, sobre las otras preguntas que tenías acerca de por qué Babel está configurado de esa manera: Discourse está construido sobre Rails utilizando el pipeline de activos, y el soporte para webpack solo se agregó en Rails en la versión 6. ¡La base de código de Discourse tiene 8 años! Con el tiempo hemos añadido cosas, pero hemos superado sus limitaciones.

Uno de los proyectos más importantes este año es la migración a Ember CLI. Si revisas nuestros commits, verás que hay trabajo en marcha hacia este objetivo en Discourse, pero es un camino largo.

Una vez que eso esté implementado, podrás utilizar muchas más características de construcción de JavaScript que actualmente no funcionan a menos que se ejecuten desde Ruby, lo cual es engorroso. Mientras tanto, no veo que dediquemos tiempo a leer package.json y hacer que esto se integre automáticamente en el pipeline de Rails.

13

Haré un PR de prueba de concepto para demostrar cómo funciona.

¡Gracias por la información y la explicación!

14

Una actualización: He logrado crear un ThemeField para Babel, que se utiliza para leer babel.config.json del tema e inyectar plugins en Babel.transform dentro de discourse_js_processor.

Espero sacar el PR pronto solo para mostrarlo como una prueba de concepto. Una advertencia: será un gran desastre :sweat_smile:.

PD: Trabajar con Ruby es tan fácil :star_struck:

15

Aquí está: