【メモ】Frontend Meetup vol.1 -SPAを語り尽くす会! 2016/9/16 @株式会社FiNC
これに行ってきたのでそのメモ。
Frontend Meetup vol.1 - SPAを語り尽くす会!
SPAと聞いて
SPAの開発が好きすぎてたまらないのだけれど毎回破綻する僕としてはSPA系の勉強会と聞いたら行きたくてたまらないんです。
やっぱりSPAという言葉にはわりと多くの人が反応するようで今回の勉強会は抽選でした。運良く当たったので行ってきました。
ということでメモったので共有します。
関係ないけどここで勉強会の抽選運を使ってしまったことで次のReact meetupの抽選での運が奪われたのではないかという心配をしてます。
目次
- React/Reduxで半年くらい真面目にSPAするとわかること
- 革命と秩序とSPA
- Angularと心中する
- コンテンツ配信とSPA
- SPAと覚悟
- Angular2でつまづいたところ
- 1pxをめぐる戦い
- SPAでのセッション管理とセキュリティ
本編
残しといたメモを貼りつつ感想を付け加えていくスタイルで。
React/Reduxで半年くらい真面目にSPAするとわかること
内容
- Finc app webをSPAで作った
- Reactは学習コスト高くないから良い
- fluxフレームワークはいろいろあるけれどReduxに行き着いた
React/Reduxをよく調べていけそうだったのでプロジェクトにいれてみた。 しかし
- つらいコンポーネント
- つらい繰り返し・テスト
- つらいデータの扱い
コンポーネントで大事なこと
this.context
バケツリレーをせずに値を受け渡すことができる。 全部のビューで使うやつとかはcontextでわたしちゃうと良い。
- UIにあわせたentityをつくってはいけない
- あくまで概念として正しい最小単位
- Storeの設計も自ずと決まる
まとめ
- 正しいコンポーネントを積み上げねば、幸せはやってこない。
- this.contextの活用 => DRYとDI
- エンティティと型 => 見通しをよくする
感想
「CSSとcomponentが一対一」ってところにはいまいちぴんとこなくて、以下の記事で言われていることの方が僕はすんなり納得できる。
ReactコンポーネントとCSSのコンポーネントの粒度は同じにならないと思っていて、CSSのコンポーネントの方がJSのコンポーネントよりも多くなる（細かくなる）。 JSとCSSのコンポーネントが1対1に対応しないので、CSS ModulesやRadiumなどのCSS in JS系ツールのアプローチは合わないと思っている。
今更ながらなんだけれど、そしてみんなそうなんだけれど、なんで最近はみんな自らSPAが良いと思って手を出して、つらいつらい言ってるんだろうとそう思いました。
革命と秩序とSPA
@joe_reさん
内容
フロントの歴史
- Ajax
- Backbone
- 2way-binding
- virtualDOM
freeeのフロントエンド
- Backbone(SPAではない)
- ページ単位でBackboneでSPA -> メモリリークするしDOM操作大変だし辛い
- freee-mvc-framework -> 社内フレームワークの誕生(Backboneの機能拡張) -> それでもDOM操作辛い
- vueのVMを追加して2way-bindingして完全なSPAになる(vue on backboneだと...) -> 状態管理辛い
- React + flux -> 革命！
flux選んだ理由
- 既存実装があるところに導入する上でReduxはつらい
- flux-utilsを使うという選択(flux実装のベストプラクティスのいいとこどり)
- ミニマムな実装でロックインが少ない。既存のfluxから乖離しない
機能はReduxっぽい。Reduxぽいけど軽い。
さらに
- bower => npm
- sprockets => webpack
それでもなお…
実装やIFに統一性がなくてつらい…型さえあれば…
flowtype
- 強力な型推論
- babelを使っている場合はpluginを追加するだけで使える
- チーム開発では必須！
- 自分が実装したモジュールのIFを明確にする
感想
やっぱり辛いって言葉が出すぎてた。
でも一つ一つ解決に持っていってるのは素晴らしい。
僕もReact + Reduxのコードにflowを入れたくてたまらない近頃なので良い話を聞いた。
Angularと心中する
@Quramyさん
https://quramy.github.io/spa-knowhow-note/#/
内容
webサイト解析をするサービスをSPAで作っている話。
フロントエンド: TypeScript, AnglarJS(1.x)
バックエンド: golang, mongodb, elastic search
解析基盤: Scala, Apache Cassandra
Angular 1.xでの取り組み
- Component
- コード自動生成
- エラー周り
Component
AngularJS1.5からはcomponentが利用可能に。directiveは余程のことがないと利用しなくなった。
AngularJSといえばscopeと2-way bindingだが、今は1wayか2wayか自分できめられるのでどっちでも良い。
それよりもCSSのscopeのが問題 => そこでBEM
でもclass名ながい => 独自directiveで解決。名前空間を指定してclass名をつづける
コード自動生成
gulp + inquirer + mustacheを使ってcomponentやserviceのscaffoldタスクを用意。
Componentの場合生成されるやつ
- Component本体となる.ts
- Componentに対応するBEMの.scss
- Karma用のspec.ts
エラーまわり
TSで型を手に入れたからエラーでない！ => 出る
Rollbarを利用。エラーモニタリングサービス。
Rollbarにした理由
- sourcemapを公開する必要がない
- stack traceとsource mapが紐付けられる
覚えて帰ってほしいこと
- CSSをComponentに閉じ込める仕組みがあるとよい
- コード生成でよい進捗
- それでもエラーは起きるので通知機能は入れた方が良い
Angular2の取り組み
書いているコードは別物感が相当強い。
DIや変更検知などの根本的な思想は1系と同じ。
慣れてくるとあまり1と2の違いは気にならない。
componentのcompile問題
componentのテンプレートは実行時にcompile => 遅い
solution => AoT compile
事前に変換して実行時オーバーヘッドを削減する仕組み。
Angularが公式にcompiler CLI(ngc)を提供している。
体感で違いがわかるくらい違う。
感想
SPAやっててCSSの問題は悩まされることが多いなあと思う。
ReactでBEMやるなら@axrossさんのbemmerが良いって聞いた。
あとはscaffoldどエラー検知は素晴らしかった。とても参考になる話。
会社単位でAngular2にこの段階で取り組むってすごいことだなあと思う。
コンテンツ配信とSPA
@konpyuさん
内容
noteをAngular 1.xで作っているのでその話。
現役でAngular 1.xだが
=> 構成見直しの機運。まずは初期ロードをなんとかしないと。
- DOMの数を減らす => デザインをなおしてDOMの描画をへらす
- HTTP負荷を減らす => cacheしにくいものはwindow.PREFETCHにつめたり
結果、すげー早くなった(それでもまだ遅いけど)。
SPAで高速(に感じる)コンテンツ配信
Reactでnoteのタイムラインを再現してSSRしたけど、実現するには実装が煩雑
HTTP/2
- HTTP1時代のベストプラクティスが裏目に出る
- facebook: 大量のアセットを一斉に落としにかかる様は圧巻！
まとめ
SPAはモバイルですぐに性能が悪化するので注意。初期ロードを早くする要件があるならDOM構築は必要なものだけ最初に。
コンポーネント化 + コンポーネントごとにSSR + コンポーネント単位の遅延ロード + HTTP/2 = よさそう
感想
以前にnoteをぼんやりと見てたらAngularだったことに気づいたのでAngularを使っているということは知っていたのだけれど(あとmozaic.fmでも言ってた気がする…)、その裏側で結構苦労したのだなあーと。
ただやっぱりSPAのモバイルで速度の問題が出るのはまあありがちなことだと思いつつ、しっかり対応してる話を聞けたのは良かった。
速度を早くするってのは、物理的な速度ももちろんなんだけれど、体感速度を早くすれば良いってのは本当にその通りだと思うので、その目線で考えてみるとチューニングの幅が広がりそう。
SPAと覚悟
@teppeisさん
SPAと覚悟 from Teppei Sato
内容
SPAとは
ブラウザにとっては1枚のページ。そこに様々なハックを駆使してリッチな体験を提供するアプリケーション。
ブラウザの標準的なUXに満足できないから自分でつくる。
SPAとはブラウザを超える体験を再実装する覚悟 => その覚悟がないならSPAを選択するべきでない
例えば遷移
ユーザーの気持ち
A => B => C 戻る C => B => A
作ったSPAの動き
A => B => B' 戻る B' => A
ページナビゲーションの設計とかもSPAでは全部自分で考える。
- いつヒストリに積む/復元するか
- どこまで状態を記憶するか
- dispose問題/投げてるXHRどうしよう
SPAゆえの考慮事項
SPA => 頭悪い流行
SPAとa11y
ブラウザが実装している標準要素は実は標準でかなりa11y対応されてる。
オレオレSPAでおらおらDOM構築する場合、自分でa11y対応していく必要がある。
divだらけのReactコンポーネント書いてない？(正確にはSPAというよりcustom element)
あなたのSPAは本当にブラウザを超えてますか？
ブラウザを超えすぎてはだめ
ブラウザを触ってるときはユーザーの頭はブラウザを想定している => 驚き最小の法則
SSR(SPAじゃないやつ)のUX(速度)も高まってる
- HTTP/2
- Service Worker
- AMP
- Preload
SPAとはブラウザを超える体験を再実装する覚悟である！！
感想
エモくてかっこいい話だった。そして色々考えさせられた。
僕はわりとSPAをやりたくてSPAをやっていたりするので(さすがに業務でその考えで導入したりはしないが)、本来の目的である問題の解決のための最適化ができているかと言うとそうでもない気がしてきた。
ここらへんから僕の心がマイナス方向へ向き始めてなんだか落ち込みつつ話を聞いていた。
ただまあその覚悟をもってSPAで全力で作るのが楽しかったりする。
Angular2でつまづいたところ
内容
フロントエンドだけ完成したので見せますよ。 技術スタック: Angular2, TypeScript, webpack, Node.js, system.js
認証機能で困った
- Angular2では状態をcomponentが持つ
- serviceは持たないようにしたい
- つまりcomponentが認証情報を持つ？
- 形のないものにcomponentを使うのがいや
bootstrapでたちあげるときに認証用のserviceにわたす
感想
初めての発表の舞台ということで大分緊張されていた。しかし、その一歩を踏み出したことってのはとても尊いことだなあと。
僕はまだ踏み出せていないので、まぶしい感じで見ていた。
SNSを作っている途中なので見てくださいって内容でした。
Angular2のチュートリアルしかやってない僕でもぎりぎり理解できた。良かった。
1pxをめぐる戦い
内容
縦並びのリストのborder-bottomに1pxつけてるときの一番下のliのborder-bottomだけ消したいけど状況的に色々厳しいときにCSSでどう頑張るかっていう話。
とにかくCSS力の高い話だった。スライドが全て。
感想
CSS深い。
SPAでのセッション管理とセキュリティ
内容
- SPAでのセッション管理
- CSRF対策
- CORS
SPAでのセッション管理
基本的に普通にcookieつかえばいい。
localStorageはどうか
- 認証の前にjsが呼ばれてないと値を読めない
- ブラウザでcookieを消しても認証は続く
- 外部の悪いJSを読むとtokenをぬかれる危険
- tokenのexpireを自分で実装する必要がある
CSRF対策
SPAだとcsrf tokenを仕込むタイミングが難しい => ブラウザのpre flightを利用する
pre flightで事前に安全かどうかを見る。
CORS
cross originのリクエストは許可しないとできないので、逆に言うと許可すれば別ドメインでサーバ置いたりできる。
まとめ
- ざっくりでもセキュリティの話を知っておくのは大事
- ブラウザの制約などは意味のあることなので、ちゃんと理解して使う
- サーバーサイドのツラミを知ろう
感想
セキュリティの話。
僕はセキュリティのところとても弱いので、しっかり勉強しなきゃなと考えさせられた。
ちなみに、僕はSPAで認証するときはJWTとsession/localStorageでやっています。
詳細を詳しくQiitaで書いてるので詳しくはそちらで。
まとめ
途中で休憩で軽食食べさせてくれたり、あと普通にそれが作ってくれたやつでとてもおいしかったり、途中のフィットネスタイムみたいなやつとか、顧客満足度を上げる努力がとても良かった。
FiNCでやるイベントはどんどん参加したいと思った。
内容としては、僕のSPAに対しての覚悟が問われた1日だったという感想が頭の中を占めてしまった。
本当に色々なことを疎かにしている中で、流行っているという理由でSPAをしてしまってるだけではないだろうかとか自問自答しちゃったり。
とにかくがむしゃらにコードを書こうというそういう意識を持てたことはとても良かった。
この連休中はひたすらコードを書く。
こちらからは以上です。とても楽しい勉強会でした。
