Edge の拡張ストアを利用した感想

Edge にも拡張のストアがあるを割と最近知ったので、Chrome に出してるやつを何点か出してみた。

👍 Good

• Chrome の拡張を、一行もソースを書き換えることなく Edge にもリリースできる
• ストアの素材（スクショ、アイコン等）も Chrome のストアのものと全て同じ大きさなので、Edge のストア用に新たに素材を作る必要もない
• 管理画面の UI は非常によく出来ている
• サポートへの質問メールのレスも、割と早く返ってくるし、丁寧な内容

❌ Bad

• 審査が遅い。遅すぎる
  • 新規ので 10 日くらいかかる（ Chrome/Firefox は 1.5〜3 日）
  • 公開済みの拡張の更新を 5 日前に提出したが、5 日経った今も審査が終わらない

この審査があまりに遅すぎるという１点が、他のメリットを全てぶち壊して、ストアの魅力を大きく毀損してしまってると感じる ... 。

Microsoft さん、もっと審査の人増やしてあげてよぉ。。。

SPA のルーティングはパスとハッシュのどちらが良いか

/dashboard と /#dashboard のどっちが良いか、という話ね。

Using Hashed vs. Non-Hashed URL Paths in Single Page Apps | by Viduni Wickramarachchi | Bits and Pieces

Google はハッシュ以降を削除した URL をインデックスするから、別々のページとして認識させたい場合はハッシュ付きルーティングは止めといた方がいいっぽい。

テストを Jest → Vitest に移行してみて

テストファイルが 15 個あるリポジトリ を Jest → Vitest に移行してみた。

良かった点

• 実行時間が 7.5 秒→ 2.9 秒、半分以下になったのは凄い
• Jest の API と互換性があるので s/jest/vi/g でほぼ動くのは凄い

イマイチな点

• たまに変なバグ踏むことがあり *1、まだ完全に枯れきってない印象
• Jest にはあるが Vitest には無い機能がたまにある
  • jest.replaceProperty()
  • jest.mock(), jest.doMock() の第 3 引数のオプション
  • etc...
• 情報が公式ドキュメント以外にネットにまだ少なく、公式ドキュメントに書いてないことをやりたくなった場合にググっても情報がほぼ無くて詰む
  • これはまぁ時間が解決することではあるが

移行にあたって妥協した点

eslint-plugin-jest から eslint-plugin-vitest への移行は諦め、eslint-plugin-jest を使い続けることにした。

理由：

• eslint-plugin-vitest の仕様がeslint-plugin-jest とかなり異なる
  • eslint-plugin-vitest/recommended が eslint-plugin-jest/recommended よりもだいぶ厳格さが落ちる
  • 同名のルールでも仕様が異なるものが存在する
  • そもそも eslint-plugin-vitest では実装されていないルールが存在する
  • （これらの状態で eslint-plugin-vitest を名乗るなよ ... という気持ちもぶっちゃけある）

総評

• Vitest はまだ完全に枯れてないものの、テストが 2 倍以上高速化したので、移行して総じて良かった
• 今後新しく何か作る場合は Vitest を使うと思う
  • 万が一、途中から Jest にしかないエコシステムを使いたくなって Jest に戻りたくなった場合も s/vi/jest/g に戻せばいいだけである

*1:fake timer を使ってる場合に useEffect が発火しない、というバグを踏んだ

React の状態管理ツールをひととおり触った所感

「たったこれだけで "ひととおり" って言うな！」というツッコミは甘んじて受けます。

触ったもの

useReducer + useContext

• 👍 React 本体の知識だけで使える
• ❌ reducer に非同期処理を書けない
• ❌ Context が増えてきたら非常に読みづらくなる
• ❌ 結果的に劣化 Redux ができがちなので、よっぽど小規模でない限りわざわざ採用するメリットは無い

Redux Toolkit

• 👍 素 Redux と比べてボイラープレートコードは減った
• ❌ 非同期処理の絡むコードは必ずしも読みやすくない（私見）
  • 非同期の処理は extraReducers という所に分けて書かないといけないところとか。あと builder.addCase() とか読みやすいか ... ？

Recoil / Jotai *1

• 👍 非同期処理の絡む state の更新処理を、非同期処理の開始と終了で分断することなく１つの関数の中に書けるので、個人的には一番読みやすいし書きやすい
• ❌ まだ Redux ほど市民権は得てない認識なので、自分以外の人が触るリポジトリに導入するのは若干まだ躊躇いがある
  • とはいえ見た目はほぼ useState なので学習コストは知れているが

結論

• 自分は Recoil / Jotai が好み。

*1:Jotai ... Recoil と概念は同じ。より API がシンプル https://jotai.org/

Tailwind は最低限のデザインで構わない自分にとっては Not for me だった

前提：私の目的は「デザインは最低限見た目が整ってればいいから、とにかくかける工数を最小にしたい」

• Tailwind 、Bootstrap みたいなもんだと思って入門してみたら全く非なるものだった。両者は役割がぜんぜん違う
  • Tailwind の役割：デザインシステムを自分で組むための下地みたいな役割
  • Bootstrap の役割：デザインを全て Bootstrap に委ねるもの
• Bootstrap は読み込むだけでそれっぽいデザインにしてくれるけど Tailwind はそういうのが全く無い
  • むしろほぼ全部のスタイルがリセットされるので、例えば h1, h2, h3 とかのフォントサイズとかを全部ゼロから決めていかなければならない
  • Tailwind UI とか DaisyUI みたいな UI 集はあるけれど、それらは UI パーツの見た目は整えてくれるが、それ以外の、例えば諸々の文字サイズや余白などを全部自分で決めなきゃいけないという問題は解決しない（そりゃそう）
• 一方 Bootstrap は、bootstrap.css を読み込めば全部それっぽい見た目に整えてくれることが強み
  • なので自分で当てなきゃいけないスタイルがほとんど無い
  • ゆえに「 Bootstrap 感 丸出しで構わない」自分にとっては、Bootstrap のほうが低工数でマークアップできる
  • 出来合いの UI パーツが公式で無料で提供されており *1 、種類も最低限で選択に悩まなくていいのも良い
    • つまり、自分は別にデザインのカスタマイズ性は求めていない

なので、世間的には Tailwind アゲの流れだけど、個人開発で使うぶんにはまだ Bootstrap だなー、と思ったのであった。

*1:Tailwind の公式 UI パーツ集はほぼ有料