「いいね!」した人を新しい順に10人分表示するようにしました。
対象 🔗
他のページも直しました。
キャッシュ削除してリロード 🔗
もしかすると古いままかもしれません。そんなときはキャッシュ削除してください。
chromeブラウザなら以下の手順でできます。
- デベロッパツールを開く
- リロードアイコンを長押しする
キャッシュの消去とハード再読み込み
を選ぶ
こんなことをエンドユーザにさせるのはおかしい。でも、どうすればいいかもわからないので。
原因 🔗
今回「いいね!」して頂いたのですが、それをうまく処理してなかったためバグったようです。
そもそもmentionには種類があって、返ってくるJSONデータが違いました。それを考慮していなかったためエラーになったようです。
mentionの種類 🔗
webmentionには6種類のメンションがあるそうです。webmention.io api
種別 | 意味 | content.html 有無 |
---|---|---|
in-reply-to |
ツイッターでいう「返信」だと思われる | ? |
like-of |
ツイッターでいう「♡いいね!」だと思われる | ❌ |
repost-of |
ツイッターでいう「リツイート」だと思われる | ⭕ |
bookmark-of |
「ブックマーク」だと思われるが、どのサービスで使える? | ? |
mention-of |
マストドンの「トゥート」がこれだった | ⭕ |
rsvp |
なんぞこれ?(日本語に翻訳したら「お返事お願いします」だって) | ? |
エラー原因 🔗
コメント欄に表示する内容はwebmention APIで返ってきたJSONオブジェクトのうちcontent.html
です。が、「いいね!」はその性質上、表示すべき内容がありません。そのせいかcontent.html
プロパティを持っていませんでした。それなのに私はcontent.html
が存在する前提でコードを書いていたため「ねーよ」と怒られ、エラーになってました。
対処 🔗
「いいね!」した人を新しい順に10人分表示するようにしました。
同じく、ブックマークした人を新しい順に5人分表示するようにしました。
こんなことまでできるなんて、すごいぞwebmention! 自分で書く必要はあるけど、自由に作れるのは楽しいのでOK。
例によってまだ10件も反応がないので、そのうち新たなバグが見つかるかもしれません。あるいは永久に10件以上いいね!されずに問題ないかもしれません。それはそれで悲しいですが。
他のメンションはどうなる? 🔗
今のところ、ツイッターでlike-of
(いいね)とrepost-of
(リツイート)をして頂けたので、その分はこうしてバグを見つけられました。ありがとうございます!
でも、まだ他のがわかりません。たぶんbookmark-of
もcontent.html
がないと思われます。なので今回はlike-of
と一緒に、そのアクションをした人の情報を表示するようにしました。
in-reply-to
(返信)は、たぶんcontent.html
があると思います。なのでコメント欄に表示される、はずです。
rsvp
(お返事お願いします)は、よくわかりません。ツイッターやマストドンでそれらしき機能ってあるのかな? あるいは他のサービスにあるか、webmention独自のマークアップか。どうやってテストすればいいのかも、まだわかりません。
よろしければ返信やブックマーク、いいねなどを試してみてください。
日時おかしい問題 🔗
これはまだ直せてません。すごく大変そうで。一旦保留にします。
どうやらツイッターやマストドンなどのサービスによって返ってくる日時テキストが違うようです。しかもそのテキストはISO8601形式を正しく守っていないように見えました。タイムゾーンのあたりが統一されていせいで9時間ずれたり、ずれなかったりしやがります。
ことの発端はリツイートされた情報の日時がおかしかったことです。いや、こっちが正常なのか? ともかく朝の時点でytyaruのプロフィールのコメント欄で-1年前
と表示されてました。マイナスってことは未来の日時になっているということでしょうね。
じつは私が9時間加算する処理を書いています。その理由は、私がマストドンでテストしたときはUTC時刻で9時間前のものだったからです。てっきり、そういうものだと思って9時間足したんですよね。無条件で常に。でもツイッターは違ったようです。なので未来の時間になったと思われます。
サーバによって返す日時テキストが違うと発覚しました 🔗
これが問題です。しかも、どいつもこいつもISO8601形式を正しく守っていない。
たとえば以下のようなデータが取得されました。
サーバ | 日時テキスト |
---|---|
マストドン(mstdn.jp) | "2022-05-24T02:49:03" |
ツイッター | "2022-05-27T22:09:18+00:00" |
マストドンのほうは私がテストしたときのものです。時刻に注目してください。02:49:03
とあります。決して深夜2時にやったわけでなく、UTC標準時です。なので日本時間から9時間マイナスされた時刻なんです。これに9時間足した11
時頃が正しい日本時間です。なので私は9時間足したわけです。
ところが、ツイッターのほうは違いますね。22:09:18
とあります。22時です。たぶんこれはUTC標準時でなく日本時間でしょう。なので9時間足す必要はありません。それなのに私は9時間足してました。なので未来の時間になってしまいバグったと思われます。
ISO8601形式でないため正しくパースできない 🔗
じゃあ、あとはよしなにやるだけじゃない? と思うでしょう? 違うんです。よく見てください。これらの日時テキストは、正しくISO8601形式になっていません。そのせいでテキストから正しい日時にパースできないんです! ムキー!
私が思うに、マストドンは末尾にZ
をつけてUTC標準時であることを示すべきだし、ツイッターのほうはタイムゾーンを日本の+09:00
にして日本のタイムゾーン時刻であることを示すべきでしょう。以下のように。
サーバ | 日時テキスト |
---|---|
マストドン(mstdn.jp) | "2022-05-24T02:49:03Z |
ツイッター | "2022-05-27T22:09:18+90:00" |
まとめます。
項目 | マストドン | ツイッター |
---|---|---|
現状 | 2022-05-24T02:49:03 |
2022-05-27T22:09:18+00:00 |
正常 | 2022-05-24T02:49:03Z |
2022-05-27T22:09:18+09:00 |
なんとかして正常な値を取得したいんです。そうすれば正常にパースできて、正しい日時が表示できるはずなんです。9時間足す処理を追加するとか、それをやめるとか、そのどちらであるかを分岐するとか、そんなバカげた処理なんて不要なはずなんです。ちゃんとISO8601形式に沿ったデータを返してくれれば。
const iso8601String = `2022-05-24T02:49:03Z`
Date.parse(iso8601String)
でも現状、各サーバごとに気分や雰囲気で日時テキストを返しているっぽいです。いいかげんにしろ。もし私の勘違いならごめんなさい。
どうしよう…… 🔗
どうすっかなぁ。どうせ使っているサービスやマストドンインスタンスは全部で3つだけだし、ゴリゴリにコード書いて対応できなくもない。でもなぁ、バグに対処するためのコードを作り込むって、ありえない。そのせいでまた新しいバグを私が作っちゃいそうだし。
それに、もしいつかサーバ側がちゃんとした値を返すように修正したらどうなるの? また対応しなきゃなの? そのときのことも考えてコードを書けと? やっぱこっちで対応する問題じゃないよね。
サーバ側がちゃんとISO8601形式に対応してくれたらいいだけなのになぁ。という気持ちが拭えず。この対応をするくらいなら、もっと他にやりたいことがたくさんあるんだよなぁ。
というわけで、日時バグの件は一旦保留!
すごいモヤるけど。