2 ポイント 投稿者 GN⁺ 2024-04-20 | 1件のコメント | WhatsAppで共有
  • Quill 2.0は、現代のWebで使える無料のオープンソースWYSIWYGエディタで、リッチテキスト編集機能を製品に直接組み込める
  • モジュール型アーキテクチャと表現力豊かなAPIを基盤に、基本コアから始めて要件に合わせてエディタをカスタマイズできる
  • 開発者はエディタのコンテンツ、変更、イベントに細かくアクセスでき、入出力にJSONを使うことで一貫した動作を期待できる
  • デスクトップ、タブレット、スマートフォンの最新ブラウザをサポートし、プラットフォーム全体で同じ動作と生成HTMLを提供することを目標としている
  • 小規模プロジェクトからFortune 500企業まで適用範囲を広げられるため、シンプルなエディタを導入した後、製品の成長に合わせて拡張しやすい

Quill 2.0と始め方

  • Quill 2.0がリリースされており、別途公開された発表記事でリリース内容を確認できる: Quill 2.0 is released!
  • Quillは現代のWeb向けに作られた無料のオープンソースWYSIWYGエディタ
  • 基本例では、CDNからquill.snow.cssquill.jsを読み込んだ後、new Quill('#editor', ...)でエディタを生成する
    • 例のバージョンはquill@2.0.3
    • modules.toolbar#toolbarを指定し、themeにはsnowを使用する
  • ブラウザの開発者コンソールでAPIを直接試せる

カスタマイズと適用範囲

  • Quillはモジュール型アーキテクチャとAPIを通じて、要件に合わせてエディタを調整できる
  • 開発者はシンプルなAPIでエディタのコンテンツ、変更、イベントに細かくアクセスできる
  • 入力と出力の両方でJSONを使い、一貫性があり決定的な動作を提供する
  • デスクトップ、タブレット、スマートフォンの最新ブラウザをサポートし、プラットフォーム間で同一の動作と生成HTMLを提供する
  • 小規模プロジェクトとFortune 500企業のどちらでも利用でき、Quill coreから始めて必要に応じてカスタマイズしたり拡張を追加したりできる
  • GitHub Star数は47,204と表示されている

1件のコメント

 
GN⁺ 2024-04-20
Hacker News の意見
  • 以前の職場で、ユーザーが Quill のテキストボックスにリッチテキストを入力し、それをデータベースに Delta 形式で保存するシステムを作ったことがある。
    後で別チームのメンバーがその内容を InDesign プラグインに取り込み、Quill で適用された書式を読み取って InDesign 側のスタイルとして再適用していた。
    新聞の法定公告をフロントスタッフが入力し、制作チームが InDesign で印刷用の作業に回す流れだった。多くのエディタのように HTML を保存していたらずっと難しかったはずの作業を、Quill Delta 形式が大幅に簡単にしてくれた。
    ここ数年 Quill を聞いたり使ったりしていなかったが、まだ生きていてうれしい。

  • リリースノート: https://github.com/quilljs/quill/releases/tag/v2.0.0
    発表記事: https://slab.com/blog/announcing-quill-2-0/
    Quill はかなり使ってきたが、統合しやすく、JSON Delta 形式もかなり良く、構造も比較的シンプル。
    ただ使うたびに「素直に ProseMirror を使うべきなのでは?」と思ってしまう。
    すばやく編集機能が必要なとき、Quill は良い暫定解だが、その機能への要求が大きくなると、いずれ 移行計画が必要になるだろうと頭の中で計算し続けることになる。

    • 投稿リンクを [1] に変えられるとよさそう。実際には新バージョンについての内容だから。
      一方で、なぜ リッチテキストエディタを標準化できないのか、ときどき不思議に思う。
      [1] https://slab.com/blog/announcing-quill-2-0/
    • ProseMirror を調べているところで、主にそれをうまくラップしているように見える tiptap2 経由で見ている。
      ただ、実際に移行するのは負担が大きく、ほかの人の経験が気になっている。
    • 職場でリッチテキスト編集を実装する必要があり、いくつかの選択肢を検討した。Quill も初期に見た候補の一つだったが、最終的に ProseMirror を選んだ。
      選んだ理由は非常に低レベルであることと、ドキュメントが膨大だったことで、少し D3 を思い起こさせる感じだった。
      その後、カスタムノード、カスタムコマンド、カスタムツールバーを作り、Markdown やカスタム Markdown プラグインと統合した。少しのグルーコードがあれば Vue ともかなりきれいにつながる。
      今のところ ProseMirror を選んだことにとても満足している。
  • テキストエディタで Return キーをどう扱うべきかについて、自分が強すぎる意見を持っているのが変なのかは分からない。
    プレーンテキストでは Return は改行で、リッチテキストでは Return は新しい段落であるべき。
    改行したいなら Shift+Return を使えばよい。
    以前のバージョンではこれが大きな問題で、今この挙動をどれだけカスタマイズできるのかは分からない。
    自分がこの問題を気にしすぎているのは認めるが、TipTap はしっくり来た。

    • 設定は簡単であるべきだが、その挙動がデフォルトであるべきだとは思わない。
      それほど一般的ではなく、特定のブロック種別で Return を押したときにだけ動作するものだから。
      Shift+Return はモバイルでは使えないし、望む挙動を得るために隠れたキー組み合わせを知っていなければならないのも厄介。
      Reddit のリッチエディタがこの方式なので、しょっちゅう格闘することになる。
      結局のところ、Return を 2 回押さなくて済むようにしているだけ。
      ユーザーを常に段落の中に保ち、Shift+Return で明示的に改行を選ばせるという整然さは理解できるが、リッチテキストエディタのような難しい領域では、整然さよりも ユーザー体験を優先したい。
    • 完全に同意。しかもその Shift+ のサポートすら不安定だが、そこはたぶん妥協できる。
      Quill の例における段落処理はぎこちなく見える。
    • 正しく読めているなら、Confluence/JIRA のテキスト入力欄の挙動に似ているように見える。
  • ドキュメントが素晴らしい。すべてのオープンソースプロジェクトに「Why Quill」[1] のようなページがあれば、そのプロジェクトの哲学や自分の目的に合っているかを素早く理解できてよいと思う。
    さらに良いのは、「Why Not Quill」のような内容もあって、どのような状況では合わないのかを素早く分かるようにすること。
    どのプロジェクトにもトレードオフはあるので、それを率直かつ明確に伝えれば、ユーザーはより良い体験を得られる。
    [1] https://quilljs.com/docs/why-quill

  • リンクを見ただけでは明確ではないが、おそらく 3 日前に v2 がリリースされたので投稿されたのだと思う。
    少し前まで Quill v1 を扱っていたが、かなり良くなかった。
    プラグインでテーブルを動かすのも苦痛だったし、妙なスクロール問題もあった。
    v2 で大きく改善されていることを願うが、機能面でより優れた TinyMCE を引き続き使うつもり。

    • TinyMCE も好きで、6か月前に Quill エディタを TinyMCE に置き換えた。
      ただ、サイトで静的 JS を使っているだけでも API キーが必要な点が腹立たしかったし、数日前に無料枠のエディタレンダリング「使用量」を急に減らしたのも不便だった [0]。
      それが問題にならないのか気になる。
      [0] https://news.ycombinator.com/item?id=40044544
  • 最初はなぜ Quill がまた上がってきたのか分からなかったが、長く待たれていた 2.0 バージョンが 3 日前にリリースされたのだと今分かった。
    https://slab.com/blog/announcing-quill-2-0/ を参照。

    • このリンクとタイトルをトピックに入れるほうが、より良い入口だと思う。
  • 以前手がけたプロジェクトで、Quillを使ったせいでかなり痛い目に遭ったことがあります
    個人的には、プロジェクトの要件に照らしてエディタの限界を十分に検討しなかったのが問題でしたが、ドキュメントがライブラリの拡張性を強調する書き方も、被害を招きかねないように見えました
    限界の範囲内にとどまるなら素晴らしいライブラリです。たとえば、ネストしたコンテンツのような複雑すぎるものは避けるべきです
    Webサイトに「Why You Should NOT Use Quill?」のようなセクションがあると、かなり役に立ちそうです

  • 場合によるとは思いますが、私はプロダクションプロジェクトでQuillを二度と使うつもりはありません
    2016年ごろにQuill 1.xを使い始め、最初はかなり気に入っていました
    Quillを検討中だとツイートしたとき、Jasonのほうから連絡をくれて、実装に関する質問にも手を貸してくれました
    2019年になるといくつかのバグに遭遇していて、Quill 1.xはメンテナンスモード、2.0は事実上ドキュメントがない状態でした [1]
    スケジュール感を知りたくてTwitterでJasonに連絡しましたが [2]、実質的には「失せろ」と言われたような返答でした
    彼の会社Slabも今では私をTwitterでブロックしていますが、もしかすると個人アカウントでブロックしようとしたものだったのかもしれません
    スタートアップを作っている最中なら誰にでもストレスの多い日はあるので、私が連絡したタイミングが悪かった可能性もあります
    私の推測では、彼は自社に集中していて、Quillを社内利用のためにかろうじて維持する時間はあっても、オープンソースとしてリリースする余裕はほとんどなかったのだと思います。そうなら、むしろ正直に言ってほしかったです
    5年後、Quill v2がついに出て、Slabがまだ存続しているのはうれしいことです
    今後Quillを公開の場で保守する余力があることを願いますが、プロダクションで使うつもりなら、サポートに対するコミットメントがどの程度あるのかを確認し、反応が途絶えた場合の計画も立てておくべきです
    Jasonがこのスレッドにいるなら、悪意はなく、もう過ぎたことです。無視してもいいですし、本人の見解を付け加えても構いません
    [1] https://github.com/quilljs/quill/issues/2435
    [2] https://twitter.com/nickbaum/status/1177240103925796865

    • Jasonに関する経験はありませんが、おかしな挙動を回避するパッチを書くためにQuillのコードを読むのに、あまりにも多くの時間を使いました
      自作ではなくリッチテキストエディタのライブラリを使う理由は、まさにそういうことを避けるためなので、余計にうんざりしました
      v2はわかりませんが、v1のコードは構造があまりよく整理されていません
      小さなバグが無数に発生するのが怖くて、実装を先延ばしにした基本機能もあります
      Quillで最も良い点は、間違いなくDelta形式です
      ただし、太字・下線・斜体以上のものを求める人にはProseMirrorを勧めます
  • 関連記事です。ほかにもありますか?
    Announcing Quill 1.0 - https://news.ycombinator.com/item?id=12437345 - 2016年9月、コメント82件
    Quill – A cross browser rich text editor with an API - https://news.ycombinator.com/item?id=10446865 - 2015年10月、コメント47件
    Quill – An Open Source Rich Text Editor with an API - https://news.ycombinator.com/item?id=7716376 - 2014年5月、コメント60件

    • 今回の発表は、数日前にリリースされたように見えるバージョン2に関するものです
  • 1年ほど前にプロジェクトでhttps://github.com/facebook/lexicalを使った記憶がありますが、ほとんどはすぐにうまく動きました
    Quillをより好む理由はあるのでしょうか?