Reactには組み込みの状態管理機能があるの？

ちょっと懐かしいな、昔Backboneのチュートリアルをたくさん書いてたんだ。 https://news.ycombinator.com/item?id=3110025 https://web.archive.org/web/20111015073638/https://backbonet... インポートがない以外は、15年後でも嫌いじゃないよ。LLMのおかげで、コーディングについての考え方がかなり変わった。どのように言語を書けばLLMが最も効果的に書けるかに興味がある。JSX/宣言的なものは結構しっかりしてると思う。useEffect以降のReactコミュニティはちょっとふわふわしてきてる気がする。多分、LLMが「考える」にはあまり良い方法じゃないんじゃないかな。（表現力、明示性、解析可能性について何かある）

MarionetteはBackboneのボイラープレートをかなり減らしてくれたけどね。

1,000コンポーネントが同じページにあるような大規模アプリ もしページに40X25の編集可能なテーブルがあったら、それが1,000コンポーネントになるね。でも、テーブル以外では、1,000以上のコンポーネントを一つのページに持つのはやりすぎに思える。

Reactの本当の革新は「単方向データフロー」だと言えるかもしれない これはDOMの動き方そのものじゃない？ データは属性やプロパティを通じて下に流れ、イベントは上にバブルする？ > でもReactチームはFlowアーキテクチャをフレームワークの中心に据えたんじゃない？ 彼らはFlowではなくFluxと呼んでたよね？

コンポーネント自体が追加の複雑さの一形態なんだ。アイデアは、構成され自己完結したコードの島を提供すること。これを達成するためには、大量のマークアップ、プレゼンテーション、イベント処理、ビジネスロジックの記述、そして前述の抽象化を補うためのセキュリティやアクセシビリティのロジックが必要になる。エディタで見るものはあまり見栄えがしないかもしれないけど、その裏には膨大な無駄が隠れている。なんで人々はこれを好むの？ メンテナンスの速度は上がらないのに。開発者が快適に感じる事前定義されたアーキテクチャスキームに組み込めるから好まれるだけなんだ。それだけ。結局は快適さの問題だけど、複雑さはとんでもないことになってる。シンプルなものはタダじゃない。

双方向データフローがあり、ストアを更新するとUIが変わり、それが状態ストアを変えて、またUIが変わる、という問題がある。Reactでも同じ問題が起こるよ。循環する状態更新。状態変更→useEffectをトリガー→状態を変更。これ、Reactを始めたばかりの頃にぶつかったことがある。

人々は、React/Flux/Reduxの前のフロントエンド開発がどうだったかを思い出さないし、思い出せないこともある。1000行未満のシンプルなページでも、状態管理で問題が起こることが簡単にあったよね。もちろん、対策はできたけど、全然簡単じゃなかった。

私は何年もAngularを使っていて、最近新しいプロジェクトのためにフロントエンドの仕事に戻ってきた。これが私のReactの経験で、完璧ではないし、いくつかのReact特有のことを学ぶ必要があるけど、正しいことをする傾向があるよ。

ここでの著者です。単方向データフローが実際の問題を解決するという点には感謝していますが、実際には一つの複雑さを別の複雑さに置き換えているだけだと思います。確かに、Backbone Storeの状態変更のカスケードはデバッグがフラストレーションでした。でも、Reactの抽象化は同じくらいフラストレーションを引き起こす問題を引き起こします。古い状態を参照するクリックハンドラーの古いクロージャー、依存配列のオブジェクトが毎回再生成されるための無限のuseEffectループ、安定からインデックスベースに変わったために起こる神秘的な入力クリアリング。違いは、Backboneの問題は明示的で可視化されていたことです。何かが壊れたとき、イベントハンドラーを追跡して、何がいつ発火したのかを理解できた。複雑さは目の前にあったから、デバッグ可能だった。Reactの問題は抽象化の背後に隠れている。Reactが問題を解決しないとは言っていませんが、それらの解決策がFacebook規模ではない99%のアプリに適切かどうかを疑問視しています。時には、明示的で冗長なアプローチの方が、長期的には考えやすいこともあるんです。