日 時： 2016年8月24日 19:00 ~ 21:30会 場： 株式会社ABEJA
Vue.js in production
ABEJA inc. Front-End Engineer LSK
資料：
- だいたいのJSのF/Wやライブラリはトップダウンに作っていくけど、
- Vue.jsは下からcomponentから作っていくといいよ
- それでSPAになるよ
- conponents -> containers -> application
npm install -g vue-cli - component内のexportに記述したものがビューに反映されるー {{}}ね。
- JSをconponentから吐き出すのではなく、htmlはhtmlファイルにだけ書いて、データのみを渡す。
- それを{{}}で参照する。
- シンプルになったAngular.jsに近い。
- デモあるよ > https://megakanban.firebaseapp.com/
よかったこと
- すごくわかりやすい。学習コストが低い。
- componentを機能ごとに分けれる
smart componentはViewがない（コントローラー）
view componentはボタンとかinputとかView（View専用） - Vue.jsはドキュメントが日本語です！
- ReactではなくVue.jsである理油はただ一つ！JSX！
Vue.js 2.0を試してみた
Vue.jsの好きなところ
- Reactivecomponentとか作りやすいね
- 軽量パフォーマンスもReactより早いとか
- シンプル細かいとこはキメが必要だけどねAngular 1.xに比べればすごいシンプル制約もあまりない
- 簡単学習コストが低い
サンプル
- https://github.com/toshilow/vue-v1-sample
babel / sass / webpackいれてる
シンプルだからってのもあるけどファイル数も少なめ
action/store : flux like → vuexっていうのがあるね （http://vuex.vuejs.org/ja/intro.html）
- Vue.js devtoolが便利
stateを覚えていて、logの履歴をクリックすると巻き戻してくれる
フロントエンドの設計に関する考察
基本設計の方針
- 状態管理の一元化
- 状態遷移と画面描画の分離
- コンポーネントの階層化による関心の分離
Fluxの考えに従ってます
- Viewの描画がstoreの状態に基づいてる
ユーザによる動作の手続き型じゃなくて関数的にできる - テストが容易
action経由でのみデータが流れるため - storeはすべてを持たない
ユーザが複数ページを経てまた元のページに戻ってくる場合は入力データを保持していたいのでstoreにいれるなど
storeの設計方針
- データ、処理状況、画面状態に整理
- 複数のデータから結果が出せるような値は持ち直さないようにする
ただ、グローバルに必要で複雑になる場合はActionを通して計算してもたせておく - store / actionのたらい回しは嫌
一方向にデータが流れることが保証されてるのであればどのコンポーネントがstore / actionを読んでもいいことにする
componentを切り分ける
- presentatinal component / container componentstoreを受けるやつviewのみを扱うやつ（actionを渡す）storeはpresentational componentからcontainer componentに渡す（1ページにroot componentを複数持つ形）
質疑応答
- galpを使わない理由
gulpが複雑。gulp職人を作りたくないし移植しずらいし。npm scriptで出来るならそっちで。
Creator of Vue.js EVAN YOU
reactに似てるけどシンプルなアプローチがメイン
How to build SPA with cue router 2.0
SPAとは
- webの技術でデスクトップライクなページを。by wiki
- ただ、普通のサーバサイドレンダリングとは違ってコツがいる
ex. 戻るボタンの挙動とか
SEOめんどくさいとか
Vue Router 2.0とは
- サーバサイドレンダリングとSPAが同時に使えるよ
SPAは普通はSEO対応できない 2年前までのスタンダード
vue router 2.0はサーバサイドレンダリングしたものをクライアントで復元するような構造になってるのでSEOも解決できる - node.jsの仕組み上、requireされると音メモリに残っちゃうので、毎回リクエスト毎にコンポーネントを作り直す必要あり
こういうこと（ざっくり）
- リクエスト→渡されたパラメタをサーバサイドでレンダリング＆データ取得→クライアントに渡す→クライアントレンダリング
いい点
- サーバサイドでデータをキャッシュできる
レンダリングされたコンポーネントをキャッシュしておく
考慮点
- gulp職人が必要
- サーバサイドでパラムをFetchするコードとクライアントサイドでパラムをFetchする部分を同じ書き方する必要あり
同じコードで動くから
まとめ；
- react + redux + react routerはそれぞれ作者が違うのでサーバサイドレンダリングできはするけどシームレスではない感じ
0コメント