odan3240のブックマーク - はてなブックマーク

odan3240 id:odan3240

ブックマーク / scrapbox.io/fsubal (6)

props のバケツリレーって何が悪いんだっけ - fsubal
#React やってて、props のバケツリレーを何か嫌がる人たまにいるんだけど、自分は props のバケツリレーそのものをそんなに悪いと思ったことがない。「バケツリレーがつらい」ように見えるコンポーネントの大半はそもそも props の設計がおかしい場合が多く、本当の問題はそっちにあると思っている。たとえば、次のようなバケツリレーはつらいかもしれない。ここでいう Body はサイドバーとしてフォロワーの一覧を表示し、メインコンテンツとしてフィード一覧を表示するみたいなものを想像して欲しい。フォロワー一覧の中で使う props とフィード一覧で使う props を混ぜて1つの親に渡している状況だ。
odan3240 2021/03/12
"「バケツリレーがつらい」ように見えるコンポーネントの大半はそもそも props の設計がおかしい場合が多く、本当の問題はそっちにあると思っている" なるほど
リンク
SWR vs React Query - fsubal
（※ この記事は API およびそこから導かれる設計のしやすさ観点での比較をしています。実際にキャッシュが有効に効いたか、などについてはまた別の機会に）
odan3240 2020/10/05
リンク
React 内で JS のクラスインスタンスを用いる - fsubal
EventEm itter とか外部の UI ライブラリ辺りが定番かと思う（カルーセルやスライダーのライブラリを自分でコンポーネントにラップした経験は数しれず）。最近の JS では pure object + 純粋関数という #設計を取るケースも増えたが、たとえば DOM API に対して副作用を起こすミュータブルな処理はクラスで書いたほうが自然なことも多い（ライブラリが new Slider のような形式を取るのもそれが理由だろう）。
odan3240 2020/06/27
リンク
Reducer はなぜ reduce なのか - fsubal
最近はそもそも redux-toolkit などがあるので概念的に理解する必要性も薄くなっているのだが、とはいえ説明した方が良いこともある。
odan3240 2020/06/08
リンク
本当に倒すべきだったのは jQuery ではなくテンプレートエンジンだった - fsubal
そうはっきり言ったほうが良かった。いや言わなくても伝わる現場は良かったんだけど、伝わらないままごく一部だけをコンポーネントに移行、それ以外はただ生 DOM API に変えて終わり（あるいは他は jQuery のまま）みたいな「モダン化」で済ます余地を与えたのは発信の失敗だった……という10年代の振り返り。テンプレートエンジンはなぜ倒された方が（…といって悪ければ、変わったほうが）良いのかは端的に指摘できて、それは初回レンダリングしか考慮してないからだということになる。 Web の UI には状態変化がつきもの（になったのは実は最近の話）だが、テンプレートエンジンは1回目のレンダリングだけを担当し、変化した後の2回目以降の見え方は JavaScript が担当するというパラダイムを構成する。
odan3240 2020/06/07
リンク
フロントエンドにおける「関心の分離」は間違っていた - fsubal
「HTML と CSS と JS を同じファイルに書くなんて関心の分離に反している」、という主張を古き良き人々から聞くことがある。これはおかしくて、そもそも HTML と CSS と JS が違う関心というのはブラウザにとっての視点であり、開発者の視点では最初からなかった。CSS なんて、HTML 内のクラスと暗黙の結合があるよね。本当は密結合であるものを拡張子の違いだけで分離した結果破綻したのがこれまでの #フロントエンド設計の歴史であり、要するに関心の分離なんて嘘じゃん、という反省から生まれたのが React や Vue などの「コンポーネント」なんですよという話。
odan3240 2020/06/07
リンク
1