# 토픽 표시 페이지가 로드될 때 토픽 ID 가져오기
**URL:** https://meta.discourse.org/t/get-topic-id-when-the-topic-show-page-loads/155620
**Category:** Development
**Created:** [6월 22, 2020, 9:05오후 UTC](https://meta.discourse.org/t/get-topic-id-when-the-topic-show-page-loads/155620 "2020-06-22T21:05:32Z")
**Posts on this page:** 20
**Page:** 1
제 테마에서 토픽 상세 페이지가 로드될 때 해당 토픽의 id(가능하면 이름도, 하지만 id만으로도 충분합니다)를 가져와야 합니다.
그 후 이 정보를 제 테마에서 사용하여 토픽에 대한 정보를 가져오는 API 호출을 수행합니다(`forum-name/t/topic-name/id.json`과 같은 엔드포인트로 호출하는 방식이죠…)
토픽 상세 페이지가 로드될 때 토픽의 id를 어떻게 가져올 수 있을까요?
> **명백한 방법들은 충분하지 않습니다**
>
> 명백한 해결책은 URL에서 정보를 가져오기 위해 window.location.href 또는 window.location.pathname을 사용하는 것입니다. 문제는 토픽 상세 페이지의 URL이 다양한 형태를 취할 수 있다는 점입니다. 보통 다음과 같은 형태입니다:
> `forum-name/t/topic-name/topic-id`
>
> 만약 항상 이 형태라면 window.location.pathname을 사용하는 것이 잘 작동할 것입니다—"t/topic-name/topic-id"를 반환해 주니까요.
>
> 하지만 때로는 토픽 상세 페이지 URL에 토픽의 카테고리 순서도 추가되어, URL이 다음과 같을 수 있습니다: `forum-name/t/topic-name/topic-id/category-index`
>
> 따라서 window.location.pathname만으로는 부족합니다. 왜냐하면 마지막 파라미터가 topic-id인지 category-index인지 프로그래밍 방식으로 알 수 없기 때문입니다.
>
> 이를 정규식(regex)으로 해결하는 방법이 있을 수 있지만, 상당한 정규식 실력이 필요합니다. 또한 페이지 내 id를 제공할 수 있는 요소를 확인하는 방식으로 jQuery를 사용하여 해결할 수도 있지만, 아직 성공하지 못했습니다.
---
> [@JQ331](#):
>
> 하지만, 때로는 주제 표시 페이지 URL에 주제의 카테고리 순서도 추가되어, URL이 `forum-name/t/topic-name/topic-id/category-index` 형태가 됩니다.
이것이 언제/어디서 발생하는 건가요? 찾아볼 수 없었습니다.
어쨌든, 이 주제가 로드되면 `link` 요소가 있습니다:
```plaintext
```
거기서 가져올 수 있을 겁니다. 🙂
---
제 포럼에서는 실제로 주제를 클릭할 때 대부분 이런 일이 발생합니다. 카테고리를 통해 주제를 클릭한 경우, URL의 마지막 부분은 해당 주제가 속한 카테고리 내의 번호가 됩니다. 아마도 이는 discourse의 설정 때문일까요? meta-에서는 그런 일이 일어나지 않는 것 같지만, 제 포럼에서 그런 일이 일어나도록 특별히 뭔가 하고 있다고 생각하지는 않습니다.
하지만 항상 이렇게 될 것이라고 신뢰할 수는 없습니다. 주제가 카테고리 내의 첫 번째 주제인 경우, 카테고리 인덱스가 추가되지 않기 때문입니다. 제가 볼 때, 현재로선 주제가 카테고리 인덱스에 나타날지 여부를 판단할 좋은 방법이 없는 것 같습니다.
div에서 ID를 가져오는 것은 괜찮지만, 불행히도 URL이나 기타 직접적인 방법으로 가져오는 것보다 꽤 느립니다. 만약 다른 해결책이 없다면, 그 Href의 값을 가져오는 Jquery 구문을 아시나요?
---
무엇을 달성하려고 하시나요?
> [@JQ331](#):
>
> 그 다음 이 정보를 내 테마에서 사용해 토픽에 대한 정보를 가져오기 위해 API 호출을 합니다(예: `forum-name/t/topic-name/id.json`와 같은 엔드포인트로 호출)…
이 방식은 작동할 수 있지만, 모든 사용자(익명 사용자 포함)가 토픽 페이지를 볼 때마다 추가적인 AJAX 요청을 보내므로 효율적이지 않습니다. 이로 인해 서버에 불필요한 부하가 많이 발생하게 됩니다.
> [@JQ331](#):
>
> 하지만, 때로는 토픽 표시 페이지 URL에 토픽의 카테고리 순서도 추가되어 URL이 `forum-name/t/topic-name/topic-id/category-index` 형태가 됩니다.
그렇지 않습니다. 기본 Discourse 설치 환경에서 토픽 URL은 다음과 같은 형태입니다.
```plaintext
your.site.com/t/topic_title/topic_id/linked_post_number(선택 사항)
```
기본 설치 환경의 URL에는 카테고리 순서가 포함되지 않습니다.
해결하려는 문제를 설명해 주시면, 해결책을 설명해 주시는 것보다 더 잘 도와드릴 수 있습니다.
---
> [@Bcat](#):
>
> ```plaintext
> api.onPageChange((url, title) => {
> var res = url.match(/\/t\/(.*?)\/(\w+)/);
> if (res && res[2] > 0) {
> console.log(res[2]);
> }
> });
>
> ```
동작합니다! 정말 감사합니다. 여기서 match 메서드를 사용하여 URL을 통해, 제가 추측하기로는 세 번째 “”/““의 출현을 가져오는 것 같습니다. ID는 항상 URL의 세 번째 “”/”” 뒤에 위치하기 때문이죠. 이는 “/t/name/id/otherstuff” 형식을 반환합니다. 당신의 정규식이 어떻게 이 작업을 수행하는지에 대해 조금 설명해 주실 수 있을까요? 제 정규식 학습에 매우 도움이 될 것입니다.
> [@Johani](#):
>
> `your.site.com/t/topic_title/topic_id/linked_post_number(optional)`
정보 감사합니다. 따라서 "linked\_post\_number"가 때때로 표시되어 제 API 호출을 방해하는 것 같습니다. 여기서는 "선택적(optional)"이라고 하셨는데, 이것이 절대 표시되지 않도록 보장하는 방법이 있을까요?
> [@Johani](#):
>
> What are you trying to achieve?
사용자가 주제(topic) 표시 페이지를 방문할 때, 저는 다음을 원합니다:
1. 해당 주제와 연관된 모든 태그를 프로그래밍 방식으로 파악하는 것입니다. 참고로 일부 태그는 사용자 보기에서 숨겨져 있습니다.
2. 주제 페이지에 버튼을 두어, 클릭 시 (숨겨진 태그가 아직 없다면) 특정 숨겨진 태그를 주제에 추가하고, (이미 숨겨진 태그가 있다면) 클릭 시 그 태그를 제거하는 것입니다.
이는 Admin API와 javascript/jquery를 사용하여(API 호출에 사용할 올바른 주제 URL을 얻을 수 있다면) 모두 직관적으로 가능합니다.
이러한 작업을 수행하는 유일한 다른 방법은 1. ember, 2. rails, 3. discourse 코드베이스에 깊이 들어가는 플러그인을 만드는 것이라고 생각합니다. 이 작업을 수행하는 방법에 대한 주요 discourse 게시물과 문서를 검토했지만, 이 세 가지를 정말로 이해해야 하므로 진행이 느리다는 것을 발견했습니다. 따라서 지금은 API 접근법에 집중하고 있습니다.
서버 부하를 줄일 수 있는 다른 방법이 있는지 알 수 있다면 관심이 있습니다.
---
토픽 페이지를 로드하면 클라이언트 측에 완전히 구성된 토픽 객체가 로드됩니다. 이제 이를 사용하려면 해당 데이터를 활용하기 위해 템플릿에 자체 코드를 추가하거나, 로드된 데이터를 활용하기 위해 클래스를 `reopen`해야 합니다(즉, 기본적으로 자체 계산 속성을 만들어 템플릿에서 사용하는 것입니다). 추가 API 호출 없이 클라이언트 측에 필요한 대부분의 데이터(아마도 필요 이상으로 많은 데이터)가 로드되어 있습니다. 또한 기존 템플릿에 자체 마크업을 넣으려면 `plugin-outlet`도 필요합니다.
위에서 언급한 용어들을 코드베이스/메타에서 살펴보면 도움이 될 것입니다. 시간적 여유가 허락하는 한, 막히면 기꺼이 도움을 드리겠습니다. 감사합니다.
---
감사합니다. 말씀하신 기본 사항 중 일부는 잘 알고 있지만, 막히는 부분이 하나 있습니다(이런 문제로 어려움을 겪는 사람이 많을 것 같습니다):
토픽 표시 페이지에서는 /templates/components/topic-category.hbs 템플릿이 로드됩니다. 이 템플릿이 카테고리 및 토픽 제목 아래에 표시되는 태그를 렌더링합니다.
topic-category에서는 `topic.tags`가 나열됩니다. 따라서 이 부분을 작동시키는 데 필요한 핵심 정보입니다.
여기서 막히는데: **topic.tags 정보를 제 JavaScript로 가져오는 방법은 무엇일까요?**
예를 들어, topic.tags의 내용만 console.log로 출력하고 싶다면 어떻게 해야 할까요?
* * *
템플릿을 오버라이드하는 방법은 알고 있습니다. 예를 들어, 테마에서 `discourse/templates/components/topic-category.hbs` 경로에 파일을 배치하고, 해당 템플릿을 다시 출력하면서 뷰에 원하는 변경 사항을 추가할 수 있습니다. ([여기](https://meta.discourse.org/t/splitting-up-theme-javascript-into-multiple-files/119369)에 설명된 개별 파일 구조를 사용하고 있습니다).
제 테마에서는 `theme/initializers/initializer-file.js.es6` 경로에 JavaScript를 배치하는 방법도 알고 있습니다.
그리고 일부 jQuery를 사용하여 두 요소를 상호 작용하게 만들 수 있습니다. 예를 들어, 템플릿에서 topic.tags를 div에 넣고, 이니셜라이저에서 jQuery를 사용하여 해당 div의 내용을 가져올 수 있습니다.
하지만 이 방법은 우회적입니다. topic.tags 정보를 직접 가져와서 파싱하고 조작할 수 있는 방법은 무엇일까요?
---
> [@JQ331](#):
>
> topic.tags의 내용만 console.log로 출력하고 싶다면 어떻게 해야 하나요?
전체 topic을 console.log로 출력한 후 필요한 키를 찾는 것이 좋습니다. jQuery 관련 상호작용은 컴포넌트 내에서 수행해야 하며, 실제로 그렇게 해야 합니다. 여기서는 `didInsertElement`라는 컴포넌트 훅이 유용합니다.
> [@JQ331](#):
>
> topic.tags 정보를 직접 가져와서 파싱하고 조작하려면 어떻게 해야 하나요?
질문 내용으로 보아, 해당 컨트롤러/컴포넌트에서 `topic.tags`에 의존하는 계산 프로퍼티(computed prop)를 만들어서 조작된 결과를 반환해야 할 것 같습니다. 이렇게 하면 템플릿에서 바로 사용할 수 있습니다. 또한, 이런 것들에 대해 포기하지 마세요. 시간이 좀 걸리겠지만, 기대 이상의 좋은 결과로 돌아올 것입니다.
---
> [@fzngagan](#):
>
> jQuery 상호작용은 컴포넌트 내에서 이루어져야 하며, 그렇게 되어야 합니다.
"컴포넌트 내에서"라는 것이 무슨 뜻인가요? jQuery 코드를 어떤 파일에 작성해야 하나요? (제 테마에서는 theme/intializers/intializer-file.js.es6 파일에서 jQuery를 사용할 수 있지만, 그것은 컴포넌트 "내부"라고 보기 어렵습니다.)
> [@fzngagan](#):
>
> `didInsertElement`는 여기에서 유용한 컴포넌트 훅입니다.
didInsertElement 코드는 어떤 파일에 작성해야 하나요?
---
이 시점에서는 Ember 가이드를 꼭 확인해 보시길 권합니다. 컴포넌트는 배포하고 다른 요소에 연결할 수 있는 기능의 묶음입니다.
> **[Core Concepts - Getting Started - Ember Guides](https://guides.emberjs.com/v3.12.0/getting-started/core-concepts/)**
>
> Before you start writing any Ember code, it's a good idea to get an overview of how an Ember application works.
>
> Router and Route Handlers
>
> Imagine we are writing a web app for a site that lets users list their properties to rent. At any given...
---
고맙습니다, 여러분. 모두 유용한 정보입니다. 현재 가이드와 일반 문서를 확인하고 있습니다. (i) jQuery 코드와 (ii) didInsertElement 코드를 어디에 넣어야 하는지 해당 파일의 이름을 알 수 있다면 매우 도움이 될 것입니다. 이런 구체적인 정보는 추가 검토를 진행하는 데 큰 도움이 될 것입니다.
---
> [@JQ331](#):
>
> “컴포넌트 내부” – jquery 코드를 위해 어떤 파일을 사용해야 하나요?
컴포넌트란 Ember 컴포넌트를 의미합니다.
> [@JQ331](#):
>
> 컴포넌트 “내부”에 있는 것으로 보이지 않습니다)
모든 종류의 Ember 클래스를 `reopen`하여 코드를 주입할 수 있습니다. 더 잘 이해하려면 그렇게 하는 플러그인/테마를 찾아보시기 바랍니다.
---
@JQ331 아시다시피, 구글에서 정규식을 찾아서 여기에 시도해 봤습니다! 가장 좋은 결과를 얻으려면 다양한 변형을 입력해 보세요.
> **[regex101: Online Regex Tester, Builder & Debugger](https://regex101.com/)**
>
> Build, test and debug regex online with real-time matches and clear explanations. Supports PCRE2, JavaScript, Python and more. Save and share your examples.
---
> [@JQ331](#):
>
> 사용자가 주제 표시 페이지를 방문할 때 다음을 수행하고 싶습니다:
>
> 1. 해당 주제와 연관된 모든 태그를 프로그래밍 방식으로 파악하는 것입니다. 일부 태그는 사용자 화면에서 숨겨져 있습니다.
> 2. 주제 페이지에 버튼을 배치하여, 클릭 시 해당 숨겨진 태그가 주제에 없다면 추가하고, 이미 있다면 제거하는 기능을 구현하는 것입니다.
이것은 플러그인 영역에 해당한다고 생각합니다.
태그가 일반 사용자에게 숨겨져 있다면, 추가적인 호출이 어떻게 도움이 될까요? 직렬화기(serializer)는 어쨌든 일반 사용자에게 해당 태그를 숨겨야 합니다. 그렇지 않다면 콘텐츠 보안 구멍을 노출시키는 셈이 됩니다.
프론트엔드만 변경하는 것의 한계를 우회하기 위해 이 모든 노력을 기울이려 한다면, 추가 호출을 통한 복잡한 설정 대신 한 번에 직렬화할 수 있도록 플러그인으로 구축하는 것이 더 나은 선택일 것입니다.
---
그렇게 하면 말이 되네요. 직렬화기(serializer)를 사용하는 방법에 대해 더 알고 싶습니다. 직렬화기는 디스코urs 플러그인에서 가장 중요한 단계 중 하나이지만, 기본적인 사용 예시를 보여주는 문서를 아직 찾지 못했습니다. 해당 문서를 아시나요?
직렬화기가 해당 태그를 숨겨야 한다고 말씀하셨는데, 어떤 의미인지 감을 잡을 수 있도록 의사 코드(pseudo-code)를 제공해 주실 수 있을까요? (완전히 작동하지 않아도 괜찮습니다. 개념을 이해하려고 노력하고 있을 뿐이니까요)
---
여기입니다:
> **[RubyDoc.info:
Class: ActiveModel::Serializer
– Documentation...](https://www.rubydoc.info/gems/active_model_serializers/0.8.2/ActiveModel/Serializer)**
>
> Documenting RubyGems, Stdlib, and GitHub Projects
이것은 재즈 음악과 비슷합니다. 기존 오픈소스 플러그인 생태계에 이미 최고의 관행이 존재하죠. 마치 모든 레코드들처럼요. 모든 것을 어떻게 해야 하는지에 대한 완벽한 가이드를 기대하기보다는, 대부분의 경우 이전 사례에서 배우는 데 익숙해져야 합니다.
#customization:plugin에서 기능적으로 유사하거나, 하고 싶은 것의 일부 요소를 수행하는 플러그인을 찾아서 코드를 살펴보세요. 그것이 어떻게 일을 달성하는지 확인하는 것입니다. [Discourse 소스 코드](https://github.com/discourse/discourse)도 마찬가지입니다. 이를 궁극적인 '베스트 프랙티스’의 출처로 사용할 수 있으며, 특히 Discourse와 관련하여 그렇습니다.
기존 플러그인을 로컬로 클론하고 몇 가지 사항을 변경해 보세요. 실험해 보세요.
시리얼라이저(Serializer)는 컨트롤러/모델에서 전송되는 것을 필터링할 뿐이며, 기본적인 조작도 수행할 수 있습니다.
---
소스에서 가져온 예시를 하나 보여드리겠습니다: [discourse/app/serializers/concerns/topic\_tags\_mixin.rb at 888e68a1637ca784a7bf51a6bbb524dcf7413b13 · discourse/discourse · GitHub](https://github.com/discourse/discourse/blob/888e68a1637ca784a7bf51a6bbb524dcf7413b13/app/serializers/concerns/topic_tags_mixin.rb)
```plaintext
def tags
# Calling method `pluck` along with `includes` causing N+1 queries
tags = topic.tags.map(&:name)
if scope.is_staff?
tags
else
tags - scope.hidden_tag_names
end
end
```
여기서 스태프가 아닌 사용자에게는 숨겨진 태그가 제외되는 것을 볼 수 있습니다.
[다음 페이지](https://meta.discourse.org/t/get-topic-id-when-the-topic-show-page-loads/155620.md?page=2)