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
코딩 에이전트 체크리스트: Claude Code ver.
nacyot
0
930
生成AI時代のコンポーネントライブラリの作り方
touyou
1
290
LT 2025-06-30: プロダクトエンジニアの役割
yamamotok
0
870
なぜ「共通化」を考え、失敗を繰り返すのか
rinchoku
1
680
PicoRuby on Rails
makicamel
3
140
The Niche of CDK Grant オブジェクトって何者?/the-niche-of-cdk-what-isgrant-object
hassaku63
1
620
Agentic Coding: The Future of Software Development with Agents
mitsuhiko
0
130
Model Pollution
hschwentner
1
160
「App Intent」よくわからんけどすごい!
rinngo0302
1
100
マッチングアプリにおけるフリックUIで苦労したこと
yuheiito
0
190
Flutterで備える!Accessibility Nutrition Labels完全ガイド
yuukiw00w
0
170
ソフトウェア設計とAI技術の活用
masuda220
PRO
17
3.8k
Featured
See All Featured
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Java REST API Framework Comparison - PWX 2021
mraible
31
8.7k
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.5k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.6k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Designing for humans not robots
tammielis
253
25k
Being A Developer After 40
akosma
90
590k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.8k
KATA
mclloyd
30
14k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
750
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