WYSIWYGエディタ選定の遠回り体験記
こんにちは！株式会社コミュニティオのしまだい（@cimadai）です。
WYSIWYGエディタの選定、悩んだ経験ありませんか？
私たちコミュニティオでも、 CKEditor4 → Quill → Tiptap という、ちょっとした遠回りを経験しました。
最終的に Tiptap で大成功だったのですが、ここに至るまでには
「なぜ最初の選択がダメだったのか」「なぜ Tiptap が正解だったのか」 という多くの学びがありました。
この記事では、その試行錯誤の全体像をまとめて紹介します。
プロジェクトの背景
コミュニティオには、VueとReactそれぞれを採用している2つのメインプロジェクトがあります。
それぞれのプロジェクトで、2022年9月頃からMicrosoft Teams上で従業員に一斉にメッセージ(AdaptiveCard)を配信する機能を提供しており、ユーザー自身が 画面上でメッセージを作成できるようになっていました。
ただ、AdaptiveCardはその制約が多く、正しいフォーマットで安全に送ることができるように制限せざるを得ない事情があり、当初は決まった項目に値を流し込むだけのフォームでユーザーの自由度はかなり低い状態でした。
しかしユーザーから「もっと自由に、見たまま(WYSIWYG)で作成したい」という声も増えてきたため、 Vue/React のどちらでも使える共通エディタを探すプロジェクトが 2023 年 3 月に始まりました。
CKEditor4の採用
選定基準
当時はVue/Reactの片方専用であれば魅力的な選択肢はいくつもあったのですが、両方をカバーできるエディタとなると候補が少ない状況でした。
- Vue/React 両対応
- 採用実績が豊富
- 情報が多く、安心して使えそう
こうした中で、これらの条件を満たしていたのが CKEditor4 でした。
実装とカスタマイズ
Vue と React のそれぞれに CKEditor4 を組み込み、必要最低限のカスタマイズを行い、
ユーザーがGUI上で自由に AdaptiveCard のコンテンツを WYSIWYG で作れる機能を提供し始めることができました。
初期の価値提供としては十分で、実際これでしばらくは問題なく運用できていました。
問題点の顕在化
しかし、使い込んでいくうちに、いくつかの問題が見えてきました。
- UIやロジックのカスタマイズの柔軟性が低い
- エディタのUI/UXの古臭さ
- ちょっとした追加拡張でも対応工数が大きくなる
- そして極めつけは、CKEditor4のEOL
特にEOLは致命的でした。
長期的にメンテナンスしていくプロダクトとして、サポートが終了するエディタを使い続けるリスクを許容できません。
乗り換えを避けられない状態になりました。
乗り換え先の検討とQuill選定
候補の洗い出し
乗り換え先を探しているときに候補に上がったのが、以下のエディタでした。
- Quill
- Draft.js
- Tiptap
この中から、当時のnpmトレンドやドキュメントの量などから、最も現実的に見えたQuillを選択しました。とても人気があり、情報も豊富で、良さそうに見えたのです。
Quillでの苦労
とはいえ、Quillで開発を始めると、次から次へと問題にぶつかりました。
- 独自拡張には blot の理解が必須だが、blotに関するドキュメントが少ない
- AdaptiveCardに必要な独自ブロックのパターンが多く、実装が複雑になる
- 時期的にQuill v1とv2が混在しており、情報が錯綜している
- ツールバーのUIとロジックが密結合されていてカスタマイズしづらい
- ドキュメント通りにやっても期待した結果が得られないことがしばしば
「一つ一つの機能の単体レベルではいいけど、プロダクトレベルにしようとすると途端に苦しくなる」 という状況でした。気づけば進捗がでないまま数ヶ月が経ってしまいました。
Vue3リプレースの優先
ちょうど同じ頃、別プロジェクトでVue2からVue3へのリプレースが進んでいました。
「このままエディタで時間を浪費するよりもまずはVue3リプレースを優先しよう」という判断をし、エディタ移行は一時凍結してVue3移行にリソースを投下しました。
結果的にいえば、この判断は大正解でした。
Vue3のコードベースになったことで見通しが良くなり、Storybookの導入やテストコードの整備も進み、後の「新しいエディタを受け入れやすい基盤」が出来上がったのだと思います。
Tiptapとの出会い
試しに触ってみた
Storybookが整備されたことで色々と試しやすい環境ができていたため、気軽な気持ちでTiptapを試してみることにしました。
すると...
「あれ？なんか...めっちゃ素直に動くぞ！」
Quill で数カ月悩んでいた部分が、Tiptap だとスッと実装できる。
その「手馴染みの良さ」に衝撃を受けました。
シンプルなモジュール設計と、拡張性の高さが、我々の要件に非常にマッチしていたのです。
スムーズな移植
別のタスクと平行しながら進めても、以下のように非常にスムーズに移行が進みました。
- 3スプリント（3週）かからずにCKEditor4からTiptapへの移行が完了
- React側もnpm package化したコア機能を流用し、1スプリント以内でリプレース完了
Quillでの苦労が嘘のようでした。
なぜTiptapがやりやすいのか
- 独自コンポーネントをExtensionとして簡単に追加できる
- Headless設計でロジックとUI/UXの分離が容易
- フレームワーク層が薄く、Vue/React両対応が容易
- TypeScriptで書かれており、型が強力で開発体験が良い
こうした特徴のおかげで「触りたい場所をちゃんと触れる」「素直に実装できる」という体験が得られました。
得られた成果
二重メンテからの解放
Vue用とReact用で別々のエディタ実装をメンテナンスする必要がなくなり、二重メンテの地獄から解放されました。
コア機能を共通化することで、以下のメリットも得られました。
- 機能追加が一度で済む
- バグ修正も一箇所で済む
- テストコードも共通化できる
開発体験の向上
Tiptapは開発者体験（DX）が非常に良く、以下の点で優れていました。
- TypeScriptのサポートが充実
- 拡張性の高い設計
- ドキュメントが分かりやすい
- コミュニティが活発
なぜTiptapが「正解」だったのか
振り返ってみると、Tiptapが正解だった理由は以下の点にあると考えています。
1. モダンな設計思想
ProseMirrorをベースにした設計で、エディタのコア機能とフレームワーク層が明確に分離されています。
この構造のおかげで、マルチフレームワーク対応がしやすくなっていました。
2. 拡張性の高さ
Extensionベースの設計により、必要な機能だけを組み込むことができます。
カスタマイズも直感的で、UI/UXも既存のフレームワークとの親和性を高く保つことができ、Quillで苦労していたことが嘘のように簡単でした。
3. TypeScriptファースト
型定義がしっかりしており、開発時の補完やエラー検出が優れています。これにより、開発効率が大きく向上しました。
4. 活発なコミュニティ
GitHubでの活動も活発で、issueへの対応も早く、長期的にメンテナンスされていく安心感があります。
学びと反省
ダウンロード数や人気だけで選ばない
Quillを選んだ当時の判断基準は「ダウンロードトレンド」や「ドキュメントの量」でした。
しかし、これらは必ずしも「使いやすさ」や「カスタマイズのしやすさ」を保証するものではありません。
みんなが使っているから・ドキュメントが多いからといって飛びついてしまったのはしくじりでした。
実際に触って試すことの重要性
結果的に、Tiptapは「試しに触ってみた」ことで惚れ込みました。
最初からもっと多くの選択肢を実際に触って比較していれば、遠回りせずに済んだかもしれません。
今であればコーディングエージェントを使えば楽に複数パターンの試行ができるので、とにかく使ってみて比較することをおすすめします。
弊社の場合ではStorybookでプロトタイプを作成して比較しました。
ライブラリの設計思想を理解する
Tiptapの設計が優れていたのは、ProseMirrorという安定した基盤の上に、フレームワーク層を薄く載せるという思想があったからです。
Vue/Reactで共通して使おうと思った場合には、Headless設計であることが非常に強力なポイントになります。
ライブラリ選定時は、こうした設計思想まで理解することが重要だと学びました。
まとめ
CKEditor4 → Quill → Tiptapという遠回りを経験しましたが、そのおかげで「なぜ Tiptap が正解だったか」という理解につながりました。
急がば回れ、とはよく言ったものですが、いまエディタ選定で悩んでいる方は、ぜひ実際に小さく触って比較してみてください。
この記事が同じような課題を抱えている方の参考になれば幸いです。
Discussion