지금과 같은 방식으로, 특정 Theme Component에 종속되지 않는 일반적인 방법이 필요하다고 생각합니다.
이 기법을 사용하는 다른 Theme Component가 하나 더 있습니다:
따라서 제 쪽에서만 최소 두 건이 있고, 더 많을 수도 있습니다.
동의합니다. 저는 블록 컴포넌트 컬렉션을 구축했는데, 각 컴포넌트는 하나의 패키지에 번들링된 것이 아니라 독립적으로 작동합니다: Blocks · GitLab.
현재 저는 Homepage Blocks 컴포넌트를 사용하여 이러한 블록을 전용 홈페이지에 배치할 수 있으며, Right Sidebar Blocks나 Bars와 함께 사용하는 것과 동일한 방식으로 사용할 수 있습니다.
최근에는 Central 테마에서 커스텀 사이드바 레이아웃이 필요한 프로젝트를 진행했습니다. 커스텀 사이드바용 블록 프레임워크를 쉽게 구축하고 그 위에 블록 컴포넌트를 배치할 수 있었습니다: https://central.kostka.studio (이름만 참조하여 Powered-by-discourse 컴포넌트를 사이드바에 배치하는 것도 포함합니다).
독립적인 블록 컴포넌트는 현재 클라이언트 커스터마이징을 유연하고 유지보수 가능한 방식으로 구축하는 데 제가 가진 가장 유용한 도구입니다. 이를 지원하기 위한 일반적인 방향이 제시되면 좋겠습니다.
컴포넌트를 처리하는 가장 좋은 방법을 찾고 있어 이 주제를 다시 올려봅니다. 현재는 두 가지 옵션을 보고 있는데, 둘 다 치명적인 단점이 있습니다. 테마 컴포넌트별로 블록을 렌더링하는 레지스트리를 만들 수 있지만, 이는 모듈화라는 본래의 목적을 무너뜨리는 결과를 초래합니다. 아니면 플러그인을 통해 전역적으로 하나를 추가할 수 있지만, 그렇게 하면 내 컴포넌트가 해당 플러그인이 설치되어 있다는 것에 의존하게 됩니다.
따라서 코어에 전역 블록 등록 API가 있다면 정말 도움이 될 것 같습니다. 테마 컴포넌트가 블록 렌더링을 호출하고 새로운 블록을 등록하는 데 사용할 수 있는 것 말입니다.
블록 방식을 좋아하는데, 이는 앱 레이아웃과 컴포넌트 콘텐츠 간의 관심사를 분리할 수 있게 해주기 때문입니다. 블록 컴포넌트는 단순히 자신의 콘텐츠를 렌더링할 뿐이며, 앱의 다른 컴포넌트에 의해 렌더링됩니다. 이렇게 하면 블록 컴포넌트에서 라우트와 아웃렛 로직을 모두 제거할 수 있고, 레이아웃은 물론 앱 전체에서 동일한 블록을 여러 번 쉽게 재사용할 수 있습니다.
이 방식은 모든 것을 더 간결하고 재사용 가능하게 만들어주며, 전반적으로 우아한 접근법이라고 생각합니다. Discourse에서 이 패턴에 대한 견고한 지원을 갖춘다면 훌륭할 것입니다.
데이비드, 다른 플러그인/컴포넌트에서 사용할 수 있도록 “크로스 테마/플러그인” 컴포넌트를 등록할 수 있는 임의적(discretionary) API를 제공하는 것이 가능할까요?
이렇게 하면 모든 것을 등록할 필요는 없지만, 명시적으로 가능하도록 하는 유연성을 제공할 수 있습니다.
이 작업에 대해 범용 API를 사용하는 것이 적절할지 확신이 서지 않습니다. 컴포넌트를 사용하는 방식이 너무 다양하고, 각 방식마다 인자와 로드 시점에 대한 기대치가 다르기 때문입니다.
질문자님의 사용 사례에는 테마/플러그인별 레지스트리가 적합할까요? 위 목업처럼 우측 사이드바 블록과 같은 경우를 말하는 것입니다.
그렇지 않다면, 구체적인 예시를 제공해 주시면 어떤 종류의 API가 필요한지 정확히 파악하는 데 도움이 될 것입니다. CDCK에서 유지 관리하는 모든 테마와 플러그인은 이미 gjs로 마이그레이션되었으며, 우측 사이드바 블록과 같은 특정 사례를 제외하고는 이러한 문제를 경험한 적이 없습니다.
네, 실제로 Draft PR에 작성된 내용을 다시 꼼꼼히 읽어보니 이것이 충분히 좋은 해결책이라는 생각이 듭니다. 특히 다음과 같은 부분이 그렇습니다:
“이 커밋은 오른쪽 사이드바 블록 컴포넌트의 전용 목록을 도입하고, 다른 테마/플러그인이 추가 항목을 등록할 수 있도록 허용합니다.”
저는 이것이 핵심이라고 생각합니다. 원격으로 다른 테마와 호환되도록 등록한 후, ‘마스터’ 테마가 원격으로 등록된 요소들을 통합할 수 있게 하는 것이 제가 원했던 바로 그 것이기 때문에, 이미 이것이 가능하다는 것을 입증해 주셨다고 생각합니다.
좋아요!
매우 단순한 경우라면, “마스터” 테마에 PluginOutlet을 추가하는 것만으로 충분할 수 있으며, 그 후 다른 테마들은 renderInOutlet을 호출하거나(connectors/...에 파일을 배치하는 것) 할 수 있습니다.
맞습니다. 등록 패턴은 정말 마음에 듭니다. 아주 좋습니다. 실제로 RSB와의 호환성을 유지하는 것이 좋을 것 같습니다. Bars가 이미 동일한 파라미터 시스템을 사용하고 있기 때문에, 이를 통해 전체 시스템이 상호 운용 가능해질 수 있습니다.
이상적으로는 기본 블록이 테마 팩으로 제공되고, '모선(mother ship)'은 별도의 TC로 구성되는 것이 좋겠습니다. 그러면 Bars를 모선 역할로 교체하여 확장된 레이아웃 기능을 활용할 수 있으면서도, 팩은 계속 재사용할 수 있습니다. 다만 최종 사용자 관리나 CDCK 유지보수 측면에서는 너무 복잡할 수 있다는 점은 이해합니다!