isomorphic JavaScript のスコープ雑感
Posted: Updated:
isomorphic JavaScript のスコープ
雑記です。
- 単純に server でも client でも使える isomorphic module なのか
- コンポーネントを共有できる isomorphic architecture なのか
- ルーティングを共有できる isomorphic architecture なのか
1. モジュール共有
モジュール単位の isomorphic は、DOM API や Node API に依存していない or 依存していたとしても browserify のようなツール類によって壁を乗り越えられる条件下では比較的容易に実現できる。使うべきAPIが違っても、if分岐で何とかなるだろ、って感じもする。HTTP Client とかは最たるものかもしれない。
2. コンポーネント共有
コンポーネント共有であれば、クライアントでもサーバーでも同じコンポーネントを呼び出せるというだけ。サーバーサイドでレンダリングしたコンポーネントの DOM と State の関係性をクライアントサイドで初期化するのは一定の戦略が必要ではある。
3. ルーティング共有
ルーティング共有は一番面倒くさそう。Server-Side Rendering を目的とした isomorphic architecture を SPA として振る舞わせるならマストかもしれない。そうでもないならさほど重要ではない。ルーティングの共有が実質、いわゆる Controller 処理の共有につながる節もある。パーマネントリンクをどういう方針で管理するのか、とかも絡んでくるだろう。ここまでくると、全域が isormorphic でないといけないので手間は増えそう。
反面、yahoo/fluxible のような諸問題を解決済み(?)のプロジェクトをベースに構築すること自体は難しくなさそう。（ fluxible 自体はクセがある感じもするが）
まぁー
なんにせよ何のために isomorphic するんだっけか？ というのと、クライアントサイドの JavaScript は今の所は絶対王者だけど、サーバーサイドの JavaScript はそれほどでもない、というコトも踏まえて研鑽の力加減を考えて参りたい。
