 |
요약 | 컴포저의 텍스트 영역을 클릭하면 미리보기 창에서 해당 줄이 선택되고, 그 반대도 마찬가지입니다. |
 |
저장소 링크 | https://github.com/thijsbrilleman/discourse-click-to-edit |
 |
설치 가이드 | Discourse에서 플러그인 설치하는 방법 |
기능
컴포저의 텍스트 영역을 클릭하면 미리보기 창에서 해당 줄이 선택되고, 그 반대도 마찬가지입니다.
28개의 좋아요
PR로 환영받을 것 같은데, 나는 거기에 대해 결정할 권한이 없어요.
6개의 좋아요
안녕하세요 
감사합니다, 정말 멋진 것 같아요 
테마 컴포넌트로 만들면 정말 좋을 것 같아요. 
7개의 좋아요
감사합니다. 저도 동의합니다. 시간이 나면 바로 살펴보겠습니다. 언제든 풀 리퀘스트를 제출해 주셔도 좋습니다.
현재 이는 의도된 동작이지만, 물론 더 나은 아이디어에 대해서는 열려 있습니다. 어떤 시각적 큐(시그널)를 추천하시나요?
2개의 좋아요
무언가가 실제로 선택된 상태일 때 붙여넣기된 텍스트로 표시되어야 합니다. 그러면 동작과 응답이 생길 것입니다.
궁금한 건, 왜 이게 플러그인이고 테마 컴포넌트가 아니에요? 이 토큰들은 전부 클라이언트 사이드에서 생성할 수 있는 거 아닌가요?
참고로, 정말 잘하셨어요. 마크다운 엔진이 주입하는 줄 번호를 활용하신 점이 마음에 듭니다.
4개의 좋아요
Sam, 감사합니다.
알고 계셨을지 모르겠지만, data-ln 속성은 서버에서 생성 및 저장되는 cooked html에도 존재합니다.
이 동작을 구현한 이유는 나중에 플러그인을 확장하여 토픽 뷰 페이지에서 조각(fragments)을 신뢰할 수 있게 삽입/편집할 수 있도록 하기 위함입니다. 이는 아래에 표시된 편집 버튼과 유사하지만, 조금 더 견고한 방식입니다:
이 코드를 작성한 지 1년이 지났지만, 기억이 정확하다면, 그 목적을 위해 plugin.rb에서 아래 줄이 필요합니다:
register_asset "vendor/javascripts/markdown-it-line-numbers.js", :vendored_pretty_text
이것은 html을 cook할 때 MarkdownIt 확장 기능이 서버 측에서도 실행되도록 보장하기 위함입니다.
다만, 확장된 편집 기능을 구현하는 데 필요한 시간을 찾지 못했습니다. 따라서 해당 요구사항이 폐기된다면, 이 기능을 컴포넌트로 변환할 수 있을 것 같습니다.
5개의 좋아요
@sam 이걸 테마 컴포넌트로 변환하는 방법을 알아보고 있는데, markdownit 플러그인 컨텍스트에서 이 코드를 실행하는 방법을 도저히 모르겠어요:
// javascripts/lib/discourse-markdown/initialize_markdownit_plugin.js:
export function setup(helper) {
helper.registerPlugin(markdownitLineNumbers); // markdownitLineNumbers is already available
}
전에 제가 작성한 플러그인의 해당 줄이 클라이언트 사이드 마법 같은 것들도 함께 뿌리고 있는 것 같다는 의심이 듭니다:
# plugin.rb
register_asset "vendor/javascripts/markdown-it-line-numbers.js", :vendored_pretty_text`
혹시 아이디어가 있으신가요?
확실하지 않으니 팀에 연락해볼게요.
2개의 좋아요
이는 현재 플러그인 스코프에만 제한되어 있기 때문이라고 생각합니다. 해당 체크가 없으면 정상적으로 동작할 것입니다. (이 코드는 이 커밋에서 도입되었습니다.)
다른 컴포넌트에 줄 번호를 통합하고 싶었지만, 플러그인을 만들고 싶지 않아서 결국 포기했습니다. 테마 컴포넌트에서 마크다운 기능이 지원될 수 있다면 정말 멋질 것 같습니다!
부연하자면, 여기서 제안하신 멋진 기능입니다 – 정말 좋습니다. 
4개의 좋아요
아, 그렇군요. 이제 이해가 됩니다.
이 코드를 보면 런타임에 테마 컴포넌트에서 마크다운 플러그인을 수동으로 주입할 수 있을 것 같습니다. 하지만 이렇게 하면 꽤 해킹적인 방식이 될 것입니다. 구현을 시도하기 전에核心团队의 결정을 기다리겠습니다.
4개의 좋아요
저희 마크다운 파이프라인은 클라이언트(미리보기용)와 서버(게시글의 HTML을 미리 렌더링하기 위해) 양쪽 모두에서 실행됩니다. 그래서 플러그인 전용으로 설계된 것입니다. 서버 측에 코드를 주입할 수 있는 것은 플러그인뿐이기 때문입니다.
자… 이 경우는 다소 특이한데요, 해당 확장 기능은 서버가 아닌 작성기(composer)에서만 필요하기 때문입니다. 따라서 테마 컴포넌트에서 처리하는 것이 가능할 것입니다.
이 부분에 대해 특정 전략을 생각하고 계셨나요?
5개의 좋아요
이것은 많은 사람들에게 큰 관심을 끌 것 같습니다. 긴 게시물에서 자신의 위치를 찾기란 쉽지 않죠. pr-welcome 태그가 적합할까요?
5개의 좋아요
원본 코드베이스에서 이 함수를 오버라이드하세요:
// discourse/app/assets/javascripts/discourse/app/components/d-editor.js
async cachedCookAsync(text, options) {
this._cachedCookFunction ||= await generateCookFunction(options || {});
return await this._cachedCookFunction(text);
}
테마 컴포넌트 초기화기로 다음과 같이 대체할 수 있습니다:
export default {
name: "d-editor-cached-cook-async-override",
initialize() {
const dEditor = require("discourse/components/d-editor").default;
dEditor.reopen({
cachedCookAsync(text, options) {
// 수정된 cook 함수를 반환하기 위해 코드를 여기에서 중복 구현
},
});
},
};
설령 작동하더라도 상당한 코드 중복이 발생하게 됩니다. 더럽고 더러운 방법입니다.
4개의 좋아요
음, 맞아요. 확실히 이상적이지 않네요. 코드를 중복하는 것이 가능하지도 않을 수 있어요. markdown-it 모듈들이 비동기적으로 로드되고, 테마/플러그인이 직접 접근할 수 있는 amd 모듈 시스템의 일부가 아니기 때문이죠. 
테마가 클라이언트 사이드 전용 md 변환을 기여할 수 있는 시스템을 구축하는 것도 재미있을 수 있지만, 사용 사례는 상당히 제한적입니다. 99%의 경우에서 사람들은 md 변환이 서버 사이드에서도 적용되기를 원하니까요.
그래서 지금은 플러그인을 사용하는 것이 가장 좋은 접근 방식이라고 생각합니다.
5개의 좋아요
이런 장식은 무조건 적용해야 하는 게 아닐까 궁금합니다.
예를 들면:
<p data-source-line="0">.....</p>
추가된 data 속성은 내부 구현에 많은 도움이 됩니다. 예를 들어 코드 블록 안에 있을 때 자동완성을 표시하지 않는 기능 같은 경우요. 또한 인용과 빠른 편집도 훨씬 쉬워집니다.
이 단순한 구현은 거의 추가 부담이 없으면서도 대량의 소스 코드를 제거할 수 있게 해 줍니다.
7개의 좋아요
과거에 이 기능이 플래그 뒤에 존재했지만, 이 커밋에서 제거되었습니다. 해당 기능에 대한 내부 논의 중 한 스샷을 찾았습니다:
즉, 성능 문제는 라인 번호 주입이 아니라 스크롤 동기화 코드 때문이었습니다 
네, 미리보기(Preview)에서만 추가된다면 코어에 data-source-line 주입을 추가하는 데 반대하지 않습니다. @pipkin 님, 이 부분으로 PR을 만들어 보실 의향이 있으신가요?
4개의 좋아요
반갑게도! 여러분께 무언가 돌려드릴 수 있어 기쁩니다.
6개의 좋아요
전적으로 동의합니다 
작년에 비슷한 기능 요청을 제출한 적이 있습니다…
2개의 좋아요