Notification as a Serviceが求められる

文脈

現在のWeb開発現場では

• Firebase
• GAE
• AWS Lambda
• CDN
• クラウド型の
  • RDBサービス
  • K8s ホスティングサービス
  • ログ収集サービス
  • 死活監視サービス

が使われるようになった。

これを、Webアプリケーション開発者はビジネスロジックの開発のみに集中しそれ以外のめんどくさいことは各クラウドサービスに外出しする流れと総括できるだろう。
（WebアプリにはAndroidアプリやiPhoneアプリも含む）

僕はいま、Webアプリにおける通知もこの仲間に入っていくであろうと予測している。
そのことについて書く

通知とは

ここでは以下のものを通知と呼ぶ。

まず、ServiceWorker、iOSのAPNS、AndroidのFCSを使ったプラットフォームのネイティブのサーバーPush型ポップアップ通知機能が挙げられる。

また、Webサービスにありがちなベルマークの右上に未読件数が赤丸で表示されるだけのものも通知に含むことにする。

この場合、そのページにアクセスしたときだけ最新の件数を取得するものと、サーバー側でイベントがあればWebSocket等でベルマークをRefreshする機能を持つもののどちらも通知に含む。

メールやLineを使って通知するものも含む。

通知も内容によって色々あるが、主にSNSにおける「いいねされました」「コメントがつきました」のような内容のものの話をする。

今のお気持ち：通知はめっちゃ難しい

通知の機能を作るのはめちゃくちゃ難しい。

通知のプロトコルやSDKの話ではなく、通知機能を入れるとコードが汚れるという話。

僕はアーキテクチャを整頓するのが得意で、自分が作っている情報システムはコード量が増えれば増えるほど新規機能追加コストが下がっていく傾向がある。

しかし、通知周りはどんどん脳みそにかかるコストが高まっている気がする。

なぜ難しいのか

発生源がたくさんある

Twitterであれば

• フォローされた
• いいねされた
• RTされた
• リプされた
• 引用Tweetされた
• その他広告っぽいもの

などがごった煮になっている。それがコードの追いにくさにつながっていると思う。

また、SQLを含む多くのコンピューター言語は代数的データ型を持たない。
よって、正確なif文を書くのがちょっと難しいケースがある。

未読既読管理

これはDBに大量の変数を持たなければいけないことを意味する。

また、中には既読の中に「画面に表示された」「タップして詳細を見た」等の複数のタイプを持つものもある。

RESTFulとの親和性

場合によってはGET メソッドに副作用を持たせなければいけないかもしれない。

グルーピング

Twitterであれば一つのTweetに二人がいいねしてくれたとき、その通知が１行にまとめられる。

ユーザーにとっては便利だが作る側からすると地味にめんどくさい機能である。

キャンセラブルである

Twitterであれば、自分のTweetに誰かがいいねしてくれて、その後にTweetを消した場合、いいねに対する通知を消さなければいけない。

毎度、DB上にどんな通知が残ってるか考えるのが辛い。

JOINした状態で保存できない

通知はその機能の使われ方の性質上、できれば非正規化しておきたい。

例えばいいねの通知なら、いいねしてくれた人のユーザー名は通知のレコードと一緒に保存しておいたほうが負荷が少ないだろう。

しかし、それをしてしまうといいねした後に名前を変えた場合どうするのかを考えなければいけない。

間違いの影響がでかい

サーバーサイドからPushして画面に表示するタイプの通知の場合、間違って同じ通知を二回送ってしまったらユーザーに嫌われる。

また、間違った内容の通知を送ってしまったら取り返しがつかないケースが多い。

データ量と更新頻度が高い

これは、何か変更があったら関係ありそうなデータをDBをから全部落としてきてキャッシュファイルを洗い替えするような手抜きがしにくいということだ。

常に計算量やDBからの転送量を意識してコードを書かないといけない。

外出しされる部品の特徴

ここまで通知を実装することの難しさを挙げた。ここから通知をクラウドサービスが巻き取ることの合理性の話をする。

上に挙げたクラウドサービスに巻き取られるパーツにはこのような要素があると思う

• 外出してもしなくてもビジネスロジックが変わることがない
• スケールしてくれると嬉しい
• APIや外から見た振る舞いは単純だが、内部に複雑な状態を持つ
• 運用が難しい
• だいたいどの会社も同じようなことをしてる

こう見ると通知 as a Serviceはまさにこれに適していると思う。

どのようなAPIを持つのか

おそらくサーバーサイドアプリケーションからHTTPで問い合わせるようなものになるだろう。

もちろん通知サービスが独自のドメインを持ちクライアントと直接やり取りするような実装も可能である。

事前にYAML等で、このシステムがどんな通知機能を持つのかをアップロードしておくと良さそうだ。

一種の腐敗防止層になってくれそう。

YAMLよりもSwiftのようなコンピューター言語で定義するのもいいアイディアだと思う。

type aliasと代数的データ型を持つ言語なら正確かつ簡単に型付けできていい。

アプリケーションサーバーから通知サービスへ構造体をPostすることで通知を作成する。

このとき、構造体の型と各propertyの値の組み合わせがサービス全体で一意になるようにする。

そうすると、既読管理と重複Push防止ができる。

また、propertyの型をType Aliasとするとリレーションが表現できるので、キャンセルや非正規化する時に間違い防止ができる。

つまり

struct Like {
let from:UserID
let to:UserID
let tweetID:TweetID
}

という構造体にしておけば、関連のあるユーザーかTweetが消されたらその通知は消していいということが型で判断できる。

同様に、ユーザー名が変更されたときも、アプリケーションサーバーから通知サービスにそのユーザー構造体を送れば自動で再JOINしてくれるようにできる。

モックサーバーのすすめ

主張

• SPAを作るときは、Node.js/ExpressでAPIモックサーバーを作るといい
• SPAの動作確認・表示確認に有効である
• 特にリアルタイム性があるアプリを数人で動作確認するのに有益

前提

本番用のサーバーはGoやScala、フロントエンドはReactなどで作る想定をしています。
本番用サーバーのコードベースに一つの機能を実装するのは時間多少時間がかかります。なので、新規開発時や機能追加時は先にフロントエンドとモックサーバーを実装することにより企画を固めてから、本番用サーバー開発に手を回すほうが合理的だと考えています。
Swaggerのモックサーバジェネレータで満足できる方は別にそれでいいと思います。
ReactのStorybookで満足できる方も別にそれでいいと思います。

SPAの動作確認・表示確認をするためにステートフルなモックサーバーがほしいことがあります。
例えばTwitterのようなSNSを作っているとして、投稿したらちゃんとタイムラインに表示されるか確認したいことがあります。
そのため、ちゃんとそれっぽい挙動をするモックサーバーを作るといいです。

やること

1. ExpressでAPIのモックサーバーを作る
2. webpack-dev-serverのproxy機能で1のサーバーに転送するように設定
3. フロントエンドは普通に作る
   • 基本的にフロントエンドに特殊なコードを書く必要はない
   • ただし、本番でFirebaseを使うがモックサーバはWebSocketで済ませたい場合は、そこをすげ替える仕組みがあるといい
4. webpackで動かして試してみる

参考までにwebpack.config.jsonを載せておきます。

let webpackHost = "0.0.0.0";  
if ("WEBPACK_HOST" in process.env) {  
    webpackHost = process.env.WEBPACK_HOST;  
}
...
devServer: {  
    contentBase: "./dist",  
    hot: true,  
    host: webpackHost,  
    port: port,  
    proxy: {  
        "/api": {  
            target: `http://${webpackHost}:${port + 1}`,  
            pathRewrite: {"^/api": ""}  
        },  
        "/ws": {  
            target: `ws://${webpackHost}:${port + 1}`,  
            ws: true  
  }  
    },  
},
...

作るモックサーバはどんなものか

データの永続化は不要です。グローバル変数に持っておけばいいです。
立ち上げたらすぐに表示を確認したいので、適当なデータを自動で生成するものを作るといいです。例えばTwitterなら100人のユーザーと100の投稿を自動で作ります。
APIエンドポイントはちゃんとそのAPIを模倣するように作るべきです。

• Tweet取得APIはグローバル変数から値を返す
• 新規Tweet投稿APIはTweetをグローバル変数に追加する

としておくと、フロントエンドを実装したら本当に投稿できるようになっていいです。

サンプルデータをJSONでファイルに保存しておくのも良い手段です。JSONをそのまま返すのではなくて、スピンアップ時にJSONを読んでグローバル変数に入れるようにするとフロントエンドの操作に合わせて動的な反応ができていいです。

サンプルコード

// 必要に応じてサンプルデータも入れておくといいです
interface Data {  
    tweets: Tweet[];  
    users: User[];  
}

let data: Data = {  
    users: [],  
    tweets: [],  
};

router.get("/api/tweets", (req, res) => {  
    res.json(data.tweets);  
});

router.post("/api/tweets", (req, res) => {  
    let tweet = req.body as Tweet;  
    let tweetID = randomBytes(16).toString('hex');  
    tweet.tweetID = tweetID;  
  
    res.status(201);  
    res.send(tweetID);  
});

開発コストをどう考えるか

永続化をせず全てグローバル変数を使うので大変ではないと思います。
セキュリティのことも考えなくていいので簡単だと思います。
大体 RESTFul APIといえば

• get
• post
• put
• delete

です。なので一つのエンドポイントをJSの

• find
• concat
• filter

を使って書けば、後は他のエンドポイントにコピペするだけです。
Swaggerを使っている人には関係ない話ですが、僕は使わないことにしたので、フロントエンドとJSONの型定義用TypeScriptファイルを使いまわせるので楽です。
なので、大してコストはかからないと思います

ファイル構成についてのアドバイス

今の所これが最善だと思っています。
リポジトリを分けることにした理由は、求められるtsconfigが違って辛いからです。
そんなことはtsconfigを２つ用意してコンパイル時に引数で分ければいいではないかと思うかもしれないですが、僕が使っているWebStormがうまくいかなくなるのでやむを得ないです。
他にも、WebStormのSuggestionが汚れて辛いとかの理由があります。

5は大変ダーティーですが、所詮モックサーバーなのでまあいいとします。
本当はフロントエンドとモックサーバーは双方向に依存していますが、package.json上で双方向に依存しているとライブラリ関係でろくなことにならないのでこうします。

1. フロントエンドとモックサーバーはリポジトリを分ける
2. フロントエンドがモックサーバーをインポートする
3. フロントエンドでnpm run startするとwebpackとモックサーバーが両方立ち上がるようにしておく
4. 開発PCではフロントエンドとモックサーバーを隣のディレクトリに並べる
5. モックサーバがフロントエンドリポジトリ内のファイル（主にTypeScriptによるJSONの型定義ファイル）が必要な場合は ". ./隣のリポジトリ/some/file.ts"とインポートする。

本番サーバーができたら

本番サーバーが出来上がってもメンテするべきです。
なぜなら、企画→フロントエンドだけ作ってみる→実機で見て企画を練る→　というサイクルを回すために、このモックサーバーは使われ続けるからです。
GoやScala製の本番サーバは永続化層のコードを書く必要があるため、モックサーバに比べて開発のオーバーヘッドが高いはずです。常にどんな企画もモックサーバーで手早く実機確認できるようにしてあるといいです。

また、本番が始まったらassetsやマスタデータを本番から落としてくるシェルスクリプトを作っておくと、いつでもそれらしいデータを表示できるのでおすすめです。

副次的な効能

リアルタイム性があるような動き（例えば、Tweetが投稿されたら他人のタイムラインに投稿が表示されるなど）が早期に仮実装されると、企画さんが喜びます。その後が遅れちゃっても少々大目に見てくれます。フィードバックは大事です。

MySQLからリアクティブにFirebaseを更新するものを作った

コンセプトは f(RDB)=> Firebase

モチベーション

Firebase Realtime Databaseを使う上でこのような問題点がある

• あえて非正規化した場所が、バグによって正しく更新されず不整合になるリスク
• 正確なアクセス権限設定が極めて難しい
• 枯れたRDBほどマイグレーションツールが揃っていないためAlter Table的な操作をしたくない

そこで、Realtime Databaseの前にRDBを置き、RDBからReactiveにRealtime Databaseを更新すれば解決できると考えた。

実装

MySQLから更新イベントを受信するためにはmysqlbinlogというコマンドを使う。
これは本来全然別のことに使うためのものだが、せっかくなので使う。

RDBの全データを引数にRealtime Database上の全データを作る純粋関数を書く。

mysqlbinlogが標準出力に何かを書いたら、それに反応してfirebaseを更新する。

サンプル

void main() async {
  var command = "mysqlbinlog --read-from-remote-server --short-form --host=localhost --user=your_name --password=*** --stop-never mysql-bin-changelog.000001";

  var process = await Process.start(command , []);
  process.stdout.listen(onStdout);

}


class UserEntity {
  int userID;
  String name;
}

class MessageEntity {
  int messageID;
  DateTime time;
  String text;
  int userID;
}

void onStdout(List<int> data) async {
  print("-" * 10);

  var conn = await MySqlConnection.connect();

  var result = await conn.executeStreamed("select * from users");

  List<UserEntity> users = [];

  await for (var row in result) {
    var user = new UserEntity()
      ..userID = row[0]
      ..name = row[1];
    users.add(user);
  }

  var result2 = await conn.executeStreamed("select * from messages");

  List<MessageEntity> messages = [];

  await for (var row in result2) {

    var message = new MessageEntity()
      ..messageID = row[0]
      ..time = row[1] as DateTime
      ..text = new Utf8Decoder().convert((row[2] as Blob).toBytes())
      ..userID = row[3];
    messages.add(message);
  }

  messages.sort((m1, m2) => m1.time.compareTo(m2.time));


  var fbMessages = messages.map((m) => <String, dynamic>{
    "time": m.time.toLocal().toIso8601String(),
    "text": m.text,
    "userName": users.firstWhere((u) => u.userID == m.userID).name,
  }).toList();


  await fbClient.put("/messages",fbMessages);

}

今後の課題

今はパフォーマンスが悪すぎるので改善したい。

1. バイナリログをきちんと読み取って、毎回全データを落としてくるのではなく、関係のある行のみを落としてくるようにしたい
2. Realtime Databaseに全データを書き込んでいるので、今回の出力と前回の出力を比較して差分更新できるようにしたい
3. 今はRealtime Databaseに書き込む全てのデータを毎回作っているので、関数を小分けにして、無関係な部分は実行しないようにしたい

また、クライアント側からのアクションをMySQLに書き込むところも上手く抽象化したい

日本は今すぐUber Eatsのオープンプラットフォームを作るべき

Uber Eatsがよかった

今日、初めてUber Eatsを利用して見た。UXが素晴らしかった。

• 店舗を選ぶ
• メニューを選ぶ
• 自分の住所を入れる
  • 料金+配送料が表示される
• クレカを入力
• OKボタンを押す
• 配達員さんが今どこにいるのか地図に表示される

という完璧なUXだった。
Webアプリは簡潔でわかりやすかった。
すでにUber Eatsにハマりそうである。

Uber Eatsが解決した問題

そもそも、僕はあまり飲食店を開拓しない方だ。いつも同じ店に行っている。
新しい場所というだけで落ち着かない。
店ごとに注文方式、メニュー体系、前払いか後払いかが違う。

デリバリーも可能だが問題がある。多くの場合電話を強要される。電話が嫌なのだ。

ネットで注文できる店もある。
しかし、店ごとに

• パスワードを作って会員登録
• 住所入力
• クレカ登録

をしなければいけない。
割りに合わない。
また、飲食店のホームページは店側の見せたい情報がてんこ盛りで、なかなか目当ての情報にたどり着けない。
自分に必要な情報が整然と並んでいて欲しいのだ。

しかし、Uber Eastsはすごい。

まず、今後ここに出店している店舗に注文する限り同じ会員情報を使いまわせる。
店舗数は結構多いし、ガストなどメニューが広い店舗もあるので、飽きることはないだろう。

Webアプリは、非常に整頓されていた。見苦しい宣伝文が少ないし、どんなメニューがあるのか一目瞭然だった。
料金体系も非常に的確なフィードバックがなされてわかりやすかった。

なぜ今までこれがなかったのか

僕はちょっとがっかりした。
Uber Eatsの要素を見れば、20年前の技術水準で十分に似たようなものは作れたはずである。
なぜ今まで日本の外食産業はこれを作らなかったのか。
今になって外資系に高額な手数料をふんだくられているのか。
日本のプラットフォーム構築能力の低さにがっかりする。

今からでも遅くない。すぐに取り掛かるべきだ。

するべきこと

前提として一社がプラットフォーマートして一人勝ちする構図は避けたい。
まず、各店舗がメニュー表を自分のドメインから所定のXML的なものでフィードする。
そのフィードをお客さんが自分のアプリで閲覧する。
フィードのフォーマットはオープンに定められ、誰が対応するアプリを作ってもいいことにする。
フィードは過剰な装飾ができないフォーマットになっているべきである。
お客さんは自分のアプリから注文する。
この時の注文プロトコルも事前に決めておく。
配送業者の位置情報を追跡するための鍵交換のプロトコルも必要であろう。

ブラウザの画面を転送するものを作った

ブラウザの画面をもう片方の画面に転送するものを作った。

めっちゃ簡単にWeb上の画面を他の端末に再現するものを作った。
ユーザーテストとかに使えそう。

Android・PCはWebRTCで
iPhoneはWebSocketで画面を転送する。 pic.twitter.com/smxdYBwRiE

— 弩.net@Coqやっていき (@isyumi_net) December 23, 2018

動機

AWSがWebSocketのリバプロに対応してくれた。

これまでWebSocketでいろいろ作った。楽しかった。しかし、一つ問題があった。WebSocketを使うとインフラ・デプロイの自動化が不可能になる点だ。HTTPと違いユーザーが使っている間はずっと接続が維持される。つまり、ユーザーが一人でも残っていたらサーバーを捨てれないのだ。

そこで、Nginxなどを使って自前でWebSocketリバースプロキシを立てるのがこれまでの習慣だった。当然、そのサーバーにパッチを当てたりするのが嫌になる。

この度、それをAWS側が巻き取ってくれることになった。ありがたい。せっかくなので前々から作ろうと思っていたこのシステムを作った。

用途

ユーザーテストとかに使えると思う。

あと、無許可でお客さんに対してやるのはやめましょう。 

動作要件

送信画面は数行のJSを入れられればなんでもいい。

WebSocketサーバーは別のドメインになっても問題ない。

受信画面は送信画面と同じドメインに存在する義務がある。これは主に相対アドレス解決の問題である。無理なら手元にプロキシサーバーを立ててhosts.txtに入れればよいだろう。WordPressを使うなら、共通ヘッダーに受信用スクリプトを入れて、固定ページに送信用スクリプトを入れればいいだろう。

やっていること

1. 画面の変更を検知
2. innerHTMLを取得
3. それをWebSocketで別のブラウザに転送
4. innerHTMLをサニタイズ
5. 表示

画面の変更検知

1. DOMの変更検知
2. Touchイベント
3. InputEvent
4. Scrollイベント

MutationObserver

developer.mozilla.org

DOMの変更を検知するもの。以前はDOMNodeInsertedなどを使っていたが、現代ではこのAPIを使うべきだ。このAPIはコールバック関数が非同期で起動されるのでユーザーにやさしい。

Touchイベント

Start/End/Moveイベントを拾うことでスワイプをたどることができる。

毎度毎度clientYとかscreenYとかpageXとか、どれを使えばいいんだっけとググる羽目になるので、正解を書いておく。clientXとclientYだ。

InputEvent

MutationObserverとinnerHTMLだけではinput要素の中を取れないようだ。どのハンドラを使うべきかだが、

• onChangeだとフォーカスが外れるまで発火しない
• onKeyPressだと最新のvalueが取れない

という点を考慮し、今のところonKeyUpイベントをハンドルするのが正解ではないかという気がする。

一つ問題がある。DOMの中の特定の要素を一意に指すことができるグッドな方法がないことだ。一般的にXPATHが使われる。しかし、JSにはあるDOMのXPATHを取り出すAPIもXPATHからDOMを取り出すAPIもない。

そこでその要素は同じタグの何番目というXPATHもどきを作った。

String getPath(HtmlElement element) {
  var tagName = element.tagName.toLowerCase();
  var tags = document.querySelectorAll(tagName);
  var elementIndex = tags.indexOf(element);
  return "${tagName}/${elementIndex}";
}

これなら画面を超えて一意に特定のDOM要素を指すことができる。

Scrollイベント

当たり前の話だが、目上の人のwindowのscrollイベントをハンドリングするときはpassiveを指定するのがマナーです。

innerHTMLの送信

おそらく

• HEADタグの中身
• BODYタグの中身
• 現在のスクロール位置
• 現在のURL

を１セットで送るのが合理的なようだ。理由は↓。

サニタイズ

まず、innerHTMLをDOMに変換したい。いきなりwindow.documentに入れてしまうと大変なことになる。

DocumentFragmentというブラウザのAPIを使うのが正しいと思う。自分はDartで書いたのでJSの詳細なAPIは存じ上げないが、nsTreeSanitizerというのを正しく設定しないとダメなようだ。Dartの場合はtreeSanitizer: NodeTreeSanitizer.trustedでおｋ。

次にHEADのDocumentFragmentにbase要素を入れる。こうすることで送信画面と同じCSS・imgを見に行ってくれる。

次にスクリプトを削除する

• スクリプトタグを全部消す
• 各要素のonで始まるattributeを全部消す
• Link rel="serviceworker"を前部消す

で大丈夫だと思う。違ったらだれか教えてください。

準備ができたらnodeを入れ替えてScroll位置を設定すれば大丈夫。

MSが社運をかけて世界を変える賭けに出たらいいな

文脈

最近のWeb界隈でよく話題に上るテーマがある。Webの後継技術についてだ。主に二つの理由による。

1. 技術的に古い
2. 仕様が肥大化し過ぎた

そこで、後方互換性を切りモダンな設計で新しいWebを作りなおすべきだという夢が語られるようになった。

次世代のWebとは

おそらく

• 新しいUIコンポーネント
• アプリケーションレイヤーの通信プロトコル
• クライアントサイドプログラミングとAPI
• メディアのコーデック

あたりをモダンなものに置き換えれることになるだろう。それぞれ

• HTML/CSS
• HTTP
• JS
• jpg等

に対応する。

Googleの動向

Googleは次世代のWebを画策しつつ、現行のWebを少しずつ前進させていこうという二正面作戦を取っているように見える。比重は2:8くらいか。僕も今日まで次世代Webの旗手になるのはやはりGoogleかと思っていた。

今日起きたこと

MSがEdgeのレンダリングエンジンを独自のものからBlinkに切り替えるという発表があった。大変残念なことだ。MSが今後Webの世界で覇権を取ることが難しくなったとみられる。
断っておくが、別に僕はGoogleやMSが覇権を取って欲しいと思っている訳ではない。競争によって技術革新が起こって欲しいのだ。だから、MSというGoogleと対等に渡り合える数少ないプレーヤーがリングを降りたことを残念に思う。

夢

そうであれば、MSはWebの後継技術を大々的に打ち出して競争をひっくり返して欲しい。
MSは莫大な資金力と世界最高峰のソフトウェア技術力と絶大なブランド力と強大なインフラとナイスガイなCEOを持つ最強の企業の一つだ。特にクラウドプラットフォーム事業が絶好調であることが好材料だ。OSやOfficeなど過去の資産で食っている状況ではなく、モダンITの世界で気を吐いている。今のGoogleに敵う可能性を持ったほぼ唯一の企業だ。
これからMSがGoogleの

• スマホOS
• 検索エンジン
• Web広告
• ブラウザ

の牙城を崩す可能性は低い。
そこで、起死回生の一発として次世代Webの主導権を取りに来て欲しい。

スマホ用Webアプリづくりには限界がある。

スマホ用Webアプリづくりには限界がある。

この２ヶ月間、あえてiPhoneからTwitterアプリを消して、ChromeでTweetをしていた。

Twitterのスマホ向けWebアプリはネイティブアプリに比べてあまりにも操作感が悪かった。

Facebookも同様だった。

TwitterとFacebookという、おそらく世界で最も金と時間と技術がかかっていそうなWebアプリでもこの程度の体験になってしまうのかとがっかりした。

そこで、不満点の指摘と提言をしたい。

題材としてTwitterを取り上げるが、決してTwitterの悪口ではない。

むしろ普段スマホ向けWebアプリを作ってる身からすると、この苦労は大変良くわかるし、Twitter Webアプリはすごく良くできていると思う。

だから「世界最高峰の人たちでもこうなるんだぞ、今のWebには色々足りないものがあるんだぞ」ということを言いたい。

不満点

Pull To Refreshの判定がきつい

Pull To Refresh（以下PtR）とは、画面を下向きに引っ張ることでコンテンツを更新できる機能である。

多くのアプリに採用されている。

Chromeもそのジェスチャでページのリロードができるようになっている。

Twitterネイティブアプリはそれでタイムラインを更新することができる。

Twitter Webアプリは画面の中央を下向きに引っ張ると同じことができる。

しかし、タブメニューのあたりを下に引っ張っるとTwitterがJSで実装したPtRではなくChrome側のPtR（以後ネイティブPtR）が反応してしまう。

中央を引っ張った場合でも、タイミングによってはネイティブPtRが反応してしまうことがある。

Context Menuが意図せず立ち上がる

コンテキストメニューとは、PCの場合右クリックした時に出るメニューだ。

コピーや印刷などの操作が選べる。

スマホのブラウザの場合、テキストを長押しするとそのメニューが出てくる。

これが厄介者である。時々そんなつもりがなくても立ち上がってしまうことがある。

iPhoneの場合、急に文字列選択UIが出てくる。

キャンセルしようとして適当な場所を押すといいねを押してしまったりする。

別の画面に行ってから戻ってくるとスクロール位置が保存されていない

この手順で再現する

　　１．タイムラインで結構下の方までスクロールする

　　２．適当なツイートをタップしてTweet詳細画面を開く

　　３．戻る

　　４．さっきと違い場所にいる

ポップアップを開いている状態で後ろの画面がスクロールしてしまう

Tweet右上のドロップダウンメニューを開いた状態で上下にスワイプすると後ろで本体がスクロールされている。

ちなみに、多くのWeb開発者は、現在のスクロール位置を変数に保存した上で後ろの画面をposition:fixedにするということをしていると思う。

画像のトリミングができない

意外なことにTwitter のWebアプリではトリミングができない。

これはわからなくもない。

自分もWebアプリでトリミング機能を作ったが、必ずちょっと残念な感じになる。

まず、結構カクつく。また、左から右にスワイプすると、ブラウザの戻るジェスチャにイベントを取られてしまうことがある。ピンチイン・ピンチアウトも指の置き場が悪いと画面全体が縮小・拡大してしまう。

なんかウニャウニャ動く

ネイティブアプリの場合、アプリの外枠が決まっており、それが動くことはない。スワイプで物の大きさが勝手に変わったりしない。

しかし、Webアプリの場合、アプリの外枠や各要素が不自然にリサイズされたりオーバースクロールしたりする。

良かった点

悪口ばかり言っては申し訳ないので補足する。

無限スクロール

無限スクロールとは下にスクロールすると、どんどん新しいコンテンツをサーバーから取ってきて下に追加していってくれる機能だ。

普通にスマホWebアプリで無限スクロールを実装するとかなり怪しい挙動をする。

これだけスムーズに無限スクロールが動いているということは、中の人が結構工夫したと思われる。

ちなみに僕はIntersection Observerとそのポリフィルをつかった。多分パフォーマンス悪いと思う。

提言

前提になる問題として、スマホのブラウザはバテリー節約のためOnTouchMoveEventとOnScrollEventの発生頻度を抑えている。

また、スマホブラウザがネイティブで持っているジェスチャUIは、多くのWebページ閲覧に必要なものだと思うので無くせとは言えない。

なので、スクロールやスワイプのイベントを取らなければ実現できないようなことは、だいたいHTML標準に入れておいてほしい。

HTMLにPtR要素を追加してほしい

また、Document内にPtR要素がある場合はネイティブPtRをオフにしてほしい。

無限スクロール要素もHTMLに追加してほしい

同上

画像トリミング画面を呼び出せるAPIを作って欲しい。あるいは矩形選択要素のようなものをHTMLに追加してほしい。

同上

レイヤーの概念とSegue的な概念を入れてほしい

今の所多くの開発者はBodyの中に適当なDivを作り、スタイル属性のpositionやz-indexを使って階層を表現している。

あるいは諦めて別Tabを開いたりする。

しかし、思い切ってサブBodyのようなものを作れるようにしてはどうか（というかDialog要素はどこへ行った）

その要素へのイベントは一切上要素に伝播されないようにしてほしい。

その要素はHistoryAPIとうまい感じに連携して戻る・進む・リロードの動作が違和感ないようにしてほしい。

スクロール位置はサブBodyごとに持って欲しい。

ちなみに、cssのoverflow:scrollを使えばいいのでは？　と思った人がいるかもしれないが、最大スクロール位置を超えてスクロールすると微妙な感じになるのでちょっとストレス。

ContextMenuをオフにすることをベストプラクティスにしてほしい

これは既存のJSでできる。しかし、嫌悪感がある人も多いだろう。その人は多分おっさんである。

２０００年代、まだWebページのプラクティスが確立してなかった頃、JSでマウスイベントやスクロールイベントを謎フックをしているサイトが跋扈し大変うざがられていた。

マウスにカモメがついて着たり、右クリックをすると画面がチカチカしだすなどの演出を盛り込んでる人がいたのだ。

そのため、「極力ブラウザの標準UIを妨げない」というのがお約束になった。

しかし、スマホにおいてTwitterのようなWebアプリでコンテキストメニューを出せるメリットはないだろう。

ここは思い切って「文書度合いが低くアプリ度合いが高いスマホ向けWebページはコンテキストメニューをオフにするべき」ということをベストプラクティスとしていくべきではなかろうか。

根本的な問題

WebからスマホのネイティブUIコンポーネントを作れるようにしてほしい。