202306のブックマーク
これ、 useEffect(() => { ... }, []) ってかんじの呼び出し方にしか言及がなくて、変数の監視について言及してないから片手落ち感はあったなあ
stateでもpropsでもよいんだけど、再度レンダリングが必要になる値の変更が走った場合に副作用（effect）をかけるよ〜〜ってのがuseEffectの正しい説明なのでは？と思ったりはしている（けど周囲に触れ回るほど自信はできてない） useEffect(() => { someStore.subscribe(); return () => someStore.unsubscribe() }, [someStore.state]) みたいな監視は上記ケースにハマる（けどReact v18だと useSyncExternalStore() にしてくれ〜〜って方向になってるけど）
useEffect(async () => { const bookmarks = await fetch('/bookmarks'); setBookmarks(bookmarks); }, []) みたいにmount時にデータを取得するだけ、みたいな初期化処理もそうね
たとえば検索クエリによってeffectの結果が変わるならstateないしpropsを監視して再レンダリング時に読み直すけど、そうじゃなければ不要でしょ？みたいなお話
一方でcomponent内にあるUIパーツとかで発生し得るeventは各々想定した上でhandlerを立てて処理する、みたいな区分け感
（これ、ほぼ #初稿 なのでページに書き直したいわね......😇） Functional Componentは関数として冪等に評価された後にレンダリングされるものなので、propsとかstateとかeffectとかの依存が変化して再評価が必要なときにunmountされてmountされ直す的な感覚なのよねおそらく
厳密な振る舞いはこれ書いた20230614時点では知らないんだけど、感覚としてはそんなかんじで再評価をするコンテンツをmount時にsubscribeしている的な実装コンセプトかな？と思ったりしてる（hooksなどの概念も含めて考えると） 読みたいけどなんか読みにくいな......
これ覚えておこう......
コメントでされているrefを受け付けるか否かのお話、コンポーネントライブラリみたいに公開する場合はそうかもしれないけど、refを注入されたくないケースとかあるのかな......？（refを注入されることを想定しちゃダメなケースがあまり思い浮かばなかった）
いま最もほしい情報だったこれ
毎回忘れるのよね〜〜 cat package.json | jq -r ".dependencies | keys[]" | tr '\d' ' ' でdependency packagesをspace繋ぎで拾うやつ
これは window.matchMedia(mediaQuery) のようにmediaQueryという引数をもらう話なので、 window.innerWidth のような変化する値を観測する場合は何かしらのstoreをwrapしたいのだけど......
jotaiとかに window.innerWidth を打ち込めば実現できるかもなあ あんまり使うシーンがイメージできてない......どっかで理解したい
Reactのmemo機能って不用意に常用するとメモリ効率悪そう......みたいに思ったけど、多くの場合では再レンダリングする方がコスパよいかも的なお話になってたのは納得感あった
まあそもそも再利用して効率よいケースって限られるからオプトインするくらいがちょうどよさそう
サーバーサイドにおけるデータキャッシュでも闇雲に使うと危うく、正しい用法・用量が必要なので
何だったのか？というか現在（2016年ないし2019年当時）に存在するフレームワークで表現するにはRxですら煩雑じゃん？ってお話なのかなあこれ Rxってめちゃ汎用的でObservableな構造に当てはめられる値ならなんでも監視可能である、ってかんじだと思うけど、そのためにリクエストをObservableにしてレスポンスをObservableにして双方をそれぞれsubscribeして〜〜っての流れは双方向性はあれど面倒なのかもねえ、みたいな気持ちはわかる そう考えるとReactのFunctional Componentとかは基本的に単方向（props/stateからレンダリングするだけ）なのでシンプルだし、逆方向は自分でeventでもstreamでもよいから監視してくれ〜〜ってなる程度なので全ての構成要素が監視し合う構造じゃなくたってよくなったし、それ普及してくれれば余計な複雑さに出会う機会は減るかもな......と思ってくださるかもしれないな、なんて思ったりはした まあでもpropsが変わったことをどう検知するの？となると、Functional Componentも何かしらの依存している値が監視された結果によって再レンダリングが走りますねえ
ReactのFunctional Componentはhooksを用いてstateに依存させてね！ってかんじなので、それに則ってサクッと監視し合う構造が作れるようにしておけば楽だとは思いますよね（たぶんReact向けにリアクティブさを実現するパッケージだと整備されてそうだし、そういう再利用で楽はできそう） ちなみにpropsはFunctional Componentの外から渡される引数でしかないので、決まった値が渡ってくるだけで監視する責務はないね〜〜みたいな前提だと思っています
あと、Rxのようにstateを一元化してpublishしておき各所でそれをsubscribeする構造にすることが、データの不整合さを取り除く（というかstateを管理する側で不整合になる更新にも適切に振る舞うことで正しく保つ）という意味でも重要さはあるんだけど、そこまでしなくてもよい場合も多々あるのでね......
そう考えるとuseState（というかReact hooks）は非常にカジュアルに扱えて便利よ...... 元ネタも一応読まなくては......と思って読んでた
あと「Elmすごいね」って言及してるくらいだし、こういうパラダイムをシュッと書くためのプログラミング言語の適性ってのはたしかにあるよね〜〜そうよね〜〜〜みたいなことよねたぶん 前提として関数というものは、たとえば$ f(x) = yのような式（$ f:x \rightarrow yという写像とも言える）に$ x \in Xのような集合$ Xに含まれる値が入力されれば$ y \in Yのような集合$ Yに含まれる一意の値が返るように対応している（＝全域関数である）場合もあるし、そうならない（＝部分関数である）場合もある
つまり、部分関数は集合$ Xの中でも返せない域（＝未定域）が存在している状態にある関数である、ということ
じゃあ未定域を確定させるためにはどうすれば？？というと、そんな術はなくて確定しないから関数の処理は停止しないんですよね（不停止性）
まあ不停止性/停止性の細かいお話はほぼ何も読んでないので割愛しますが、Promiseを待つ状態がなんとなく未定域な$ x（つまり$ f(x) = \botになってしまってる状態）っぽかったな......という感覚のお話でした
部分関数というか、副作用で確定する$ f(x)みたいな関数だね！みたいな感覚
FRPという概念の存在意義を理解する上で、以下がよい言及だった
RPにおいて副作用を持つ関数は依存関係を見た上で、特別扱いしなければならないのです。理想を言えば、外に追い出せばいいですよね、と言う訳で、副作用と作用を厳密に切り分けられる、FPの出番になります。
これ翻訳記事なのもあって表現も含めわかりづらいんですけど、最後にあるbehaviorに関する言及は少し参考になるかもしれないな......と思ったけど、やっぱよくわからん
表示的意味論を使って、改めてbehaviorとは何か考えてみたところ、すぐに次のように理解することができました。 すなわち、命令型で計算すると時間的に離散するというbehaviorの性質とは、 behaviorそのものを表すというよりむしろ、あるスタイルをもった 機械(machine) に対する調和を意味する、ということです。 私は、“（連続した）時間を表す機能”という表現がもっともシンプルで正確にbehaviorを言い表していると思います。
まあbehaviorを手続き的に各所に書くと連続的に書けない（＝離散的になる）ので、リアクティブプログラミングという概念を用いれば連続して書けるし、それが連続した時間のようなものである本来のbehaviorの姿を表現したプログラムになる、みたいなことなのかな
で、副作用を排除してある関数プログラミングと組み合わせれば、時間とともに変化する値を購読したままに関数に流して利用できて便利〜〜ってことなんだろうなあ
そう考えると2023年現在に存在する各種ライブラリは、当時に比べれば格段に扱いやすくなっていってるからありがてえ〜〜となるねえ 「なるほどな〜〜」と思いつつ、これがベストなのか......？と思うと微妙な表情になるのだけど、少なくとも現時点におけるベターな選択肢のひとつではある気はした
Result型の中身を見ると「200 OKで応答して処理結果をdata内に含めるAPIレスポンスっぽい」感覚になったので、UsecaseというAPIを書いてるわね〜〜とは思った となると二度手間的ではあるんだけど、そもそもクライアントとサーバーを分けてる構成なら各々で構えておくのは当然やんな......その考え方モノリシックやで......！というセルフツッコミが発生した
これも「なるほどな〜〜」と思ってて、サーバーもクライアントもこういうModel層の構造がさほど変わらずに大事やんな......と思わさせる内容だった
となると共通化できへんのかな......と思うのは怠惰なエンジニアの性であるのだけど、型の定義くらい共通したものを読みたくはなるよね〜〜みたいな気持ちだった
PnP（Plug'nPlayというrequireするファイルをひとつにまとめつつダウンロードしたzipファイルのまま参照できるようにしてデプロイ高速化を狙うやつ）とかZero-Installs（プロジェクトのrepoにnode_modulesをcommitして保持しておいちゃえ！ってやつ）が最近のyarnの目玉だけど、そこまで魅力的かは微妙...... @yarnpkg/shellもnpxでできるって考えるとそこまででも......
yarnもpnpmも速度的には魅力的だけど、CI/CDにおいてそこまで効率的になるのか？みたいな気持ちはある
それこそPnPやZero-Installsは効くかもしれないけど、昨今は適度にキャッシュするし、Edgeに撒くとしてもDeployが都度されるわけでもないからなあ......みたいな
サーバーレスアプリだと効くのだろうか......でもこれもいわゆるイメージに起こしておいて実行時に起動する構成のはずよね......
便利そうだけど、結局npmなのかyarnなのかpnpmなのかを意識しなくちゃいけないなら必要なのか......？の気持ちが残る
諸々参考にすべきで、特にReact.ComponentPropsとFunctional Componentで定義する最後の引数にスプレッド演算子（...props）をつけて残りのpropsを受け取ってから return <button {...props} /> みたいに流すのは便利
ComponentProps<ArticleList>でpropsの型を解決できるので、わざわざコンポーネント側でpropsの型を公開しなくても済むしね
そういえば以前、「組合もそうだけど商工会議所とか入るといいよ」と勧めてくれたことを思い出して調べてた
いわゆる積み立てとか横の繋がりとか様々〜〜みたいなね
標準のマップ（ここではGeolonia Mapsというソフトウェアを使ってレンダリングされたやつ）から指定した領域の画像を切り出すデモ
これを参考に何か作りたいな〜〜と思ったけど、何をつくるかな......🤔
どこかに利用規約が書いてあるwikiがあったはずだけど、見失った......
あ〜〜リアクティブプログラミングで出てくるSignalって概念がめちゃわかった〜〜〜ってかんじ（別の効能があった感） 値の変化だけ書き変わるので他の部分のレンダリングに影響しないのこれ......？？？？？
jotai-uncontrolledもすごいすね......仮想DOMをすっ飛ばすってのをReactに混ぜ込む発想とかあるんだ......みたいな感覚だった
その後が書かれていた
えっ comp() ってのでFunctional ComponentをAtomにしてるの......何これ......
というかpropsすらAtomで追い出してるようなものなので、Signalに包まれたAtomが埋め込まれたJSX（実際に当てられてる型はReactNode）でしかない 簡略化してるけど、以下のような comp() を宣言してAtomにcallbackを埋め込んでメタプログラミングしてるかんじ（デモでの実装は、推論させるために type Signal って指してる部分が詳細だったり any で取り急ぎ回避してる部分があったり、もう少し厳密に型をパズルする必要はあるけど）
code:tsx
const comp = ( fn: ($: Signal) => ReactNode ) => atom(
(get, { setSelf }) => fn((a, ...args) => args.lenght ? setSelf(...args) : get(a)),
(_, set, a, ...args) => set(a, ...args)
)
まあ正直、このへんってReactのパラダイムをあんまり利用してないので、ざっくりReactと言えるけど本質的にReactと言えてるのか......？とは思ってしまった
あくまでjotaiというstoreとReactで拡張されたJSXを返すFunctional Componentという構成要素になってて、その薄さだったらFunctional Componentの部分を代替するものが生まれてもおかしくはない気もする
でも、JSXを返すFunctional Componentがそもそも現在のReactが主導してるパラダイムだと思うので、まあReactではあるのか......という自己解決もしてる
まあFunctional Componentがstateを直接は持たなくなったように、そういった独立性とAPIでの連携が普通になると、別にhooksみたいな公式APIじゃなくても副作用は持たせられる方向になってるやんな？と理解しておく
そう考えると、こういうstoreがReactとどう自然に連携しているかを学んでおくのは非常によいのかもしれないねえ......どっかで
いままではContextで値を渡すだけしかできないと思ってて、場合によってはuseStateをそのまま渡してなんとかしたりしてたんだけど、Dispatchを一緒に流して扱う構造にすれば便利なのね
たまたまアーティファクトみたいなテキストを見返してて、読み返したけど思ったよりも陳腐化してない内容だった
使ってるOSSは2015年当時のトレンド感あるけど アーキテクチャとか勘所とか心得みたいなものとかは2023年現在でも通用しそう Honoよさそうよね〜〜Web標準に準拠してるってのがすてき
OpenAPIとかでAPI仕様書作って一通りテンプレート生成してもらって、それぞれ中身を実装して各種実行環境でサクッと動くみたいな世界線になるのかなあ
小型のアプリなら今のアセットでもできそうだけど、どのようにModel/Domainを組織化していくかね〜〜とかは思いつつも、DenoみたいにES相当のランタイムで動く想定にしておけば流動性も担保できそうよね（えっどうだろ）
まだ他のLLとかGoとかの方が汎用的かなあ......うーん
これ〜〜この多重継承に引っかかったんだよね最近 😇
class APIClient(APIRequestFactory, Client) で class APIRequestFactory(RequestFactory) と class Client(RequestFactory) があるようなかんじで、参照される順序が APIClient -> APIRequestFactory -> RequestFactory -> Client だと思ってたんだけど、 RequestFactory と Client が逆だったんだよね
C3線型化 ってアルゴリズムだと、共通して基底に持たれる場合は優先順位が変わるっぽい この構造でどのバージョンのDjangoを触っているかわかるわね...... 😇😇😇
def __call__() をもったクラスのインスタンスは関数みたいに扱えるみたいだけど、それclassとして定義するんだ......みたいな気分
でもPHPでもあるよねそういうのたしか（と思ったけどマジックメソッドの function __call() と勘違いしてたから違うわね）
Pythonランタイムにビルトインされてるテストランナーみたいなものなのかな
このへんの unittest.TestRunner とかに渡ってるのかな
このあたり で class SomeTestCase(unittest.TestCase) みたいなTestCaseクラスのインスタンスにテストメソッドの名前を渡して unittest.TestSuite を作ってる このへんのお話は整理して何かしらのエントリに書くとよさそうよね 👀
Django 4.0 でのお話
こうやってrequestオブジェクトが作れることを知ってると便利よね
request.request() で WSGIRequest インスタンスも
なんかとあるクラスインスタンスを if isinstance(instance, type) って検査されてたのを見て、初見だとよくわかんなかった
結論、 type(instance) でそのインスタンスのクラスが返るんだけど、この type() って関数っぽいやつが実は class type(object) みたいな定義で object 型を継承しているらしい
そもそも type(name, bases, dict) という形式でクラス定義を読み込むビルトイン関数みたい（定義はcpythonリポジトリにC言語で書いてある）
で isinstance(instance, type) を渡すと全てのクラス定義は type() で呼び出されてるから、何かしらのクラスインスタンスか否か（＝プリミティブ型ではないかどうか）がわかる、みたいな仕組みらしい
あーduck-typingってそういう意味なのね
あるオブジェクトが正しいインターフェースを持っているかを決定するのにオブジェクトの型を見ないプログラミングスタイルです。代わりに、単純にオブジェクトのメソッドや属性が呼ばれたり使われたりします。（「アヒルのように見えて、アヒルのように鳴けば、それはアヒルである。」）
そうよね型の方がstrictよね
toxの設定に渡せる envlist に指定できる値が定義されてるっぽい（ってのがrepoのdescに書いてあるわね） .pthって拡張子のファイルでpath通せるらしい......？
便利そ（ pip install --editable ./path/to/module でlocalにある開発中のモジュールを読める）
Pythonはモジュールの読み込みをする都合上 src/ ディレクトリを使わないレイアウトが通例だったけど、上記のようにsetuptoolsにDevelopment Modeが追加されたことで src/ ディレクトリをカジュアルに使えそうなかんじっぽいね
django-fliterのよさがあんまりわからんけど、Django REST Frameworkにだいぶ密なモジュールなのね......と思った
DjangoのMiddlewareとかはCakePHPのMiddlewareを知ってたらなんとなくわかるし、これも何かしらの標準なんだろうね
Middleware群を設定しているリストを下から上に読んでいって重ねていって連鎖的にMiddleware内で次の get_response() を実行していくかんじ
なので各Middlewareに定義されてる def __call__(self, request) のなかで response = get_response(request) をする前と後でViewを呼ぶ前の処理とViewを呼ぶ後の処理とを行えるようになってる
get_response() の前でMiddleware群の定義されたリストの上から下へ実行されていって、 get_response() の後でリストの下から上へ実行されていくかんじ
Django 1.10のときに class MiddlewareMixin を廃止して process_request() と process_response() を書くんじゃないスタイルになったのね
もともとは request = get_response(request) の前後を明示的に process_request() と process_response() に分けてたけど止めたっぽい
class CsrfViewMiddleware とかも csrf_exempt() みたいなデコレータを使ってskipできたりとか便利ね〜〜みたいな気持ち
あと process_view() はViewが呼び出される前に呼ばれるのね〜〜（そういうhookみたいなのがいくつかある）
あとDjangoのView Genericsが便利ね〜〜みたいなかんじ
実装はDjangoが一通りメタにしといてくれてるから、各種設定を書いてくかんじになるよね
あれこれ使いこなせば、Viewはスリムに保てる感があってさすが〜〜みたいな
その一環がdjango-filterみたいな思想なんだろうね〜〜使いこなせればシュッと定義できそうだし再利用も効きそうなのよね
けどWSGIはPythonくらいでしか使わないのか......
他の言語はだいたいApache httpdモジュールのモジュールとか、それぞれの言語向けにサーバーソフトウェアあるもんね
Goはnet/httpでマルチスレッドなHTTPサーバー立てれるし、これにリバースプロキシ立てれば十分なのか......？すげえなあ Apache httpdにはmod_wsgiがあるから、直接WSGI経由でハンドラをApache httpdから叩いてもらってるけど、nginxだと別途WSGIサーバーを立てる必要があるのか
Apache httpdでもよいけど、軽量サーバーの選択肢は他にもある
uWSGIとかgunicornとかあるっぽいけど、これリバースプロキシをわざわざ立てる必要性......？（普通にリバプロの機能が欲しい場合とかサーバーの中でスケーラビリティ持たせたいならまだしも、Dockerコンテナとかならコンテナを並列させてロードバランサーで対応してもよさそうに思えた）