 |
概要 | コンポーザーのテキストエリアをクリックすると、プレビューペインの対応する行が選択され、その逆も同様です。 |
 |
リポジトリリンク | \u003chttps://github.com/thijsbrilleman/discourse-click-to-edit\u003e |
 |
インストールガイド | Discourseにプラグインをインストールする方法 |
特徴
コンポーザーのテキストエリアをクリックすると、プレビューペインの対応する行が選択され、その逆も同様です。
「いいね！」 28
Discourse のコア編集機能への非常に良い追加です。作成していただきありがとうございます。
「いいね！」 5
それは歓迎されるべきことのように思えますが、私には何も言う権利がありません。
「いいね！」 6
こんにちは 
ありがとうございます、これは本当にクールですね 
テーマコンポーネントにできたら最高だと思います。
「いいね！」 7
ありがとうございます。私もそう思います。時間がある限り、検討します。プルリクエストを提出していただくこともいつでも歓迎します。
これは現在の意図した動作ですが、もちろんより良いアイデアがあれば検討します。どのような視覚的な手がかりをお勧めしますか？
「いいね！」 2
選択されたものが実際には選択されていないのに、貼り付けられたテキストとして表示されることがあります。その後、アクションと応答が発生します。
不思議なのですが、これはテーマコンポーネントではなくプラグインなのですか？ トークンはすべてクライアントサイドで生成できるのではないでしょうか？
ところで、素晴らしい出来栄えです。マークダウンエンジンによって挿入される行番号を活用している点が気に入っています。
「いいね！」 4
サムさん、ありがとうございます。
お気づきかもしれませんが、data-ln 属性は、サーバーで生成および保存される調理済み HTML にも存在します。
これは、後でプラグインを拡張して、トピック表示ページからフラグメントの信頼性の高い挿入/編集を可能にするために実装しました。これは、以下に示す編集ボタンに相当しますが、もう少し堅牢です。
1 年前に書いたものですが、記憶が正しければ、そのために plugin.rb の次の行が必要です。
register_asset "vendor/javascripts/markdown-it-line-numbers.js", :vendored_pretty_text
これは、HTML を調理する際に MarkdownIt 拡張機能がサーバー側でも実行されることを保証するために必要です。
ただし、拡張編集機能を実装する時間がありませんでした。そのため、その要件が削除された場合は、コンポーネントに変換できると思います。
「いいね！」 5
@sam それをテーマコンポーネントに変換しようとしていますが、markdownit プラグインのコンテキストでこのコードを実行する方法がわかりません。
// javascripts/lib/discourse-markdown/initialize_markdownit_plugin.js:
export function setup(helper) {
helper.registerPlugin(markdownitLineNumbers); // markdownitLineNumbers はすでに利用可能です
}
以前に書いたプラグインの行が、クライアントサイドのマジックも散りばめているのではないかと疑っています。
# plugin.rb
register_asset "vendor/javascripts/markdown-it-line-numbers.js", :vendored_pretty_text
何か心当たりはありますか？
わかりません。チームに連絡します。
「いいね！」 2
これは、現在プラグインスコープのみに制限されているためだと思います。このチェックがなければ機能するはずです。(このコードは、このコミットで導入されました)
別のコンポーネントのために行番号を統合したかったのですが、プラグインにしたくなかったので諦めました。マークダウン機能がテーマコンポーネントでサポートされるようになると、非常に素晴らしいと思います！
ちなみに、ここで提案された素晴らしい機能ですね。とても良いです。
「いいね！」 4
ああ、これで明確になりました。
このコードを見ると、実行時にテーマコンポーネントからマークダウンプラグインを手動で注入できるかもしれませんが、これはかなりハッキーな方法になります。実装を試みる前に、コアチームからの評決を待ちます。
「いいね！」 4
プレビュー用にはクライアント、投稿のHTMLを事前レンダリングするためにサーバーの両方でマークダウンパイプラインを実行しています。そのため、プラグインのみを対象として設計されています。サーバーサイドでコードを挿入できるのはプラグインだけです。
今回のケースは、拡張機能がサーバーではなくコンポーザーでのみ必要とされるため、非常に珍しいです。そのため、テーマコンポーネントから行うことは可能でしょう。
何か特別な戦略を考えていましたか？
「いいね！」 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 変換を提供できるシステムを構築することはクールかもしれませんが、ユースケースはかなり限られています。ほとんどの場合、人々は md 変換がサーバーサイドでも適用されることを望んでいます。
そのため、現時点ではプラグインにとどまるのが最善のアプローチだと思われます。
「いいね！」 5
それなら、この種の装飾は適用されるべきでしょうか？
例：
<p data-source-line="0">.....</p>
追加のdata属性は、コードブロック内にいる場合にオートコンプリートを表示しない、引用やクイック編集を容易にするなど、多くの内部実装に役立ちます。
些細な実装はほとんど追加の負荷をかけませんが、ソースコードの山を削除することを可能にします。
「いいね！」 7
過去にも（フラグの後ろで）ありましたが、このコミットで削除されました。その機能に関する内部議論で見つけたスクリーンショットがあります。
つまり、パフォーマンスの問題は行番号の挿入ではなく、スクロール同期のコードにあったということです 
ですから、プレビューでのみ追加される限り、データソース行の挿入をコアに追加することに反対はありません。@pipkin さん、PRを作成していただけますか？
「いいね！」 4
喜んで！皆さんに何かお返しができることを嬉しく思います。
「いいね！」 6