前回のあらすじ：Tailwind は最低限のデザインで構わない自分にとっては Not for me だった - ブラウザ拡張開発日記
Tailwind を無料で使う場合、UI Component ライブラリは無料の 3rd party 製のものを探して選ぶ必要があるわけだけど、品質がまちまちだし、流行り廃れがあるのでせっかく選んだものが後に負債化する、とか考えるのが嫌なので、
— Cside (@Cside_) 2023年11月9日
公式が無料で高品質な UI Component を一通り提供してくれる Bootstrap を未だに使い続けてるわけなのですが、令和に Bootstrap...？ スキルセット的にどうなの...？ みたいなモヤりをずっと抱えつつ使っている...。
— Cside (@Cside_) 2023年11月9日
実装はあらかた終わったが、最後の最後に、買い切りかサブスクかで迷いが生じてしまった。
相談できる同僚もいないので、ここで自分の考えを整理したい。
一見簡単そうに見えるが、パーサーが非常に複雑で、コード行数 5,000 行超えの大作となっている。これだけ手間隙かけて無料はちょっとなぁ、と思い始め、一部の機能を有料で提供する決断をした。
2 つある。
最も悪いケースを考えれば、 「僕が体調不良でコードを書けない期間」と「 Notion の API の（後方互換性を壊す）仕様変更」が同時に起こった場合、その期間はサービスが停止する ことになる。
上記の最悪ケースが起こり、当面の間サービスが停止する緊急事態になった場合。（しかも、いつコードを再び書けるようになるかも見通せない場合）
(1) 既存のサブスク加入ユーザーへの罪悪感 (2) 早く回復しなければ、という焦りが生じる という 2 点から、ただでさえ病気で余裕の無くなっている精神状態にさらに追い打ちをかけることになる 。それはかなり危険言わずとしれたエラー収集サービス。アラートを Slack に流してる。
💡エラーに個人情報が混じってる場合は適切にマスクした上で送信すること。
無料プランだと Slack 連携が使えないので
Sentry の Webhook → Vercel に立てているリクエスト中継アプリ → Slack の Incoming Webhook
みたいな感じで Sentry の Webhook を Slack までリレーしている。
Vercel のリクエスト変換アプリのコードはこんな感じ。(クリックで展開)
const { IncomingWebhook } = require("@slack/webhook"); export async function POST(request) { const params = await request.json(); const webhook = new IncomingWebhook( "YOUR SLACK INCOMING WEBHOOK URL", { icon_url: "YOUR ICON URL", channel: "YOUR SLACK CHANNEL", username: "Sentry", } ); await webhook.send( `${params.event.title}\n${params.url}\n( by ${params.project} )` ); return new Response("OK"); }
リクエスト変換アプリを立てる場所はVercel でなくても、Google Cloud でも AWS でも何でも良いと思う。
バグレポートや機能要望をユーザーが投稿できる SaaS 。
以前までは Github Issues を使っていたが、言わずもがな Github アカウントが必要でユーザーにとって敷居が高かったので、Google などのアカウントでログインできるこちらのサービスに変えた。
決済機能をまるっと請け負ってくれるサービス。（正確にはまだ使っておらず、近々使う予定。）
これを使えば、サーバーを自前で持たなくても、クライアント JS のコードだけで有料機能の実装ができる。
ExtensionPay の内部では Stripe で決済を実行しているので、Stripe のアカウントが必要となる。（審査を通すために Web サイトなどをこしらえるのが割とだるい）
ただ、問題なのは競合サービスが存在しないことで、もし ExtensionPay がサ終した場合、決済のサーバーサイドを自前で用意しなければならないことになる。。サ終に怯えながら使ってる。
どうしたもんかなー。（昔は Google 公式が、拡張機能の決済システムを提供してくれていたらしいのだが、だいぶ昔に廃止されてしまった。復活してくれないかなー。無いか。。）
chrome.tabs.onUpdated の方がいいかも。
ユーザーに対して "ブラウザの履歴" 権限を要求しないのも、ユーザーの心象が良い。
URL が動的に変わった場合、とは要するに pushState された後に何かすることを指す。
window.popstate イベント というのがあるが、これは現在の Chrome などのブラウザでは使えない。
ではどうするか ... というと、chrome.webNavigation API の onHistoryStateUpdated イベントを listen すれば良い。
https://example.com/* でページの URL が変更された場合 *1 に何かするコードの例：
chrome.webNavigation.onHistoryStateUpdated.addListener( detail => { /* 何かする */ }, { url: { urlPrefix: 'https://example.com/'} }, );
このコードは background service worker でしか動かないので、content script でなにかしたい場合は chrome.tabs.sendMessage() で content script にメッセージを投げる。
/* background.ts */ chrome.webNavigation.onHistoryStateUpdated.addListener( detail => chrome.tabs.sendMessage(detail.tabId), { url: { urlPrefix: 'https://example.com/'} }, );
/* content.ts */ chrome.runtime.onMessage.addListener(() => { /* 何かする */ });
この方法の唯一のネックは、ユーザーに webNavigation permission をインストール時に要求することになること。
「おいおい何で history にアクセスできる権限を要求するんだよ！！」とクレームが来たことが１度だけあるので、気にする人は気にするかもしれない。
*1:動的に変わった場合も、初回読み込み時も含む
tsup とは：rollup みたいなバンドルツール。TypeScript で npm パッケージを作るのに特化している。
これを使わないと何が面倒臭いか：
import './foo.js' みたいに import 文に .js を書かないと実行時エラーになってしまう
.js を書かなくても実行時エラーにならないchmod +x しなければならない
GitHub Packagesのクイックスタート - GitHub Docs
Github Packages とは：パッケージをホストおよび管理する Github の機能。npm 互換がある。
ここに Github Actions を使ってパッケージをアップロードすれば、あとは npm パッケージをインストールするのと同じように、 npm install <package name> でそのパッケージを使えるようになる。
他に検討したがボツにしたもの：
npm install https://github.com/Cside/some-package みたいなことをすることGithub Packages にもデメリットは 1 つあり、それは Github の Access Token を含んだ .npmrc を、リポジトリを触る全員が設置しないといけないこと。
これはメンテナにとってはだるそうなので、ここだけ気になるんだよなー。。（どうしようもならなそうだけど）
割と前からあるっぽいが、社会と断絶した生活を送ってるため、昨日知った。。
公式サイトでは下記のように謳っている。
懸念点は触ってみないと何とも言えないので、どっかで腰を据えて触りたい。
