Ember는 하나의 선택지이긴 하지만, 제가 개발하고 그 주변에서 일하면서 느낀 바로는 그렇지 않습니다. 또한 저는 Vue가 이러한 유형의 애플리케이션에 자연스러운 선택지처럼 보이기 때문에 개인적으로 사용하지 않을 것입니다.
약간의 맥락을 설명하자면:
최근 몇 달간 저는 클라이언트를 위해 상당히 커스텀한 테마를 개발하는 데 시간을 보냈습니다. 이 과정에서 Discourse의 내부 작동 방식에 대해 많은 것을 배웠지만, 이는 전체 경험의 아주 작은 부분일 뿐입니다.
현재 저는 초보자가 흔히 하는 실수들을 리팩터링하고, 제 작업을 유지보수하게 될 미래의 동료들이 최대한 쉽게 다룰 수 있도록 하려고 노력하고 있습니다. 그래서 JSX에 대해 약간의 실험을 해 보았습니다.
오늘, 해당 토픽의 첫 번째 게시물에서 언급된 접근법을 시도해 보았습니다. 여기 transform-react-jsx를 포함시켰습니다: 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
그리고 vendor/assets/javascripts/babel.js 파일의 26586번째 줄에서 pragma 설정을 변경했습니다:
var id = state.opts.pragma || "React.createElement";
// 다음으로 변경
var id = state.opts.pragma || "h";
이렇게 함으로써 Babel을 통해 변환된 코드에서 React.createElement 대신 virtual-dom의 h 함수를 사용할 수 있게 되었습니다. h는 Discourse의 일부이며, 이는 자연스러운 선택처럼 느껴졌습니다.
저는 Discourse 개발의 역사를 잘 모르고, 여러분은 코드에 유용한 플러그인들이 가득한 완전한 babel.js 파일을 추가하는 데 그만한 이유가 있었을 것입니다. 하지만 이러한 플러그인들이 저와 같은 최종 개발자 사용자에게 제공되지 않는다는 것은 아쉽습니다. 따라서 제 제안은 다음과 같습니다:
-
.babelrc, .babel.yml 또는 about.json과 같은 Babel 설정 파일을 사용하거나, package.json에서처럼 Configure Babel · Babel Babel 설정 필드를 정의합니다. 이 설정은 babel.js 내의 모든 플러그인(또는 3번 항목에서 확인하듯 다른 플러그인들)을 참조할 수 있습니다.
-
discourse_js_processor.rb#babel_parse에서 https://github.com/discourse/discourse/blob/master/lib/discourse_js_processor.rb#L138 이 설정을 읽고 현재 설정에 확장 적용합니다.
-
개발자가 커스텀 Babel 플러그인을 사용하려면, 이를 vendor/assets/javascripts/babel/plugins 폴더(또는 단순히 babel/plugins 폴더)에 추가할 수 있고, Discourse는 이를 감지하여 트랜스파일링 과정에 사용하게 됩니다.
저는 Rails 백엔드 개발에 익숙하지 않으므로, 이는 제 메타 제안입니다.
그리고 또 하나의 질문인데, 이 기회에 Discourse가 테마의 package.json에서 의존성을 읽고, 첫 실행 시 설치한 후 테마 내에서 사용(캐싱하거나 유사한 방식으로)하도록 하는 것이 얼마나 어려울까요? (의존성이 변경되면 변경된 항목을 확인하고 설치하거나 제거하는 등)
다시 한번 말씀드리지만, 여러분은 훌륭한 일을 하고 있으며 여러분의 작업은 놀랍습니다. 제 쪽에서 어떤 압박감을 느끼지 마시기 바랍니다. 저는 단지 배우기 위해, 그리고 좋은 토론과 의견 및 아이디어 공유를 위해 여기에 있습니다. 제가 요청한 것을 구현하거나 다른 것을 기대하지 않습니다.
. 
.