読者です 読者をやめる 読者になる 読者になる

nabeliwo note

5万人に1人になる。

【メモ】Frontend Meetup vol.1 -SPAを語り尽くす会! 2016/9/16 @株式会社FiNC

Angular2 React Redux SPA JavaScript

これに行ってきたのでそのメモ。
Frontend Meetup vol.1 - SPAを語り尽くす会!

SPAと聞いて

SPAの開発が好きすぎてたまらないのだけれど毎回破綻する僕としてはSPA系の勉強会と聞いたら行きたくてたまらないんです。
やっぱりSPAという言葉にはわりと多くの人が反応するようで今回の勉強会は抽選でした。運良く当たったので行ってきました。
ということでメモったので共有します。

関係ないけどここで勉強会の抽選運を使ってしまったことで次のReact meetupの抽選での運が奪われたのではないかという心配をしてます。

目次

  • React/Reduxで半年くらい真面目にSPAするとわかること
  • 革命と秩序とSPA
  • Angularと心中する
  • コンテンツ配信とSPA
  • SPAと覚悟
  • Angular2でつまづいたところ
  • 1pxをめぐる戦い
  • SPAでのセッション管理とセキュリティ

本編

残しといたメモを貼りつつ感想を付け加えていくスタイルで。

React/Reduxで半年くらい真面目にSPAするとわかること

@takayuki_shmzさん

内容

  • Finc app webをSPAで作った
  • Reactは学習コスト高くないから良い
  • fluxフレームワークはいろいろあるけれどReduxに行き着いた

React/Reduxをよく調べていけそうだったのでプロジェクトにいれてみた。 しかし

コンポーネントで大事なこと

this.context

バケツリレーをせずに値を受け渡すことができる。 全部のビューで使うやつとかはcontextでわたしちゃうと良い。

  • UIにあわせたentityをつくってはいけない
  • あくまで概念として正しい最小単位
  • Storeの設計も自ずと決まる

まとめ

  • 正しいコンポーネントを積み上げねば、幸せはやってこない。
  • this.contextの活用 => DRYとDI
  • エンティティと型 => 見通しをよくする

感想

CSSとcomponentが一対一」ってところにはいまいちぴんとこなくて、以下の記事で言われていることの方が僕はすんなり納得できる。

morishitter.hatenablog.com

ReactコンポーネントCSSコンポーネントの粒度は同じにならないと思っていて、CSSコンポーネントの方がJSのコンポーネントよりも多くなる(細かくなる)。 JSとCSSコンポーネントが1対1に対応しないので、CSS ModulesやRadiumなどのCSS in JS系ツールのアプローチは合わないと思っている。

今更ながらなんだけれど、そしてみんなそうなんだけれど、なんで最近はみんな自らSPAが良いと思って手を出して、つらいつらい言ってるんだろうとそう思いました。


革命と秩序とSPA

@joe_reさん

内容

フロントの歴史

  1. Ajax
  2. Backbone
  3. 2way-binding
  4. virtualDOM

freeeのフロントエンド

  1. Backbone(SPAではない)
  2. ページ単位でBackboneでSPA -> メモリリークするしDOM操作大変だし辛い
  3. freee-mvc-framework -> 社内フレームワークの誕生(Backboneの機能拡張) -> それでもDOM操作辛い
  4. vueのVMを追加して2way-bindingして完全なSPAになる(vue on backboneだと...) -> 状態管理辛い
  5. 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が良いって聞いた。

github.com

あとはscaffoldどエラー検知は素晴らしかった。とても参考になる話。
会社単位でAngular2にこの段階で取り組むってすごいことだなあと思う。


コンテンツ配信とSPA

@konpyuさん

内容

noteをAngular 1.xで作っているのでその話。

現役でAngular 1.xだが

  • 機能や仕様が肥大化してどんどんカオスに
  • 超巨大directiveがいくつもうまれ
  • 低いテストカバレッジ、人による実装の違い
  • バイルwebで信じられないくらい遅い

=> 構成見直しの機運。まずは初期ロードをなんとかしないと。

  • DOMの数を減らす => デザインをなおしてDOMの描画をへらす
  • HTTP負荷を減らす => cacheしにくいものはwindow.PREFETCHにつめたり

結果、すげー早くなった(それでもまだ遅いけど)。

SPAで高速(に感じる)コンテンツ配信

  • 体感を早くする
  • 最初に枠組みだけを高速にロードして、準備ができたコンポーネントから表示
  • 静的なコンポーネントSSR
  • 出せるものから出す。総ロード時間に変化はないけれど体感速度は変わる

Reactでnoteのタイムラインを再現してSSRしたけど、実現するには実装が煩雑

HTTP/2

  • HTTP1時代のベストプラクティスが裏目に出る
  • facebook: 大量のアセットを一斉に落としにかかる様は圧巻!

まとめ

SPAはモバイルですぐに性能が悪化するので注意。初期ロードを早くする要件があるならDOM構築は必要なものだけ最初に。
コンポーネント化 + コンポーネントごとにSSR + コンポーネント単位の遅延ロード + HTTP/2 = よさそう

感想

以前にnoteをぼんやりと見てたらAngularだったことに気づいたのでAngularを使っているということは知っていたのだけれど(あとmozaic.fmでも言ってた気がする…)、その裏側で結構苦労したのだなあーと。

ただやっぱりSPAのモバイルで速度の問題が出るのはまあありがちなことだと思いつつ、しっかり対応してる話を聞けたのは良かった。
速度を早くするってのは、物理的な速度ももちろんなんだけれど、体感速度を早くすれば良いってのは本当にその通りだと思うので、その目線で考えてみるとチューニングの幅が広がりそう。


SPAと覚悟

@teppeisさん

内容

SPAとは

ブラウザにとっては1枚のページ。そこに様々なハックを駆使してリッチな体験を提供するアプリケーション。
ブラウザの標準的なUXに満足できないから自分でつくる。
SPAとはブラウザを超える体験を再実装する覚悟 => その覚悟がないならSPAを選択するべきでない

例えば遷移

ユーザーの気持ち

A => B => C 戻る C => B => A

作ったSPAの動き

A => B => B' 戻る B' => A

ページナビゲーションの設計とかもSPAでは全部自分で考える。

  • いつヒストリに積む/復元するか
  • どこまで状態を記憶するか
  • dispose問題/投げてるXHRどうしよう

SPAゆえの考慮事項

  • 初回ロードパフォーマンス
  • パーマリンク
  • SEO(クローリング対策)
  • スクロール制御
  • 各種オブジェクトのライフサイクル管理(オブジェクトの樹苗が長くなるのでいつ破棄するのかとか)
  • ページ間親子間の協調

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でつまづいたところ

@nacika_insさん

内容

一人でSNSを作った話。構想4年。OSSで。

フロントエンドだけ完成したので見せますよ。 技術スタック: Angular2, TypeScript, webpack, Node.js, system.js

認証機能で困った

  • Angular2では状態をcomponentが持つ
  • serviceは持たないようにしたい
  • つまりcomponentが認証情報を持つ?
  • 形のないものにcomponentを使うのがいや

bootstrapでたちあげるときに認証用のserviceにわたす

感想

初めての発表の舞台ということで大分緊張されていた。しかし、その一歩を踏み出したことってのはとても尊いことだなあと。
僕はまだ踏み出せていないので、まぶしい感じで見ていた。

SNSを作っている途中なので見てくださいって内容でした。
Angular2のチュートリアルしかやってない僕でもぎりぎり理解できた。良かった。


1pxをめぐる戦い

@yoshiko_pgさん

1pxをめぐる戦い - @yoshiko_pg

内容

縦並びのリストのborder-bottomに1pxつけてるときの一番下のliのborder-bottomだけ消したいけど状況的に色々厳しいときにCSSでどう頑張るかっていう話。
とにかくCSS力の高い話だった。スライドが全て。

感想

CSS深い。


SPAでのセッション管理とセキュリティ

@uryyyyyyyさん

qiita.com

内容

  • 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で書いてるので詳しくはそちらで。

qiita.com

まとめ

途中で休憩で軽食食べさせてくれたり、あと普通にそれが作ってくれたやつでとてもおいしかったり、途中のフィットネスタイムみたいなやつとか、顧客満足度を上げる努力がとても良かった。
FiNCでやるイベントはどんどん参加したいと思った。

内容としては、僕のSPAに対しての覚悟が問われた1日だったという感想が頭の中を占めてしまった。
本当に色々なことを疎かにしている中で、流行っているという理由でSPAをしてしまってるだけではないだろうかとか自問自答しちゃったり。

とにかくがむしゃらにコードを書こうというそういう意識を持てたことはとても良かった。
この連休中はひたすらコードを書く。

こちらからは以上です。とても楽しい勉強会でした。