디자인 커스터마이징을 위해 플러그인 대신 테마 사용을 권장한다는 점을 확인했습니다. 어떤 장점이 있나요?
개발자 관점에서는 테마가 다소 번거롭게 느껴집니다. 코드 변경 사항을 실시간으로 확인하려면 Theme CLI console이라는 추가 도구가 필요합니다.
테마가 사용자가 선택할 수 있다는 점(저는 이 기능이 필요하지 않습니다)도 이해하고 있습니다.
프로덕션 환경에서 테마가 플러그인보다 갖는 장점은 무엇인가요?
제 생각은 다음과 같습니다:
- 빌드 시가 아닌 런타임에 설치 시점에 판단하며, 다운타임이 전혀 없습니다.
- 비활성화 및 제거가 더 쉽습니다.
- 콘솔에 접근할 수 없는 호스팅 클라이언트도 사용할 수 있습니다.
하지만 제 의견으로는, 개발자 관점에서 플러그인을 탐색하는 것이 보통 더 쉽습니다.
Splitting up theme Javascript into multiple files 기능이 추가됨에 따라, 이제 테마를 통해 Ember로 플러그인이 할 수 있는 모든 것을 효과적으로 수행할 수 있습니다.
따라서 라우트를 생성하거나, 직렬화기를 수정하거나, 사용자 정의 데이터를 저장할 필요가 없다면, 테마만으로 원하는 결과를 달성할 수 있을 가능성이 높습니다.
지원 관점에서 사용자 정의 플러그인의 가장 큰 문제는 사이트 장애입니다. 이는 보통 플러그인이 코어에서 변경된 Rails 클래스나 메서드에 패치되어 있지만, 플러그인이 아직 이에 맞춰 업데이트되지 않았기 때문에 발생합니다. Ember 측에서 변경 사항이 생겨 테마나 테마 컴포넌트가 깨지더라도 사이트가 올바르게 렌더링되지 않을 수 있지만, /safe-mode를 사용하여 빠르게 비활성화할 수 있습니다.
말씀하신 내용에 동의합니다. 또한 이 게임을 사용하면 로컬에서 테마를 개발하고, API 키가 있는 모든 Discourse 사이트(테마-크리에이터.discourse.org 포함)로 동기화할 수 있습니다. 해당 게임만 실행 중이라면 로컬 개발 환경을 설정할 필요조차 없습니다.
와, 여기 댓글들이 정말 훌륭하네요. 제가 추가로 할 말은 별로 없습니다.
제가 중요하다고 생각하는 유일한 추가 사항은, Discourse 내부에서 현재 일부 플러그인을 "백엔드용 플러그인"과 "프론트엔드용 테마"로 분리하는 데 힘쓰고 있다는 점입니다. 이렇게 혼합된 상태에서는 "배포"라는 문제를 고려해야 하기 때문입니다.
전반적으로 제 매우 강력한 권장 사항은, 플러그인이 절대적으로 필요한 경우에만 플러그인 생성으로 대체하도록 하는 것입니다. Ruby 백엔드를 수정해야 하는 상황에서는 선택지가 없습니다. 프론트엔드에만 변경을 가하는 플러그인은 강력히 비권장됩니다. 최신 버전을 유지하기가 더 어렵고, 사용 측면에서도 훨씬 유연하지 않기 때문입니다.