依存を明示するか、抜け道から通すか
しかし、特定のまとまり、featureごとに、外部からの依存をすべて子に渡していくのは重いという感じもある
jotaiとか使って渡すのは楽
抜け道のようにも見えるし、import, exportで依存自体の明示はされている
関数の依存のDI
わりとどこにおいても登場する概念ぽい?
そうだとしたら、何らかの形で問題を構造化するなりして、方向性を定めたり議論が可能な形にしておくとよいのだが
難しい。わからん
依存に必要なものは、エントリポイント、controllerに相当するレイヤーで用意するのが正しい
しかし、その依存アクションの利用が、関数呼び出しツリー or コンポーネントツリーの深いところで利用する場合に、これが面倒
明示的依存だと、経由する全部に記述する羽目になる
暗黙依存だと、asynclocalstorageとか使うが、その魔術を乱用すればglobal state地獄になる
プログラマの技量に左右されてしまう
そもそも、差し込む依存物がactionではなくcalculation or dataで、しかも単一なら、スコープ外から差し込めば良い
actionであり、外部への副作用、effectである場合に、考慮が増える
effectであるから、テスト用にモックしたい or ...
結果、単一でなくなる
asynclocalstorageは、そのstoreが状態であるとつらい
逆に言うと、そのstoreが、一度決まれば固定なものなら、そんなに困らない
logでの利用事例とかはまさにそれだろう
リクエストごとのidなどは、途中で変わるものではない
依存明示のシンタックスの違いがある
goとかはcontextを第一引数に置く、というのがよくある
これってどっちが正しい、というのが決まるようなものでもないな
依存を受け渡す経路が二通りある
props, 引数
import export
状況や意味に応じて使い分けたらいい、という話なのだが
それを理屈で明示できるといい
たとえば、なんらかのボトルネック、インターフェースに相当するところは、引数で明示をしたほうがいいだろう
import exportにした方がいいケースは
それが必要であることが内側から確定している
ファイル移動、並び替え、設計の変更をする、頻繁にする
こういったケースは、引数経由で取り回す場合、その経路の間をすべて引き直す必要が出てくる
なので、ボトルネックで明示的に受け取り
受け取った内容を良い感じに転送する感じで受け渡す、という感じが良さげ
ブレッドボードとジャンプワイヤの空中配線みたいなもんか
なんか作りながら考えてる際は空中配線しまくったほうがいい
どの依存をどこに渡すべきなのかが確定するのは、設計や動作の後だから
arduinoとかで電子工作する際のブレッドボードとジャンプワイヤみたなもの
先に電子回路設計が済むわけではない
これは実際に動かしてみて考える、という帰納的な設計である
対して、
XはAとBのためのもので、Cとは独立すべきだから、
このような依存関係、インターフェースであるべきだ、
的な理屈から考えていく場合は、演繹的な設計と言える