데이비드, ‘split’ 컴포넌트와 '.gjs’가 아닌 파일에 대한 지원을 언제쯤 중단할 계획이 있나요?
아마도 그렇습니다. 가까운 미래까지도 Ember가 개별 js/hbs 파일을 지원할 것으로 보이지만, 테마/플러그인 빌드 시스템을 단순화하기 위해 더 일찍 전환하는 것이 우리에게 이롭다고 판단될 수 있습니다.
hbs를 비추천(deprecate)하기로 결정하게 된다면, 모든 정상적인 비추천 주기와 공지 사항을 거칠 것이므로 갑작스러운 변화가 되지 않을 것입니다.
표준 린팅 설정을 사용하는 테마/플러그인의 경우 이미 .hbs 파일이 금지되어 있으며, gjs로 전환하기 위한 자동화 도구를 갖추고 있습니다. 해당 도구를 사용하여 CDCK 소유의 모든 테마/플러그인 업데이트를 거의 완료했습니다.
확인차 여쭤봅니다(제가 js/hbs 컴포넌트를 수정할 수 있도록). 테마 스켈레톤에서는 hbs 컴포넌트가 지원되지 않으며, gjs로 이동하는 것이 강력히 권장되는 것이 맞나요?
Hbs 파일은 계속 "지원"됩니다(즉, 여전히 작동하며, 비추천 주기를 거치지 않고 이를 변경하지는 않을 것입니다).
하지만 새로운 코드에는 .gjs를 사용하는 것이 강력히 권장되며, 기존 테마 및 플러그인의 마이그레이션을 시작해야 합니다. 스켈레톤의 최신 린팅 설정은 ‘require-strict-mode’ ember-template-lint 규칙에서 의도적으로 옵트아웃하지 않는 한 이 권장 사항을 강제합니다.
아, 이제 알겠어요. 설명해 주셔서 감사합니다!
어떤 경우든 Glimmer Components는 3배에서 5배까지 빠를 수 있다고 생각합니다. 따라서 확실히 좋은 관행인가요? (다만, 많은 추가 트래킹으로 부하를 주지 않는 한)
글리머(Glimmer) 컴포넌트는 클래식 컴포넌트보다 훨씬 더 빠릅니다, 맞습니다!
하지만 .gjs 파일 형식이라고 해서 반드시 글리머 컴포넌트인 것은 아닙니다. 코어에는 여전히 수백 개의 클래식 컴포넌트가 있으며, 이들은 이제 모두 .gjs 파일 형식으로 변환되었습니다. (명명이 혼란스럽다는 점, 알고 있습니다 
)
우리가 실행 중인 코드모드(codemod)는 js/hbs에서 .gjs로의 파일 형식 변환만 수행합니다. 컴포넌트 유형을 변경하지는 않는데, 이를 완벽하게 자동화하는 것은 거의 불가능하기 때문입니다.
그렇긴 하지만, 수동 리팩터링을 진행 중이라면 그만한 노력은 가치가 있는 경우가 많습니다.
아니, 정말요. 겨우 이해가 시작되는 줄 알았는데 말이에요.
그러니까 저만의 혼동이 아니군요! 
이것이 글리머 컴포넌트가 되는 건가요?
그렇다면; 템플릿만 있는 경우에도 클래스를 추가하면, 단순히 <template>My important words</template>만 있는 .gjs 파일보다 실행 속도가 빨라지는 건가요?
export default class MyCoolComponent extends Component {
이런 겁니다:
import Component from "@glimmer/component";
(그리고 getter 같은 Glimmer 규범 준수)
이것은 "네이티브 클래스 선언"이라고 생각합니다.
아하! 그러면 가져온 컴포넌트 부분을 사용하려면 클래스를 선언해야 하는군요.
정말 감사합니다!
여기서 제가 겪는 주요 문제는 hbs에서는 명시적인 import가 필요 없으므로 다른 테마의 컴포넌트를 참조할 수 있다는 점입니다. 하지만 gjs에서는 import가 필요하며, 다른 테마의 컴포넌트에 정의된 컴포넌트를 어떻게 참조해야 하는지 전혀 모르겠습니다.
제가 살펴본 기존 구현들은 a) 여전히 hbs를 사용하거나, b) 자바스크립트 기반 주입을 사용하는 것들뿐이었습니다.
이걸 어떻게 해야 할까요?
그 경우 다음 ESLint 권장 사항을 받게 됩니다:
이 규칙은 클래스가 실제로 필요한 경우에만 추가해야 한다고 제안하며, 그렇지 않으면 오히려 성능이 더 느려질 수 있다고 합니다.
성능이 낮은 순서대로:
-
클래식 컴포넌트:
import Component from "@ember/component"; export default class Blah extends Component { -
글리머 컴포넌트:
import Component from "@glimmer/component"; export default class Blah extends Component { -
템플릿 전용 글리머 컴포넌트:
export default <template> ... </template>
정확합니다
현재 테마는 다른 테마에서 가져올 수 없습니다. 이름 기반의 마법 같은 해상도(magic name-based-resolution)를 통해 테마 간 의존성이 가능했던 것은 의도된 것이 아니었습니다.
혹시 다른 주제에서 사용 사례를 더 자세히 설명해 주실 수 있을까요? 우리 자신의 테마에서 아직 이런 상황을 겪어본 적이 없습니다.
제가 생각하기에 당신은 이미 그렇게 하고 있는 것 같은데요… (right-sidebar-blocks).
지난주 제 주요 사용 사례는 동일한 플러그인 아웃렛을 사용하는 여러 테마 컴포넌트에 대해 순서를 강제하는 것이었습니다. CSS 파일은 알파벳 순서로 로드되지만, 테마 컴포넌트의 JS는 숫자 순서로 로드되므로, 저는 테마 컴포넌트를 제거한 후 필요한 순서대로 다시 추가하고, 이로 인해 발생하는 모든 CSS 문제를 동시에 피하려 했습니다.
그런 다음, 각 컴포넌트에서 커넥터를 제거하고 해당 플러그인 아웃렛을 위한 단일 커넥터에 다음 내용을 포함하는 새로운 테마 컴포넌트를 만들면 된다는 것을 깨달았습니다:
<ComponentFromTC1 />
<ComponentFromTC4 />
<ComponentFromTC3 />
<ComponentFromTC2 />
이 방식은 아주 잘 작동했습니다. 그리고 나서 저는 '아, 몇 달 후에 이걸 다시 하지 않으려면 gjs로 만들어야겠군’이라고 생각했습니다. 그리고 나서 
귀사 쪽으로 이주하던 중 이를 원했던 고객이 있었어요. 자세한 내용은 기억이 나지 않네요.
최근에 런칭한 현행 고객을 위해 이 부분을 포크(fork)했습니다. 몇 가지 다른 유형의 블록을 추가하고 싶어 하셨거든요. 처음에는 CSS 작업만 수행하는 자매 테마를 만들어 보려 했但最终 포기하고 포크를 진행했습니다. 다른 방법이 있었을지도 모르겠지만, 확신은 하지 못하겠습니다.
하지만…
좋은 소식이지만, 왜 더 일찍 알아차리지 못했는지 모르겠어요. 그걸 본 기억이 좀 나고, 그 문제를 논의했을 때 누군가 포크를 해야 한다고 제안한 것도 기억나요. 하지만 지금은 포크를 하지 않아도 될 것 같다는 확신이 드네요.
흠 … Discourse Bars 🍻 🍸 (a sidebar framework) … 이 시스템을 사용하는데, 나는 문제가 없었습니다.
이 시스템의 핵심은 다른 테마 컴포넌트나 플러그인의 컴포넌트를 사용할 수 있다는 점입니다(그리고 실제로 작동합니다).
right-sidebar-blocks와 discourse-tc-bars 모두 Ember 리졸버를 사용하여 이름으로 컴포넌트를 조회하고 있습니다. 현재는 잘 작동하며 비권장(deprecated) 상태도 아닙니다.
.hbs에서는 {{component "some-name"}}처럼 사용하며, (g)js에서는 resolveRegistration("component:some-name")처럼 사용할 수 있습니다.
그러나 장기적인 관점에서 이야기한다면, Ember 리졸버를 통한 컴포넌트 조회를 피하는 방향으로 나아가야 합니다. 언젠가 Embroider의 “static invokables” 플래그를 활성화하게 되면 리졸버는 비어 있게 됩니다.
right-sidebar-blocks 및 다른 유사한 크로스 테마/플러그인 컴포넌트 공유에 대해 이 방향으로 진행해야 한다고 생각합니다: