2023-04-28_Muddy_Web.pdf

Transcript

1. あああ 1 アメブロにおける WYSIWYGエディタ開発
2. 自己紹介 2 柳　耕太（やなぎ　こうた） / パグ Twitter: @pagu0602 • 2017年入社、Ameba7年目 • Webフロントエンドエンジニア • アメブロの運用開発 ◦ Ameba Pick(アフィリエイト機能)の立ち上げ ◦ WYSIWYGエディタ開発 ◦ アメブロにおけるSPブラウザ向けのエディタ開発
3. 現状の説明 3
4. 4 1. アメブロとエディタについて 2. 現状の課題感 3. 改善プロジェクトの立ち上げ
5. 5 アメブロとエディタについて
6. 6 アメブロについて アメブロは今年で19周年を迎え る誰でも簡単にブログを書くこ とが出来るサービスです。 記事数は25億記事以上存在し、 日々様々な記事が投稿されてい ます。
7. 7 アメブロを書くために用いるエディタについて Web - PC Web - SP iOS Android
8. 8 アメブロのエディタについて - 設計 PC SP Android iOS ユーザーインターフェース ユーザーインターフェース ユーザーインターフェース ユーザーインターフェース エディタ機能 エディタ機能 エディタ機能 エディタ機能
9. 9 現状の課題感
10. 10 現状の課題感 - PCのエディタ設計 • ライブラリとしてCKEditor 4を利用している • コアのコードを書き換えており、アップデートが難しい ◦ サポートが今年で切れてしまう →メンテナビリティに不安を抱えた状態
11. 11 現状の課題感 - 開発コストが高い PC Android iOS 機能 実装 実装 実装 リリース 各プラットフォームの実装が完了次第 SP 実装 →機能を各プラットフォームで実装する必要がある →機能落ち、もしくは待ちが発生する
12. 12 現状の課題感 - 属人性が高い • あまり使われないAPIや機能についての理解が求められるケースがある • 機能同士の相性が悪いことがあるが、それを考慮出来る範囲が人によって違う ◦ 範囲選択をしてセンタリングをした場合にこの要素には適用しない等 →エディタに関わる案件をアサイン出来るメンバーが限られている
13. 13 現状の課題感 - デグレの検知が困難 • エディタの操作を自動的にテストする環境がない ◦ テスト項目書から漏れるケースがある • 特定のデバイス・ブラウザ・OSで発生するバグ等も存在 →テスト項目書が膨大になりがちで、完璧に網羅するのも難しい →ユーザーのお問い合わせで発覚するケースも有る
14. 14 改善プロジェクトの立ち上げ
15. 15 改善プロジェクトの立ち上げ 『各プラットフォームで使える共通のエディタを開発し 堅牢なテストで動作を担保できている状態』 プロジェクトのゴール
16. 16 改善プロジェクトの立ち上げ - 評価方法 • デバッグ工数の削減量 • 実装工数の削減量とリードタイム短縮 • メンテナーの数とオンボーディング時間改善 →これらを概算で出して承認を得た上で評価にも用いることに。
17. WYSIWYGエディタ開発について 17
18. 自己紹介 18 捧　貴史（ささげ　たかふみ） Twitter: @sasaplus1 • 2017年中途入社 • Webフロントエンドエンジニア • アメブロの運用開発 ◦ ビルド環境やCIの整備 ◦ WYSIWYGエディタの開発
19. 19 1. エディタの設計について 2. 指標はどれくらい改善されたか 3. 持続可能なエディタ保守に向けて
20. 20 エディタの設計について
21. 21 エディタを設計する前に • アメブロ固有の前提条件や制約、悩んだこと ◦ contenteditable属性の使用が必須 ◦ document.execCommandを使用しない ◦ エディタライブラリを使用するかどうか
22. 22 contenteditable属性とは • HTMLの要素に付加できるグローバル属性 • 要素の内容をユーザーが編集できるようになる https://developer.mozilla.org/ja/docs/Web/HTML/Global_attributes/contenteditable
23. 23 contenteditable属性の使用が必須 • なぜ属性を使用する必要があるのか？ ◦ 既存の機能の1つがcontenteditable属性の要素の中で　　 使用されることを前提とした実装をしているため → この属性を使用していないエディタライブラリを使用すると 　 機能が壊れる可能性がある
24. 24 document.execCommandとは • 編集可能領域に対して様々な変更を加えることができる ◦ 文字の装飾（太字、斜体、色、等々） ◦ Undo/Redo ◦ コピー & ペースト ◦ 等々
25. 25 document.execCommandを使用しない https://developer.mozilla.org/ja/docs/Web/API/Document/execCommand • 非推奨となっており、いつ機能が削除されるかわからない • ブラウザによって対応もまちまち → 自前で実装する方針に
26. 26 エディタライブラリを使用するかどうか • これまでの条件に合うライブラリが存在するか調査した ◦ GitHubで"editor"を検索した ◦ 条件に合うものはいくつか存在したものの最終更新が数年 前のものなどが多数 • Lexicalの登場でDraft.jsがメンテナンスモードとなるなど 外部要因に振り回されたくないという気持ちもあった https://lexical.dev/ https://draftjs.org/ → ライブラリを使用しない方向で作ることに
27. 27 自前でエディタを設計・実装する • メリット ◦ 自前で実装するので機能を柔軟に変更できる ▪ 特にa11yに関する挙動への要望は多くなるのではないかと予想した ◦ 外部要因に振り回されない • デメリット ◦ RangeやSelectionなどの利用機会の少ないAPIの理解が必要 ◦ contenteditableの挙動の理解が必要でとにかく大変 https://developer.mozilla.org/ja/docs/Web/API/Selection https://developer.mozilla.org/ja/docs/Web/API/range
28. 28 エディタを設計するにあたって • 目指したいこと ◦ 機能の追加が容易であること ◦ 保守に苦労しないこと ▪ コードベースが大きくなりすぎないこと ▪ ソースコードを読むときに当たりを付けられること
29. 29 機能の追加が容易・コードベースの肥大化に対して • 現状のエディタの機能を単純に再実装していくと確実に コードベースが大きくなっていくはず → 機能をプラグインとして単体のnpmモジュールとする → プラグインの管理や連携を担うコアモジュールを作る
30. 30 構成図 コア packages/core プラグイン Undo&Redoプラグイン packages/plugin-undo-and-redo 文字装飾プラグイン packages/plugin-decorator プラグイン 各種プラグイン packages/plugin-xxx
31. 31 コアとプラグインの連携 コア packages/core プラグイン Undo&Redoプラグイン packages/plugin-undo-and-redo 文字装飾プラグイン packages/plugin-decorator プラグイン 各種プラグイン packages/plugin-xxx contenteditable要素 イベント コマンド
32. 32 SPエディタに新エディタを搭載してリニューアル
33. 33 指標はどれくらい改善されたか
34. 34 指標はどれくらい改善されたか • デバッグ工数の削減量 　　→ テスト環境を整えたので大幅に削減できた • 実装工数の削減量とリードタイム短縮 　　→ 4環境への対応が不要になり大幅に削減できた • メンテナーの数とオンボーディング時間改善 　　→ アルバイトがすぐに開発に取りかかることができた
35. 35 持続可能なエディタ保守に向けて
36. 36 持続可能なエディタ保守に向けて • より一層メンテナーの数を増やす • ユニットテストやE2Eテストを充実させる • RangeやSelectionに関する理解が深まるような環境づくり
37. ご静聴ありがとうございました 37