2015/07/24はReactで遊んでみたぞい（今更）。以下全然体系だってない感想。
setStateの反映が遅い件
<p>{this.state.text}</p>
みたいなテキストを、いくつかのメソッドからappendしながら構築したい。
しかし、setStateの反映がrenderのタイミングなので
setState({text: this.state.text + str})
みたいなジツはつかえん。
かといって、それ用のフィールドを作るのもクソ設計感ある。
やはりFluxか……
追記
フィールド作っちゃったほうがシンプルっぽい。
stateは表示に直結するもの、という扱いが良さそう。なんだったら要らないかも知れないけど、コンポーネントのupdateのトリガーになる存在なので一応要るのか。
このフィールドを別のクラスに切り出した存在がFluxのStoreちゅーことになりそう。
Storeの変更をcallbackで拾ってsetStateの流れ。
ここは理解。
だが、それならトップレベルだけがStoreとやりとりするってのがひっかかるな。
state持ってるコンポーネントからStoreにcallbackを仕掛けた方がコンポーネントの責任が明確な感ある。
Storeとトップレベルコンポーネントの両方がデータ集約しちゃうからね。
Fluxよくわからんぞいや
まず説明の図に箱がいっぱいあるのがヤバイ。
View(React)→Action→Dispatchcer→Store→View
という４者の一方向に回るメッセージ構造が基本らしい。
気になるのはStoreで、こいつが全ての情報を握っているのだが、Reactを使うとViewもstateを持つわけで、なんか二重管理感がある。
Storeに変更があったら即イベント通知してViewを更新する的な感じだと思うんだけど、めんどくさい……
結局stateはどこへ置くべきか
トップレベルにまとめて置くプランと、コンポーネント毎に置いて、上から参照するプラン。どっちがいいんだ。
トップレベルに置くと、トップレベルのコンポーネントがMVCでいうModelに相当するようになる。トップレベル以下はstateは持たず、propsで反映されるだけ。これはこれで良い。
コンポーネントごとであれば、コンポーネントの責任範囲が明確になってこれもこれで良い。
はてさて
JSX構文
renderは一つのコンポーネントしか返せないという言い回しを聞くことがあるが、一つのJSX文が返せるのも一つのコンポーネントのようだ。
renderで最終的に一つのコンポーネントになるようにしたとしても、途中の関数で複数のコンポーネントを返すようなJSXを書くと変換エラーになる。
その辺はちょっと柔軟性がない。
ES6
jsxのharmonyオプションっつーのが面白そうだったので使ってみた。
連想配列でメソッドを定義するのが楽ちん。
hoge = {
method1() {...},
method2() {...},
}
無名関数も
(arg) => {...}
と書けて、全般的にfunctionをタイプしなくて良いみたい。
実際忘れてるところ以外はタイプしてないし、今消したのでfunctionという単語がゼロですよゼロ。
JavaScriptだとめっちゃ書く単語なのにね。
感想
だいたいやり方は分かってきた。
Viewのみの薄いフレームワークなので、基本はまぁそんな難しくはないなー
でもいろいろ組み合わせていくといろいろなことができるので、一朝一夕というわけにはいかなさそう。