Reactのコード量を犠牲にして、コードの見通しを取る考え方

1500行ぐらいの軽めのAngularでつくられたwebアプリケーションを、 React（+手製Fluxっぽいモジュール）を使って書き直しました。ざくっと思ったことを書いておきます。Virtual DOMや性能的な話はなしで、コードの見通し・構造的な観点のみですが。

domエレメントと、その実装の距離がコード上で近くなったので、どこで何をやっているのかなどがわかりやすくなった。
逆に、javascriptとhtmlがセットになった分、よくあるjavascriptは変えずにDOM構造変更、は気軽にできない。そういうオーダーがあとからこないかビクビクしている。
コード量が増えた。約3000行くらいだったので、倍になった。冗長なコードも多いかもしれませんが。
コンポーネントの状態（state）は、そのコンポーネントで持つか、親コンポーネントから継承（props）するか。コンポーネントで考えるときに、どのコンポーネントにどの状態を持たせるかという設計が、アプリケーション全体をシンプルでわかりやすい状態を保つために重要。
最初、子コンポーネントから、親のまたさらにその親コンポーネントにどうやって状態変更を伝えるのか？を考えて、reactでやりきろうとpropsバケツリレー的な？ことやらかしまして、それから、どんどんおかしな方向に行っちました。。reactはあくまでも、状態と処理と結果ビューを1セットで扱う、ただのMVCのVなわけで、そこを勘違いしちゃうと、変な方向にいっちゃう。なんとか知り合いに聞いて、dispatcherとstoreを入れるflux的に解決で対応。状態（state）はビューのデータを一時的に入れておく箱ぐらいに考えておいて、アプリでグローバルなデータ/モデルなんかはstoreに持たせて、ビューはstoreをlisten、storeは変更をビューにemitするのがreact/flux的。

まとめ

マルチスレッド・プロセスの処理なんか書いたことないwebサーバサイド人間としては、
フロントのUIの非同期ばんばんの処理にはじめてぶち当たったときに、MVCでやりきろうとしてカオスになって死ぬ。。的なストーリーを地でいきかけたわけです。。

で、こういうReact的な解決方法は新鮮でした。

コード増えるけど、データの流れが決まっているので、
その流れに乗せるように開発してけば、見通しよくなるんじゃね？的な。

ただ、htmlとjsをくっつけたことでの弊害も色々あるので、
ケースバイケースです。

デザイナーがjs書けて、そこそこ規模の大きくて、運用しやすさも求めるならば、
向いているかも。

もちろん、別にVirtual DOM的な導入利点もあるかもしれませんが、
それは、Reactだけの話ではなくなるので。