Mastodonのインスタンにオートスクロールなどを付けた

機能としては、ユーザーのパブリックページにjk移動やオートスクロールを付けた。 /@syui

ハマりどころが多すぎて何から解説していいのかわからないけど、覚えている限りで適当に書いてく。

まず、/publicに置いたファイルが更新されてなかったのでハマりまくった。ソースからスクリプトを見てみると、デプロイしたにも関わらず変更されてない箇所があった。

自動アップデートも含め、かなり複雑な手順を踏んでデプロイしているため、正直、何が原因でそうなってるのかの特定が面倒だった。最初はそのコード自体が危険で、あまり順当でないやり方で書いたためビルド段階でコードが排除されたのではないかと考えた。プロテクトやLint関連かなとか思った。デプロイが上手くいってるのにコードが一部消されているというのはそういうことだと思った。

しかし、この予測は間違いだった。調べてみるとローカルではなく、サーバーサイドに問題があることがわかった。で、サーバーはHerokuが提供してるものを使ってるので、Herokuに原因があると考えたが、これも違った。原因は、CloudFlareであり、これはDNSサーバーなどとして使ってるものなんだけど、メンテナンスとやらで更新が不安定であり、それが原因でファイルが更新されてなかったようだった。確かめてみると、確かにHeroku APPのアドレスではちゃんと変更後のファイルが表示されてた。これが最もハマった点だった。

後は、通常の処理やら何やらなんだけど、Mastodonのレイアウトはストリームとページャーが分かれており、それ故、ページャーをストリーム要素の下に置かないと、オートスクロール機能に不便が生じるため、この点を変更したらオートスクロールが使えるようになった。そのままだと2ページ目以降を読み込まない。ただ、これは下記のツイート?でも述べているけど、順当なやり方ではないため、もやもやした。

https://mstdn.syui.cf/@syui/589

次に、jk移動についてもハマったというか、これは上記のやり方自体があまり順当ではなく、本来的にはHTMLのビルド担当部分のソースコード辺りを変更して適切な形にしたほうがいいのだろうけど、しかし、面倒なので単に.paginationを.activity-streamの中に入れることによって解決したためにjk移動についても要素構造が複雑になってしまって難しい感じになった。

具体的には、シンプルに.activity-stream.entryのところを、オートスクロール後は.activity-stream.paginationとか.activity-stream.activity-streamとかが入ってしまって、移動処理が困難を極めた。

これに関しては、a.status__relative-time:firstとかTimeoutとかの組わせで無理やり実現してる感じになった。ページャー間移動(2ページ目、3ページ目の移動)を無視するなら簡単なんだけど、jk移動でオートスクロールを読み込み、なおかつその要素に移動しようとなると、どうしても無理矢理な感じになってしまったので、よくない。

オートスクロールで使ったプラグインに手を入れて、そのあたりスムーズになるように調整できるかもしれないので、やる気があればやるかもしれない。

https://github.com/gilbitron/Infiniscroll

Mastodon本体を変更すれば速いんだけど、しかし、あまり変更しすぎると、今度は自動アップデートが失敗するというか、自分が変更したファイルがきっかけで動かない可能性が高まるので、できる限りユーザー設定ぽいコード以外の箇所は変更したくないなというのはある。

以上