아래 그림에서 볼 수 있듯이, 일반 플러그인은 커스텀된 “css+html”이 없으며, 대부분의 “테마 컴포넌트”는 “css+html”을 조정해야 하는 경우가 많습니다. 이로 인해 대량의 대응하는 커스텀 CSS를 생성하게 되며, 이를 식별하기가 어려워집니다.
2개의 좋아요
일반적으로 코드를 시간에 따라 추적하기가 더 쉬워지므로 GitHub 또는 유사한 버전 관리 시스템 사용을 권장합니다.
이전에는 모든 테마와 테마 컴포넌트에 CSS/HTML 버튼을 포함하고 있었지만, 원격 테마를 편집할 때 원격 저장소의 업스트림 변경 사항이 로컬 커스터마이징을 덮어쓰는 문제가 발생했습니다. 이로 인해 업데이트를 꺼리는 매우 좋지 않은 경험이 초래되었습니다.
가능한 해결책 중 하나는 커스터마이징 계층을 원격 저장소와 분리하는 것입니다. 이는 현재 우리가 권장하는 방식(원격 테마의 로컬 커스터마이징을 위해 테마 컴포넌트를 사용하는 것)과 본질적으로 동일하지만, 단계를 몇 가지 줄인 형태라고 볼 수 있습니다.
7개의 좋아요
특히 테마 컴포넌트에 대해서는, 테마 컴포넌트를 포크한 후 해당 포크에서 변경 사항을 적용하는 것이 하나의 해결책입니다.
1개의 좋아요
제가 말하려는 것은, 다른 사람들이 만든 플러그인을 사용할 때 외형 조정을 위해 사용자 지정 CSS가 필요한 경우가 많다는 것입니다. 하지만 해당 플러그인에는 사용자 지정 CSS 옵션이 제공되지 않아, 각 플러그인에 맞춰 독립적인 CSS 플러그인을 만들어야 합니다. 그 결과 플러그인이 너무 많아져서 매우 혼란스럽습니다.
따라서 공식 팀이 GitHub에서 플러그인을 사용할 때 커스터마이징을 지원해 주셨으면 합니다. 예를 들어, 플러그인을 설치한 후 자동으로 사용자 지정 가능한 CSS+HTML 옵션을 붙이는 방식이죠. 설정하지 않으면 데이터를 저장할 필요가 없고, 설정하면 "플러그인 ID"에 따라 데이터가 생성되어 저장되는 방식입니다. 물론 구체적으로 어떻게 구현해야 하는지는 모르겠습니다.
제가 가진 사용자 지정 CSS의 양을 보시면 이 문제가 얼마나 복잡한지 정말 이해하실 수 있을 것입니다. 다른 사람의 GitHub 플러그인 업데이트 때문에 제 사용자 지정 CSS 파일을 찾지 못하는 경우가 자주 발생합니다…
특정 플러그인에 대한 커스텀 CSS를 추가하는 독립적인 테마 컴포넌트가 있는 Discourse 인스턴스를 정리하고 싶다면, 설치된 플러그인들에 대해 원하는 모든 고유한 커스터마이징을 담당하는 단일 테마 컴포넌트를 만드는 것이 좋습니다.
그 테마 컴포넌트 내부에서는 모든 파일을 여러 개의 .scss 파일로 나누고, 메인 common.scss 파일에 import할 수 있습니다.
my-theme-component/
├── about.json
├── common/
│ ├── common.scss
│ └── head_tag.html
├── scss/
│ ├── announcement-bar.scss
│ ├── banner-featured-links.scss
│ ├── category-banners.scss
│ ├── disco-toc.scss
│ ├── topic-list-excerpts.scss
│ ├── topic-list-thumbnails.scss
│ └── disco-toc.scss
└── settings.yml
3개의 좋아요
커스텀 CSS를 구현하는 방법이 많다는 것은 알고 있지만, 저는 이 주제를 통해 Discourse를 더 유용하게 만들고 제안을 드리고자 이 글을 올렸습니다. 답변의 결과를 이해합니다. 요약하자면, Discourse를 더 간결하게 만드는 데 관심이 없다는 뜻이죠. 답변을 업데이트해 주시면 이 주제를 닫을 수 있습니다.
아, 맞아요, 제 실수였습니다. 오해했네요. 주로 여러분의 특정 상황에 도움이 될 수 있는 제안을 드리고, 테마 컴포넌트를 위한 .scss 파일 분리 기능을 강조하고 싶었어요. 해당 기능을 아직 모르고 계실 것 같아서요.
아마 이 주제는 Contribute > Feature 채널에 더 적합할 것 같습니다. 그러면 프로덕트 팀이 의견을 제시하고, 추가하기에 적합한지 평가해볼 수 있을 거예요.
2개의 좋아요
저는 컴포넌트 설정 내에 CSS 관련 커스터마이징 계층을 별도로 두고, 이를 활성화하거나 비활성화하는 버튼을 두는 방식을 선호합니다. HTML 관련 사항은 별도 계층에서는 의미가 없다고 생각하므로, 컴포넌트를 포크하는 것이 가장 좋습니다. 이렇게 하면 사용자가 관리하기가 더 쉬워지고 불필요한 컴포넌트 부풀림도 줄일 수 있습니다. 
4개의 좋아요
이것은 최근 @david와 제가 함께 논의해 본 주제입니다.
이 아이디어는 고려해 볼 가치가 있다고 생각하지만, 위험 요소에 대해 신중하게 생각해 봐야 합니다. 테마 시스템은 이미 상당히 유연한데, 사람들이 스스로 문제를 일으키는 경우는 이미 여러 가지가 있고, 이것이 즉시 드러나지는 않기 때문입니다.
테마, 컴포넌트, 그리고 수동 커스터마이징을 통해 변하는 Discourse 위에 무언가를 얹다 보면, 스스로 구축한 의존성 그래프의 어떤 노드에서든 깨지는 변경 사항에 노출될 수 있습니다.
가까운 미래에 테마 관련 작업을 몇 가지 진행할 예정이며, 이는 테마 시스템을 다양한 방식으로 시험대에 올릴 것입니다. 이 과정에서 특정 변경 사항에 우선순위를 부여하게 될 수 있지만, 동시에 보다 유지보수하기 쉬운 커스터마이징을 어떻게 가능하게 할지에 대해 더 깊이 고민하게 될 것입니다. 그것이 어디로 향할지는 아직 명확하지 않지만, 이 요청에 대한 우리의 입장을 결정하는 데 참고가 될 수 있습니다.
4개의 좋아요