테마 컴포넌트 v 플러그인: 차이점

테마와 플러그인, 그리고 제가 언급했던 구체적인 예시에 대해 매우 유용한 답변이네요. 감사합니다.

지금까지 변경 사항을 입력하는 방식은 Discourse 코드의 세부 사항을 파고드는 것이었습니다(이 객체는 어디에 정의되어 있는가, 이 템플릿은 무엇에 의해 제어되는가, 이 작업을 처리하는 로직은 어디에 있는가 등). 하지만 이 방법은 매우 느렸습니다.

아마도 더 효율적인 방법은 API에 초점을 맞추는 것일 것 같습니다. 이렇게 하면 성숙한 Discourse 코드의 모든 세부 사항을 파고들 필요가 없고, 플러그인 대신 테마를 구축하는 데 집중할 수 있습니다–아니면 단순히 “customize” 대시보드에서 변경 사항을 입력하는 것만으로도 충분할 수 있습니다.

결국, API가 어떻게 작동하는지 파악하는 것이 Discourse 코드베이스를 파악하는 것보다 훨씬 관리하기 쉬워 보입니다.

제가 언급했던 예시에 맞춰 생각해보겠습니다: 사용자가 특정 카테고리의 moderatord(모더레이터)라면, 그 사용자에게 카테고리 페이지에서 토픽을 고정할 수 있는 권한을 부여하는 것입니다.

플러그인 없이 이 작업을 수행할 수 있을까요? 제가 그려본 시나리오를 한번 살펴보겠습니다:

1. 사용자가 카테고리의 moderatord(모더레이터)인가?

현재 api에서 사용자가 특정 카테고리의 moderatord(모더레이터)인지 알려주는 것을 찾지 못했습니다. 카테고리를 가져오는 GET 요청에서 찾아볼 수 있을 것으로 예상했지만, 그런 요청을 찾지 못했습니다. 아니면 사용자를 가져오는 GET 요청에서 찾을 수 있을지도 모르지만, 거기서는 사용자가 moderatord(모더레이터)로 있는 카테고리 목록을 볼 수 없었습니다.

이 정보를 추가할 수 있을까요?

또는 대안으로, 사용자가 moderatord(모더레이터)임을 식별하기 위해 사용자 또는 카테고리에 custom_field를 생성한 다음, 카테고리 페이지가 로드될 때 해당 커스텀 필드를 호출하는 API 요청을 만들 수도 있습니다.

2. 사용자가 moderatord(모더레이터)인 경우 고정 버튼 표시.

(1)번 질문에 답할 수 있다면, 사용자가 moderatord(모더레이터)인 경우에만 버튼을 표시하도록 프론트엔드 JavaScript+CSS로 이 버튼을 추가할 수 있을 것이라고 가정합니다.

3. 사용자(moderatord)가 버튼을 클릭하여 토픽 고정

API에서 토픽은 “pinned” 속성(부울 값)을 가진 것 같습니다. 각 토픽은 하나의 카테고리에만 속하는 것으로 보이므로, 이는 해당 카테고리에서 토픽이 고정되어 있는 상태와 일치한다고 가정합니다.

따라서 여기서 moderatord가 “고정” 버튼을 누르면, 토픽의 “pinned” 상태를 True로 업데이트할 수 있을 것입니다. 이것이 작동하지 않는다면, 커스텀 필드도 해결책이 될 수 있습니다(다만, 토픽에 커스텀 필드를 추가하는 방법을 아직 찾지 못했습니다).


즉, 위와 같이 또는 유사한 방식으로 API를 사용하면, 플러그인을 사용하여 수행했을 경우 Discourse 코드베이스의 파일들을 많이 파고들어야 하는 작업을 훨씬 쉽게 달성할 수 있을 것 같습니다.

이렇게 이해하는 것이 맞을까요?