Zedux のブログを読んできた

本家サイトのぶログ https://omnistac.github.io/zedux/blog

台本

皆さんこんにちは。「雨宿りと WEB の小噺」へようこそ!ポッドキャスト配信者の Keeth こと桑原です。

この番組は,日々降り注ぐ情報の中でちょっと雨宿りしながら、様々な Web テクノロジーの成り立ちや裏話を小噺としてお届けする番組です.

今回の話題は「状態管理ライブラリ zedux のブログを読んだ話」について.

本題

  • 前回の続きというか,つながりの話
  • ちょこっとだけ zedux というライブラリを紹介したが,どういう思想やフィロソフィーのもとに開発されたのかが気になったので,これのブログが公開されていたので読んでみた
    • ダウンロード数は recoil, jotai, zustand とは桁がいくつも小さい
    • 余談だが,このライブラリの公式サイト,デザインはイケているのに,TOP ページのレンダリングが遅く,ガッツリレイアウト崩れを見せられてからスタートするのものすごい勿体ない…
  • リポジトリ
    • 5 人のコントリビューターいるが,4 人は 1commit で,事実上一人プロジェクト(bowheart さん)
    • もちろん本ブログもその方が書いている
    • メインブランチが master なので,そのあたりもこのプロジェクトが長いことを物語っていますね
    • 元々は bowheart さんの個人リポジトリだったが,後ほど今の
  • ブログは合計4本
    • いずれも 2023 年に公開されたもので,それ以降はサイトにはなかった
    • ただ,開発は今も継続されていて,atom に関する feat(機能改善) の PR が 2 週間前くらいに投げられたり,v2.0.0-beta.0 も 2 週間前に公開されていたりする
  • 1本目 Zedux Open-Sourced and v1 Released
    • https://omnistac.github.io/zedux/blog/2023/04/24/zedux-open-sourced
    • 2023/4/24 1.0.0 のリリース
    • 誕生の歴史について
      • 何やら論争もあったらしく,2 本目の記事がフォローアップのものだそう
    • 筆者は元々 react を使って開発していたが,なぜかわからないが独自のステートライブラリを作り始めたらしい w
      • 理由なんかいらない.開発者は作りたければ作れば良い.個人プロジェクトなんだし
      • 既存のツールに不満はなく,むしろどう動いているのか,長い時間を書けて分解していた
    • FLUX にインスパイアされたコンポーザブルストアモデルのアイデアが浮かぶ
      • そっから数カ月かけてプロトタイプを作って微調整を繰り返したらしい
      • ここでいう composable store model とは,
        • 状態とそれに関連するロジックを関数(Composable)として定義
        • リアクティブな状態管理
        • アプリケーションの状態を小さな、独立したモジュールに分割
        • などのアプローチだと思われ
      • 名前の Zzero-config のことを意味する
    • クールなコードに仕上がったが1つの問題があった
      • 思ったほど便利ではなかったらしい
      • ただ,当時世の中にあったその他のツールと同等の利便性はあったが,目立つほどでもなかった
      • ようはゲームチェンジャーにはなれなく,bowheart さんもモチベがなくなった
        • あるある
    • 2018 年から 2 年,他の状態管理ツールを使いながら仕事をする中,デカいプロジェクトや不安定な状態のプロジェクトなど,厳しい状況の場合に何が不十分と感じるポイントなのかをメモ
      • 我々はツールに多くを求める
      • セレクタが遅くなる,副作用が乱立するなど
      • よりスケーラブルなものを求める
      • アトミック・モデルとサーバー・キャッシュ管理ツールが気に入る
        • いくつかのツールを徹底的にテスト
        • ソケット駆動で非常に揮発性の高いアプリケーションのニーズを満たすのに十分な安定性とパワーを備えたものはないという結論に達した
      • なんか偶然の出来事が起きて,zedux に再注目
    • zedux 復活
      • 以前の composable store model に足りないものが atomic model
      • 3 ヶ月を費やし,atomic architecture を zedux に構築
      • 状態管理レイヤー(ストア)とアーキテクチャレイヤー(アトム)を分離することで、どのフラックスベースのアプリも見たことがないような強力な DI とストア間通信を実現できることがわかった
        • (ここまで来ると,一つの映画を見るような感覚に陥る)
        • 結果,2021 年初頭には bowheart さんの会社のすべてのアプリを動かすようになった(大成功おめでとうの気持ちになる)
      • 新しいライブラリのオープンソース化の許可も得た.(おそらく会社内のプロジェクトだったからかな?)
        • 数回の API の反復と膨大なドキュメントの執筆を経て、私たちは 2023 年 4 月 24 日,満を持して発表,オープンソース化することになった
    • 細かいディテールにまで踏み込んで、他のツールに泥を塗ることを期待していたのなら、もっと長いフォローアップ記事(2本めのやつ)「Zedux: Is this the one? 」を見てほしい.この歴史レッスンを最後まで読んでくれたなら、脱帽だ
  • 2本目 Zedux: Is this the one?
    • https://omnistac.github.io/zedux/blog/2023/04/24/zedux-is-this-the-one
    • ある意味これが肝っぽい
    • 簡単な hello world のコード
      • atom メソッドで atom を作成し,useState のように,useAtomState メソッドで,変数とセッターが返され,それを使って状態管理をする
      • Zedux は、DI 駆動のアトミック・アーキテクチャに包まれたコンポーザブル・ストアモデルを特徴としている,という記述がなんとなく理解できる
    • なるほど,元々は,以前 Redux を使っていたソケット・ドリブン・アプリのパフォーマンスとメンテナンスの問題を解決するためだった
    • bowheart さん,本当に Redux が大好きなんだな(メッチャブログ内で豪語してた)
      • 一方向のデータフローと,不変性が与えてくれる安心感がたまらないらしい(割とこれは自分も共感)
      • なので不本意ではあるが差別化もいるので比較する
    • 遭遇した問題
      • reselect(というライブラリ.メモ化された selector 関数を作るためのライブラリ.redux/toolkit には標準で組み込まれているやつ)のパフォーマンス,redux saga の hogehoge.そして,redux の一般的な非干渉性.
      • bowheart さんのチームでは,セレクタの制御ができないことが,redux の最大のパフォーマンスのボトルネックになったらしい
      • これを zedux のアトミックモデルがこの問題を自然に解決する
      • コードを口で喋っても難しいので,ざっくり話すが,データのツリーと派生データが集中的になると、ツリーの途中にあるセレクタを Reselect でデバウンス/スロットル/バッファの更新をさせることはできないらしい(自分は触ったことない)。これを Zedux では、ツリーの任意の場所にあるセレクタをアトムに変えることができるらしく,それができるなら問題ないね
      • injectEffect(zedux のインジェクター)は useEffect と同じように動作するが,atom のための作りになっていて,
      • React の世界で,ステートとその副作用を接続することができる(zedux の injectEffect を利用)
      • これは熱いのでは?
    • キャッシュ・マネジメント
      • react query も大好きだったらしい
        • が,bowheart さんのチームにとっての欠点がいくつもあった
        • その中,キャッシュ管理のアイデアが気に入っており,それを参考に,atom にプロミスの状態を管理する機能を持たせることで react query 的なパワーを得たとな
        • さらにインジェクターを組み合わせると,react query できるすべてをサポートする可能性もあるらしい
          • まぁ聞けば確かにコントロールできる範囲も細かさも大きい.それでいてそもそも atom なので疎結合で,必要最小限に UI の状態管理ができる
    • 他にも技術的な差異についてお話はあったが,この番組の趣旨とずれること,桑原自信もついていけなかったこと()から諦めましたので,皆さんの方で読んでください
      • 3,4 本目の記事も同様です

エンディング

さて、そろそろ今回もお時間になりましたのでエンディングです.

  • 最後にいいことを仰っていた
    • すばらしいツールが登場したら,意見の相違を脇において便利になったことを称賛するだろう
    • ただそれは,違いを否定することになる
    • ライブラリ同士,互いの違いは我々に多くのことを教えてくれている
    • 批評することは素晴らしいこと
    • だから,違うライブラリにも親切にしてほしい
  • zedux ももちろん銀の弾丸ではないし,特効薬でもないが,このブログをここまで読んだのなら,もしかしたら貴方が待ち望んでいたステートマネージャーである可能性は十分にある
  • いずれにせよ,本当の問題は,それを使って何を作るかだ.
  • もう本当締めが素晴らしく,技術者の鏡のようなお言葉で湿られて感動した
  • 何度も言っているが,システムやアプリの肝は「データ」と「アルゴリズム」に尽きる
  • ただシステムやアプリは手段やツールであり,解決したい課題,実現したい世界のために我々はツールを選ぶことは変わらない,ということを改めて意識させられる素晴らしいブログだったなと
  • 自分は riot.js ユーザーなので,スタンドアローンに(react 以外でも使える)物を探していたので,とても興味が湧いたたので zedux でもう少し遊んでみようと思う

この番組面白かったよーという方は,ぜひチャンネル登録もお願いします.もし聴いていて気になることや、話してほしいトピック,感想などありましたら、概要欄のフォームや,𝕏 でハッシュタグ「WEB 小噺」でつぶやいてください!web はアルファベット,「小噺」は漢字でもひらがなでも大丈夫です!

それでは、また雨宿りしに来てください。今回もお聴きくださりありがとうございました!「雨宿りと WEB の小噺」お相手は Keeth でした。さようなら!

results matching ""

    No results matching ""