안녕하세요.
최근 Discourse를 다루기 시작했는데, 1주일간의 경험을 바탕으로 확실히 말할 수 있는 것은 실제 Core 부분을 수정해야 하는 개발자에게 진입 장벽이 꽤 높다는 것입니다. 이는 실제 문서/정보가 부족하기 때문이며, 특히 최신 옵션에 대해 이야기할 때 그렇습니다. 저는 3.6.0 버전에서 더 이상 작동하지 않는 내용만 찾을 수 있고, 새로운 접근 방식은 찾기 어렵습니다. 또한 몇 가지를 찾더라도 세부 사항의 수준이 낮고, 실제 사용 예시나 기능을 어떻게 사용하는지에 대한 더 자세한 설명이 없습니다.
그럼에도 불구하고, 저는 second-factor-add-totp.gjs 컴포넌트를 수정해야 하는데, 제 커스텀 테마에서 이것이 적절하게 수행될 수 있는 방법에 대한 정보가 없어서 어떻게 해야 할지 모르겠습니다. PluginOutlet이라는 것이 있으며, 이는 훅(hook)으로 작동하도록 설계되어 사용자 정의 코드를 주입하거나 PluginOutlet으로 감싸진 요소의 출력을 수정할 수 있다고 들었습니다(확신은 없지만, api.renderInOutlet과 같은 것이 있는 것 같지만, 이를 사용하는 방법에 대한 일반적인 정보를 찾지 못했습니다). 이러한 Ember 컴포넌트를 살펴봐도, 최소한 순수 JS를 사용하여 구조를 조작하는 데 도움이 될 수 있는 PluginOutlet을 찾을 수 없습니다.
이것이 거기서 추가할 수 있는 것인지, 그리고 모달 창 구조를 수정하거나 최소한 순수 JS를 사용하여 일부 요소를 다른 위치로 이동하는 데 사용할 수 있는지 설명해 주실 수 있을까요?
또한 제가 찾지 못했을 수도 있지만, 새로운 접근 방식에 대한 예시가 포함된 문서가 있을까요?
물론입니다.
제가 가지고 있는 “수정된” 버전 기준으로, MFA 모달(사용자가 MFA를 위해 인증 앱 설정을 해야 할 때)의 디자인을 약간 업데이트해야 합니다.
여기서 '업데이트’란 예를 들어 HTML 구조 내에서 QR 코드의 위치를 이동하는 것을 의미합니다. 좀 더 구체적으로 말하면, “js.user.second_factor.enable_description” 사이트 텍스트 부분에서, QR 코드는 제공된 새 텍스트(HTML 마크업) 사이에 어딘가에 배치되어야 합니다.
또 다른 예로는 “수동 입력” 대신, 클릭 시 복사할 수 있는 실제 코드가 표시되도록 하는 것입니다(클릭 시 JS를 통해 수동으로 클릭을 트리거하여 표시되고, 단순히 위치를 이동시키는 방식).
이 모든 것은 원래 컴포넌트의 실제 구조 재구축 없이 일반적인 JS 조작으로 달성할 수 있지만, 제게 주된 과제는 모달이 열릴 때 실행되도록 이 JS를 어디에 배치해야 하는지 알아내는 것입니다. 아직 방법을 찾지 못했습니다.
@david 님, 안녕하세요. 튜토리얼 링크를 공유해 주셔서 감사합니다. 하지만 이미 해당 내용을 확인해 보았으며, 제가 찾고 있던 답변은 찾을 수 없었습니다. 예시 자체도 기초적인 수준에 머물러 있고, 예를 들어 특정 카테고리를 가져오는 방법(ajax 호출 대신)이나 코드 전체에서 Discourse API를 사용하는 방법(https://docs.discourse.org/에 언급된 내용)은 다루고 있지 않습니다. 제가 알고 있는 바로는 해당 문서에 해당 내용이 존재하는 것으로 보이는데, 그래서 일상적으로 Discourse를 다루는 분들과 문서에 없는 다양한 지식을 가진 분들에게 더 자세한 정보를 얻기 위해 이곳에 글을 남겼습니다.
순수 JS 사용이 문제를 일으킬 수 있다는 점은 충분히 이해합니다. 하지만 현재로서는 제가 떠올릴 수 있는 유일한 방법입니다. 미래에 더 적절한 방식으로 수정할 수 있는 기회가 있다면 그렇게 할 수 있겠죠.
즉, 제가 이해한 바로는 제가 현재 사용 중인 Discourse 버전(3.6.0.beta2-latest)에서는 제가 언급한 변경 사항들을 Discourse 내장 도구로 수행할 수 없는 것이 맞나요? 해당 컴포넌트에 PluginOutlets이 없어서 그런 것인가요?
DEV 팀이 향후 릴리스에서 해당 컴포넌트에 PluginOutlets을 추가하는 것을 고려하고 있을까요? 기술적인 문제는 없으며, 해당 프로젝트를 담당하는 몇몇 사람들의 결정 사항이라고 생각하기 때문입니다.
@david, 제안해 주셔서 감사합니다. 실제로 작업을 할 수 있는 시간이 있을 때 검토해 보겠습니다. 하지만 Discourse를 막 시작한 사람으로서, 이 작업에는 시간이 좀 걸릴 수 있다는 점을 이해해 주셔야 합니다. 제가 어떻게 하면 필요한 변경 사항을 제대로 준비할 수 있는지 정리해야 하고, 말씀하신 대로 승인 단계와 다음 릴리스에 포함되기까지의 시간도 고려해야 하기 때문입니다.
DEV 팀은 훨씬 더 자격이 있으므로, 단순히 PluginOutlet 래퍼를 추가하고 컴포넌트 내부의 여러 위치에 소소한 수정을 하는 것이라면(제가 틀렸을 수도 있지만) 1시간 안에 준비할 수 있을 거라고 기대했습니다. 이렇게 하면 새로운 릴리스에 이 기능이 반영되기까지 걸리는 시간을 줄일 수 있을 것입니다.
그래도 위에서 말씀드린 대로, 당신의 제안을 검토해 보겠습니다.
아직도 제 질문에 대한 답변을 받지 못했습니다. 제가 언급한 작업들을 현재 버전의 Discourse에서 수행할 수 있는지, 아니면 제가 언급한 변경 사항(해당 컴포넌트에 PluginOutlet 추가)을 먼저 추가/기여해야 하는지 여부입니다.
이렇게 묻는 이유는 제가 수행해야 할 업무 범위가 있는데, 이를 수행할 수 없고, 왜 수행할 수 없는지에 대한 설명을 팀에게 제공해야 하기 때문입니다. 따라서 업무 범위를 우리가 할 수 있는 일로 변경하거나, 코어에 추가되어 다가오는 릴리스에 포함되기를 바라며 이 부분에 기여해야 합니다. 그러므로 이것이 가능한지 아닌지에 대해 Discourse DEV 팀의 확인이 필요합니다.
저는 Discourse를 Docker로 설정하여 사용하고 있습니다. 브랜치에 대해 좋은 제안을 주셨는데, 맞습니다. PR이 머지되는 동안 변경할 수 있으므로 실제 릴리스를 기다리지 않아도 될 것 같습니다.
app.yml을 살펴보니 tests-passed 버전(브랜치)을 사용하고 있는 것을 확인할 수 있습니다. GIT를 살펴본 결과 안정성 측면에서 가장 좋은 선택지는 아닌 것 같습니다. main을 사용하는 것이 더 권장되나요, 아니면 latest 태그로 전환해야 하나요? Docker 설정에서 태그로 전환하는 것이 가능한가요?