완전한 컴포넌트 API를 사용할 수 있는 유연성을 높이 평가합니다. 전반적으로 glimmer 컴포넌트의 문법을 좋아하며, 코드베이스 내 복잡도를 줄이는 데 이점이 있을 수 있다는 점도 이해합니다.
그러나 기본적인 사용 사례(버튼을 추가하고 아이콘을 부여하는 것)에서는 구 API 방식이 객관적으로 더 간결하고 이해하기 쉬웠습니다(수입(import)이 적고, 작업이 적으며, 노출되는 API 범위가 작음). 구 API 방식에 대한 지속적인 지원을 제공할 수 없는 이유가 있을까요? 구 API 방식을 편의 함수(convenience functions)로 사용하고, 내부 구현은 새로운 glimmer 컴포넌트를 통해 수행한다면, 해당 API 방식에서도 버전 호환성 검사를 수행할 수 있을 것입니다.
이렇게 하면 해당 방식을 사용하는 사용자들에게 훨씬 덜 파괴적(disruptive)일 뿐만 아니라, 플러그인 생태계 내에서 조건부 로직으로 인한 코드 폭발을 줄일 수 있습니다.
기존 위젯에 대해 제가 가진 가장 큰 불만은 문서화가 부족하다는 점입니다. 이 게시글처럼 그 제거를 알리는 글은, 해당 특정 방식이 존재하며 어떻게 사용하는지에 대해 제가 본 가장 명확한 문서 중 하나입니다. 사실 저는 구 API를 어떻게 사용하는지 알아보기 위해 여기 왔습니다.
변환기(transformer)가 문자열 리터럴로 한 곳에서 등록되는 방식을 좋아합니다. 이는 문서화(및 플러그인 개발) 업무를 훨씬 쉽게 만들어준다고 생각합니다.
위젯의 경우, 모두 createWidget 메서드에 의해 등록되며, 이는 createWidgetFrom를 호출합니다. 제가 보는 문제점은 _registry가 API로 보호되는 파일 스코프 전역 변수인데, 이 API가 반복(iteration)을 허용하지 않는다는 것입니다. 위젯 레지스트리에 반복 함수만 제공받을 수 있다면, 현재 등록된 위젯을 실시간으로 발견할 수 있을 것입니다. "브라우저 콘솔에서 이 자바스크립트 한 줄을 실행하여 API를 호출하고 레지스트리를 나열하세요"라고 문서화하면 됩니다. 그러면 변환기 레지스트리가 제공하는 것과 매우 유사한 유틸리티를 얻을 수 있을 것입니다.
플러그인 개발에 도움이 될 또 다른 점은, 컴포넌트/위젯에 의해 렌더링되는 루트 DOM 요소에 어떤 컴포넌트/위젯을 보고 있는지 알려주는 속성을 추가하는 것입니다. 예를 들어 "data-widget=foo"와 같은 형태입니다. 이는 디버그 기능이 될 수도 있고, 기본적으로 활성화될 수도 있습니다. OSS(오픈소스)이므로, 불명확성을 통한 보안(security through obscurity)을 달성하는 것이 아닙니다.
glimmer 컴포넌트로의 전환을 환영합니다. 하지만 시간이 걸릴 것이며, 그 사이 사람들이 작업해야 할 위젯이 많습니다. 따라서 위에서 언급한 대로 위젯의 가시성을 개선하면 모두에게 전이 기간(transition period)이 더 쉬워질 것이라고 생각합니다.
구 API 방식에 대해서는… 누군가 자바스크립트 API에 상세한 주석을 추가하는 데 공을 들인 것 같습니다 하지만, 이를 위한 문서 사이트는 생성된 적이 없습니다. 왜 그런가요?
만약 동의해 주신다면, 위젯 레지스트리를 반복하는 기능에 대한 풀 리퀘스트를 제출하는 것을 기꺼이 하겠습니다.