It is an option, but in my development and work surrounding it is not, and I personally would not use it because Vue seems like a natural fit for these kind of applications.
Just a bit of context:
In last couple of months I’ve been working on developing a pretty custom theme for a client, where l learned a bunch of stuff about inner workings of discourse, but that’s probably a small percentage.
Currently, I’m refactoring bunch of beginner mistakes and trying to make things friendly as possible for future colleagues that could end up maintaining my work. That’s way, I did a bit of experimentation regarding JSX.
Today, I tried the approach from the first post in topic. I’ve included transform-react-jsx here: 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
And changed the pragma setting in vendor/assets/javascripts/babel.js on line 26586
var id = state.opts.pragma || "React.createElement";
// to
var id = state.opts.pragma || "h";
That has enabled me to use h function from virtual-dom instead of React.createElement in the babelfied code. h is part of discourse and this felt like a natural fit.
I don’t know the history of discourse development, and you probably had your reasons for adding fullblown babel.js file with bunch of useful plugins in the code. It’s a shame that these plugins are not available to end developer user like me. So my proposal would be to:
-
use some kind of babel config, .babelrc, .babel.yml, or in about.json define a babel config field like in package.json Configure Babel · Babel. That config could reference all these plugins in babel.js (or maybe some others, check 3.)
-
In discourse_js_processor.rb#babel_parse `https://github.com/discourse/discourse/blob/master/lib/discourse_js_processor.rb#L138 read this config and extend it the current config.
-
If a developer wants to have an custom babel plugin, he could add it to it’s vendor/assets/javascripts/babel/plugins folder (or just babel/plugins folder) and discourse would pick it up and us it in transpile process.
I’m not experienced in Rails backend development - so this is my meta proposal.
And another question, while we’re at it, how hard would it be for discourse to read the dependencies from lets say themes package.json and installed them on first run and use the (have them cached or something like that) inside of theme? (If dependencies change, check which changed and install or remove them, etc).
Once again, you guys are doing a great job and your work is amazing. Please, don’t feel any pressure from my side, I’m just here for learning and from some good discussion and sharing opinions and ideas. I do not expect from you to implement my requests nor anything.
. I would like to use power of JSX which is actual JS instead of 
.