Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
2023-04-28_Muddy_Web.pdf
Search
pagu0602
April 28, 2023
Programming
0
3.9k
2023-04-28_Muddy_Web.pdf
pagu0602
April 28, 2023
Tweet
Share
More Decks by pagu0602
See All by pagu0602
パフォーマンス改善のケーススタディ
pagu0602
1
420
Other Decks in Programming
See All in Programming
新メンバーも今日から大活躍!SREが支えるスケールし続ける組織のオンボーディング
honmarkhunt
5
7.2k
AI時代のソフトウェア開発を考える(2025/07版) / Agentic Software Engineering Findy 2025-07 Edition
twada
PRO
86
29k
What Spring Developers Should Know About Jakarta EE
ivargrimstad
0
470
PHPで始める振る舞い駆動開発(Behaviour-Driven Development)
ohmori_yusuke
2
390
5つのアンチパターンから学ぶLT設計
narihara
1
170
Blazing Fast UI Development with Compose Hot Reload (droidcon New York 2025)
zsmb
1
290
チームで開発し事業を加速するための"良い"設計の考え方 @ サポーターズCoLab 2025-07-08
agatan
1
420
Quand Symfony, ApiPlatform, OpenAI et LangChain s'allient pour exploiter vos PDF : de la théorie à la production…
ahmedbhs123
0
190
Systèmes distribués, pour le meilleur et pour le pire - BreizhCamp 2025 - Conférence
slecache
0
120
git worktree × Claude Code × MCP ~生成AI時代の並列開発フロー~
hisuzuya
1
570
なぜ「共通化」を考え、失敗を繰り返すのか
rinchoku
1
650
生成AI時代のコンポーネントライブラリの作り方
touyou
1
210
Featured
See All Featured
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.7k
A Tale of Four Properties
chriscoyier
160
23k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
20k
A designer walks into a library…
pauljervisheath
207
24k
YesSQL, Process and Tooling at Scale
rocio
173
14k
Designing for Performance
lara
610
69k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Rebuilding a faster, lazier Slack
samanthasiow
82
9.1k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Transcript
あああ 1 アメブロにおける WYSIWYGエディタ開発
自己紹介 2 柳 耕太(やなぎ こうた) / パグ Twitter: @pagu0602 • 2017年入社、Ameba7年目 •
Webフロントエンドエンジニア • アメブロの運用開発 ◦ Ameba Pick(アフィリエイト機能)の立ち上げ ◦ WYSIWYGエディタ開発 ◦ アメブロにおけるSPブラウザ向けのエディタ開発
現状の説明 3
4 1. アメブロとエディタについて 2. 現状の課題感 3. 改善プロジェクトの立ち上げ
5 アメブロとエディタについて
6 アメブロについて アメブロは今年で19周年を迎え る誰でも簡単にブログを書くこ とが出来るサービスです。 記事数は25億記事以上存在し、 日々様々な記事が投稿されてい ます。
7 アメブロを書くために用いるエディタについて Web - PC Web - SP iOS Android
8 アメブロのエディタについて - 設計 PC SP Android iOS ユーザーインターフェース ユーザーインターフェース
ユーザーインターフェース ユーザーインターフェース エディタ機能 エディタ機能 エディタ機能 エディタ機能
9 現状の課題感
10 現状の課題感 - PCのエディタ設計 • ライブラリとしてCKEditor 4を利用している • コアのコードを書き換えており、アップデートが難しい ◦
サポートが今年で切れてしまう →メンテナビリティに不安を抱えた状態
11 現状の課題感 - 開発コストが高い PC Android iOS 機能 実装 実装
実装 リリース 各プラットフォームの実装が完了次第 SP 実装 →機能を各プラットフォームで実装する必要がある →機能落ち、もしくは待ちが発生する
12 現状の課題感 - 属人性が高い • あまり使われないAPIや機能についての理解が求められるケースがある • 機能同士の相性が悪いことがあるが、それを考慮出来る範囲が人によって違う ◦ 範囲選択をしてセンタリングをした場合にこの要素には適用しない等
→エディタに関わる案件をアサイン出来るメンバーが限られている
13 現状の課題感 - デグレの検知が困難 • エディタの操作を自動的にテストする環境がない ◦ テスト項目書から漏れるケースがある • 特定のデバイス・ブラウザ・OSで発生するバグ等も存在
→テスト項目書が膨大になりがちで、完璧に網羅するのも難しい →ユーザーのお問い合わせで発覚するケースも有る
14 改善プロジェクトの立ち上げ
15 改善プロジェクトの立ち上げ 『各プラットフォームで使える共通のエディタを開発し 堅牢なテストで動作を担保できている状態』 プロジェクトのゴール
16 改善プロジェクトの立ち上げ - 評価方法 • デバッグ工数の削減量 • 実装工数の削減量とリードタイム短縮 • メンテナーの数とオンボーディング時間改善
→これらを概算で出して承認を得た上で評価にも用いることに。
WYSIWYGエディタ開発について 17
自己紹介 18 捧 貴史(ささげ たかふみ) Twitter: @sasaplus1 • 2017年中途入社 • Webフロントエンドエンジニア •
アメブロの運用開発 ◦ ビルド環境やCIの整備 ◦ WYSIWYGエディタの開発
19 1. エディタの設計について 2. 指標はどれくらい改善されたか 3. 持続可能なエディタ保守に向けて
20 エディタの設計について
21 エディタを設計する前に • アメブロ固有の前提条件や制約、悩んだこと ◦ contenteditable属性の使用が必須 ◦ document.execCommandを使用しない ◦ エディタライブラリを使用するかどうか
22 contenteditable属性とは • HTMLの要素に付加できるグローバル属性 • 要素の内容をユーザーが編集できるようになる https://developer.mozilla.org/ja/docs/Web/HTML/Global_attributes/contenteditable
23 contenteditable属性の使用が必須 • なぜ属性を使用する必要があるのか? ◦ 既存の機能の1つがcontenteditable属性の要素の中で 使用されることを前提とした実装をしているため → この属性を使用していないエディタライブラリを使用すると
機能が壊れる可能性がある
24 document.execCommandとは • 編集可能領域に対して様々な変更を加えることができる ◦ 文字の装飾(太字、斜体、色、等々) ◦ Undo/Redo ◦ コピー
& ペースト ◦ 等々
25 document.execCommandを使用しない https://developer.mozilla.org/ja/docs/Web/API/Document/execCommand • 非推奨となっており、いつ機能が削除されるかわからない • ブラウザによって対応もまちまち → 自前で実装する方針に
26 エディタライブラリを使用するかどうか • これまでの条件に合うライブラリが存在するか調査した ◦ GitHubで"editor"を検索した ◦ 条件に合うものはいくつか存在したものの最終更新が数年 前のものなどが多数 •
Lexicalの登場でDraft.jsがメンテナンスモードとなるなど 外部要因に振り回されたくないという気持ちもあった https://lexical.dev/ https://draftjs.org/ → ライブラリを使用しない方向で作ることに
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 エディタを設計するにあたって • 目指したいこと ◦ 機能の追加が容易であること ◦ 保守に苦労しないこと ▪ コードベースが大きくなりすぎないこと
▪ ソースコードを読むときに当たりを付けられること
29 機能の追加が容易・コードベースの肥大化に対して • 現状のエディタの機能を単純に再実装していくと確実に コードベースが大きくなっていくはず → 機能をプラグインとして単体のnpmモジュールとする → プラグインの管理や連携を担うコアモジュールを作る
30 構成図 コア packages/core プラグイン Undo&Redoプラグイン packages/plugin-undo-and-redo 文字装飾プラグイン packages/plugin-decorator プラグイン
各種プラグイン packages/plugin-xxx
31 コアとプラグインの連携 コア packages/core プラグイン Undo&Redoプラグイン packages/plugin-undo-and-redo 文字装飾プラグイン packages/plugin-decorator プラグイン
各種プラグイン packages/plugin-xxx contenteditable要素 イベント コマンド
32 SPエディタに新エディタを搭載してリニューアル
33 指標はどれくらい改善されたか
34 指標はどれくらい改善されたか • デバッグ工数の削減量 → テスト環境を整えたので大幅に削減できた • 実装工数の削減量とリードタイム短縮 → 4環境への対応が不要になり大幅に削減できた
• メンテナーの数とオンボーディング時間改善 → アルバイトがすぐに開発に取りかかることができた
35 持続可能なエディタ保守に向けて
36 持続可能なエディタ保守に向けて • より一層メンテナーの数を増やす • ユニットテストやE2Eテストを充実させる • RangeやSelectionに関する理解が深まるような環境づくり
ご静聴ありがとうございました 37