00:03
みなさんこんにちは。雨宿りとWEBの小噺へようこそ。
ポッドキャスト配信者のkeethこと桑原です。
この番組は、日々降り注ぐ情報の中で、ちょっと雨宿りしながら、
様々なWEBテクノロジーの成り立ちや裏話を小噺としてお届けする番組です。
Zeduxの初期開発
今回の話題は、状態管理ライブラリーZeduxのブログを読んだお話をしようかなと思います。
前回の配信の続きというか、繋がりのお話です。
前回、ちょこっとだけZeduxというライブラリーを紹介したんですけど、
こちらがどういう思想とかフィロソフィーのもとに開発されたのかなっていうのが気になりまして、
これのブログが公開されていたので読んでみました。
Zeduxなんですけど、ダウンロード数を比較しますと、
リコイルとか状態、チュースタンド、状態管理ライブラリーいくつかあるんですけど、
これらのものと比較しますと正直桁が2つぐらい小さいんですね。
余談にはなるんですけど、このライブラリーの公式サイト、概要欄にもリンクを貼せておきますけど、
デザインは本当に素晴らしくてイケてるなっていう、まさにモダンなデザインだなと。
ファーストレンダリングがものすごい遅くてですね、がっつり最初レイアウト崩れするんですよ。
それを見てから触っていくので、ちょっと体験的にはもったいないなというふうに感じます。
ここはそんなに労力をかけないふうに中の人は倒したんでしょうねと思いました。
またリポジトリ見たんですけど、一応コントリビューターは5名いらっしゃいます。
そのうち4名はコントリビューターと言いながらワンコミットだったんですね。
これマスターブランチですね。
で、見たらそうだったので、事実上一人プロジェクト。
そのメインコミッターの人がバウハートさん。
読み方合ってるかちょっとわかんないですけど、この配信中はバウハートと呼ばせていただきます。
もちろん今日読んできたブログもその方が書かれていて、
先ほど言いましたメインブランチがマスターなので、このあたりもこのプロジェクトが実は長いことっていうのは物語っているなと思います。
しかもこのリポジトリもですね、今はオムニスタックっていうオーガナイゼーションの下に生えてるんですけど、
元々はこのバウハートさんの個人アカウントの下にリポジトリが生えていたと。
はい、今回の配信のためにブログ4本公開されています。公式サイトに。
いずれもですね、2023年に公開されたもので、それ以降は実は更新なかったんですね。
ただ開発次第は今も継続されていて、
つい最近だとアトムに関する機能改善のコミットが2週間前くらいに投げられたりとか、
バージョン2.0.0のβ0のリリースも2週間前にやられていたというので、絶賛開発は進んでいるよというところです。
さておき、ここから本題に入っていきたいと思いますけど、1本目。
Zilux Open Sourced and V1 Releasedというタイトルのブログです。
このブログはですね、2023年4月24日に公開されていて、
この日はですね、バージョン1.0.0もリリースになった日になります。
誕生の歴史についてこのブログでは書かれていて、
何やら論争があったんですかね。わかんないですけど、そういうふうなことが書かれていて、
2本目の記事がそれのフォローアップのものだそうです。
Fischerはもともと React を使って開発をされていて、今もそうなんでしょうね。
開発する中で独自のステートライブラリを作りたくなって、実際に作り始めたらしいです。
理由なんかいらないですし、開発者を作ればいいと思ってますね、僕は。
個人プロジェクトですし。というので、面白そうだなと思いました。
理由わかんないといったのは、既存のツールに不満は特になくて、
むしろどう動いているのかというのが気になって、
長い時間をかけて分解をしていったということだそうです。
Flex っていう概念が昔もあったんですけど、
こちらにインスパイアされて、コンポーザブルストアモデルのアイディアが彼の中に浮かびましたと。
そこから数ヶ月間かけてプロトタイプを作って、いろいろ微調整を繰り返して完成させていったと。
ここでいうコンポーザブルストアモデルっていうのは、
いわゆるその状態とかそれに関連するロジックっていうのを関数としてて、
その関数がいわゆるこのコンポーザブルと言われているもので、
あとはそのリアクティブな状態管理とか、
アプリケーションの状態をなるべく小さな、そして独立したモジュールに分解したなどなど、
このようなアプローチをしたモデルを持っていただければ多分合っていると思います。
また名前のZのところですけど、Zはゼロコンフィグっていうことを意味していて、
それを目指して作っていたってことがそうですね。
実際クールな行動には一応仕上がったらしいんですけど、
一つ大きい問題が発生したんですね。
思ったほど便利にならなかったっていうふうに書かれていました。
それはちょっと語弊があるかもしれないし、誤解を招きそうなんで補足されてたんですけど、
当時世の中にあったその他の状態管理のツールと同等の利便性はあったというふうには自負されていた。
ただ、利便性はあったけど特に目立つほどでもなかった。
要は状態管理ライブラリはいろいろあったんですけど、
その中のゲームチェンジャーとかトップを走るみたいなものにはなれなかった。
開発者のバウハートさんは正直モチベーションなくなってしまって一回置いてしまった。
開発の停滞と再評価
まあまあこれもよくある話だと思います。
実際に本気で作っていって、自分の中で満足して、自分自身がそれを書けばいいかもしれないですけど、
意外とそうはならなかったっていう現実があると、
モチベーションなくなっちゃう方っていうのも話は効くなって感じでした。
2018年から約2年間、他の状態管理ツールっていうのを使いながら仕事をしていたらしくて、
でかいプロジェクトや不安定な状態のプロジェクトなど、
いろんな厳しい状況と言われるプロジェクトの場合に、
何が不十分と感じるポイントなのかっていうのを裏でメモしていたらしいですね。
そこで分かってきたことが、結構私たちっていうのはツールに多くのものを求めるようになってきたと。
その結果、セレクターがどんどん遅くなってしまったとか、
あとは副作用がそこら中に乱立してしまったとか、
あとはよりスケーラブルなものが欲しいというニーズが出てきたりなどなど。
あとはアトミックモデルとサーバーキャッシュ管理ツールっていうのが、
弊社の方は気に入っていて、いくつかのツールを徹底的にテストしていったらしいです。
その中で、ソケット駆動でかつ非常に揮発性の高いアプリケーションのニーズを満たすのに、
十分に安定性とパワーを備えたものが今の世の中にはないなというふうに結論に達したらしいですね。
Zeduxのオープンソース化
一度置いていたZedaxに再注目をしたと。
ここからZedaxの復活劇が始まるらしくて、
以前のコンポーザブルストアモデルっていうものがあったんですけど、
これに足りなかったのがアトミックモデルだったというふうに気づいたと。
そこからまた3ヶ月間を費やして、アトミックアーキテクチャっていうのをZedaxに構築をしていって、
状態管理レイヤー、いわゆるストアとアーキテクチャレイヤー、これがAtomですね。
こちらを分離することで、どのフラックスベースのアプリケーションでも見たことがない、
こんなような強力なDIです。
Dependency Injection、DIとストア間通信を実現する。
ここまで来ると、本当映画を見ているような感覚になりますね。
単純に一つの状態管理ライブラリーの誕生の裏話を聞いているだけなんですけど。
結果、2021年初頭にはBauhardさんの会社の全てのアプリケーションがZedaxを動かすようになったと。
まさに大成功したというふうに本人もおっしゃっていて、これはもうおめでとうという気持ちになります。
僕も小さいながらライブラリーを作って公開したことがあるので、すごく感動したんだろうなと思います。
新しいライブラリーのオープンソース化の許可も得たと。
これ多分会社内でそもそもスタートしてるっぽいので、Zedaxプロジェクト自体も会社のものだったんじゃないですかね。
オープンソース化のところで許可を得たんでしょうと。
ここから数回のAPIの反復と膨大なドキュメントをして、
そして私たちは2023年4月24日、満を持して発表したと。
この日についでにオープンソース化にもなったということですね。
バージョン1.0.0が公開になったということです。
素晴らしい。
細かいディテールとかに踏み込んだり、他のツールに泥を塗ることをこのブログで期待していた。
煽りとか自分たちの優位性を語ってくれるんだろうというふうに期待して読まれていたのであれば、
この2本目の記事ですね。フォローアップの記事ですけど。
こちらにたくさん書いてあるので、ぜひ見てみてください。
Zedax Is This The Oneって言ってます。
これが2本目のブログです。
こっちのほうがどっちかと肝となるような記事っぽかったなって今読んでて思いました。
最初に簡単なHello Worldのコードを書いてあったので見たんですけど、
いわゆるAtomというメソッドがあって、こちらで状態管理のオブジェクト、Atomを作って、
UseStateのようにUseAtomStateというメソッドがあるのでそちらをインポートしておいて、
これを使うと先ほど言った通りUseStateのように変数とセッターが返されて、
これを使って状態管理をしましょうと。
とてもシンプルですね。分かりやすいです。
ZedaxっていうのはDI駆動のアトミックアーキテクチャに包まれたコンポーザブルストアモデルの特徴としている。
元々は以前Reduxを使っていたらしくて、
このReduxのソケットドリブンアプリのパフォーマンスとメンテナンスの問題を解決するために作っていったっていうのは
一番最初の発端だったらしいですね。
弊社の方の会社が作っているアプリケーションがまさに同期的なソケット通信を求めるアプリケーションというところで、
思想としてはそうなんだろうなと思いました。
その話を聞くと、前回の中でも言ってたRXのサポートが手厚いって言った理由もそうだよねっていうのは分かりますよね。
バウハードさん、本当にReduxが大好きなんだなっていうふうに感じますというか、
めっちゃブログ内で豪語してるんですけど。
好きな理由としては一方向のデータフローとか、
あと普遍性というものが与えてくれる安心感がたまらないらしくて、
これは僕も結構共感しますね。
データをどう管理するかってすごく複雑で、
とにかくちゃんとルールを決めなかったりすると、
一気に僕らはカオスに走り倒しますからね。
本当にいいなと思いました。
本ブログ、2本目の記事では、不本意ではあるんですけど、
Zeduxの基本概念
差別化もやはりいるでしょうというところで、
企画をしていこうと思っています。
一つ目に、遭遇した問題から入りましょうっていう話から入っていて、
昔はバウハードさんのプロジェクトでは、
ReSelectっていうライブラリー。
これはメモ化されたセレクター関数を作るためのライブラリーで、
Reduxツールキットを使ったことある方は、
最初からこれに組み込まれています。標準で。
そういうやつですね。
そのReSelectのパフォーマンスだったり、
昔Redux使っていた人はRedux Sagaにお世話になった方も
結構いるんじゃないですか。
僕もお世話になりましたね。
このRedux Sagaのいろんな問題ホゲホゲがうんざりしたと。
あとは、Reduxの一般的な非干渉性のところですね。
この辺がバウハードさんのチームだと、
セレクターの制御ができなかったり、
最大のパフォーマンスのボトルネックというふうに判断になったと。
これをReduxのAtomicモデルが自然に解決してくれるよというふうに書いていて、
これちょっとコード見たんですけど、
口で喋ってもイメージしづらいので、
ざっくりとお話しますけど、
データのツリーと派生データというのが結構集中的になってくると、
いわゆるツリーの途中にあるセレクターっていうのを、
彼のチームでリセレクトを使ってたんですけど、
こちらで、例えばデバウンスとかスロットル、
パッファーみたいなところを更新させることはできないらしいです。
ちょっと僕はこれを触ったことないんでわからないんですけど。
これをReduxだと、
ツリーの任意の場所のセレクターをAtomicに変えることができるんですって。
これすごいですよね。
それができると、確かに問題なく更新できたりするし、
コントローラブルになるなっていうので、これいいなと思いました。
あとはインジェクトエフェクト、いわゆるインジェクターのことですね。
Zenuxにおけるインジェクターがインジェクトエフェクトっていう関数があって、
これユーズエフェクトとほぼ同じような動作をするもんですね。
ただこれはAtomのための作りに裏っかではなってて、
リアクトの世界でステートとその副作用、エフェクトです。
これをコロケーションすることができるようになるんですね。
Zenuxのインジェクトエフェクトを使えばそれができるようになる。
これなかなか厚いお話だったなと思います。
確か今までできなかった?
無理やりやろうと思ったらできる気がしますけど。
これを自然とサクッとできるようになるっていうのはかなり厚いなと思いました。
これ結構大きな優位性というか差別化だったな。
あといろいろ差別化たくさん書いてあったんですけど、
もう一つやっぱり気になったのはキャッシュマネジメントのところです。
こちらまた別のツールでリアクトクエリっていうのがあります。
今は単スタッククエリになりましたね。
これも大好きだったらしいですね、バウハードさんは。
なんですけどやっぱりバウハードさんのチームにとっても
リアクトクエリはいくつかやっぱり欠点が出てしまって、
それについては本記事に書かれているので見てみてください。
その中ですね、一点だけキャッシュ管理のアイディア自体はとても気に入っていて、
こちらを参考にAtomにプロミスの状態を管理する機能っていうのを持たせていて、
こうすることでリアクトクエリ的なパワーを得ることができましたと。
さらにインジェクターを組み合わせると、
インジェクターってさっきのインジェクターエフェクトですね。
こちらを組み合わせるとリアクトクエリでできる全てをサポートできるような世界観が見えてくるよっていうふうに書いてました。
これまだ今できてないんでしょうけど、今後そういうことはできそうなっていうことだそうですね。
まあ聞けば確かにですね、コントロールできる範囲もさらに細かさも加わってきて、
すごいなと思いますね。
それでいて、そもそもAtomなんで、それが疎結合ですよね。
さらに必要最小限にUIの状態管理もできるっていうのは、もともとAtomなんでそうだよというので、
かなりパワフルなライブラリだなって感じましたね。
インジェクトエフェクトの重要性
他にも技術的な際についていくつかわーっと記事書かれてたんですけど、
趣旨とずれるのと、正直ですね、読んでて僕自身がついていけなかったんですね。
諦めましたので興味ある人は読んでみてください。
特に3本目4本目の記事も大体テックの話だったなっていうので今回は割愛しました。
そんなことで誕生秘話について書かれていましたけど、いかがでしたかね。
いろんなツールとかの差別化を比較をしながらお話がされてたんですけど、
本当にZedaxに対する思いと強さっていうのを改めて強く感じた。
いいブログだったなと思います。
じゃあそろそろ長くなってきましたので今回もここでエンディングにしたいと思います。
最後なんですけど、このブログからとても素晴らしいことをおっしゃっていたので、
その言葉をお借りして締めにしようかなと思います。
素晴らしいツールっていうかライブラリが登場したら、
我々は意見の相違というものを脇に置いて便利になったってことを称賛するようになるでしょう。
またそういうふうに信じています。
ただそれは違いそのものを否定することにもなってしまいますと。
ライブラリ同士、もちろん違いがあって当然で、
お互いの違いっていうのは我々にいろんなことを教えてくれてるよっていうふうにおっしゃっていて、
否定することは別に傷つけるのはあれですけど、
否定することそのものは別に素晴らしいことだよって書かれてました。
ただ違うライブラリにも思想とかフィロソフィーがあるので、
そこはライブラリに親切にしていってくださいねっていうふうに一つだけお願いをしようというふうに書いてますね。
で、ゼダックスももちろん銀の弾丸ではないですし、特効薬でもないんですけど、
本ブログをここまで読んでいただけたんであれば、
もしかするとあなたが待ち望んでいたステートマネージャーである可能性っていうのは十分にあるよと。
まあいずれにせよ、本当の問題、真の問題とは何を使うのではなく、
それを使って何を作るかだっていうふうに締められていました。
ツール選定の哲学
いやーほんと締め素晴らしいですね。
二重通写の鏡のようなお言葉で締められていて、
反動した深夜1時40分です。
システムとかアプリケーションの肝っていうのは、
データとアルゴリズムに尽きるなってずっと思っていて、
ただそのシステムとかアプリケーションはあくまで手段やツールでしかなくて、
解決したい課題とか実現したい世界のために、
我々はツールを選ぶことっていうのは変わらないですと。
そういうことを改めて意識させられるなっていうブログでもあったと思います。
私はIoT.jsユーザーですので、
スタンドアローンに動くものを探しています。
リアクト以外で使えるものを探していたので、
今回Zedax見ていったんですけど、
もちろんもともとリアクトをベースに作られているライブラリーですので、
Zedaxスラッシュリアクトでインストールできるんですけど、
リラックスコアもありますからね。
それはスタンドアローンで動くので、そっちを使おうかなと思います。
とても興味が湧いたライブラリーですので、
ちょっと触ってみようかなと思います。
というところで、皆さんでも興味があれば触ってみてください。
ではでは、この番組面白かったよという方は、
ぜひチャンネル登録もお願いします。
もし聞いていて気になることや話してほしいトピック、感想などございましたら、
概要欄のフォームやXでハッシュタグ、
ウェーブ小話でつぶやいてください。
ウェーブはアルファベット、
小話は漢字でもひらはなでも大丈夫です。
それではまた、雨宿りしに来てください。
今回もお聞きくださりありがとうございました。
雨宿りとウェーブの小話、お相手はKeithでした。
さよなら。
