東京Node学園祭 2016(2日目)に行ってきました。
参加したセッションは下記。資料公開されてるものは資料リンクつけてます。
- Why to Standardize your READMEs
- Vue.js 2.0 サーバサイドレンダリング
- React + Reduxを使った大規模商用サービスの開発
- ZEIT謹製 "Introducing Now and Next.js"
- PostCSS: Build your own CSS processor
- JavaScript による並列処理:共有メモリとロック
Why to Standardize your READMEs
リポジトリが増えてREADMEのメンテが大変になるのどうにかしようみたいな話。
READMEの標準化。
- standard JS
-- インターナショナライゼーション(他言語対応?)はされるのか?
STANDARD-READMEで楽になると思ってる。
Vue.js 2.0 サーバサイドレンダリング
このセッションで人が増えて「おっ!」となる。
内容はスライドに書いてあることがほぼ全て。
Vue2.0での仮想DOMとSSRの仕組みについて大変詳細に書いてあります。
- Vue.js 2.0からはプログレッシブフレームワークがコンセプト
- virtual DOMアーキテクチャを採用
React + Reduxを使った大規模商用サービスの開発
前セッションのVueよりさらに人が増えて室温が1℃ぐらい上がった気がする。React人気を見た。
【スライド資料】React + Reduxを使った大規模商用サービスの開発
【togetter】React + Reduxを使った大規模商用サービスの開発 #nodefest #nodefestB
サービス - ブッキングテーブル
- 飲食店の予約に特化したサービス
- 今、確実に予約できる店舗しか載ってない
- 掲載店舗数が競合の10倍なのが強み
- WEB版は明日(2016年11月14日)公開
ブッキングテーブルWEB版
- 流入時はSSR
- そのあとブラウザではSPA
- Universal(Isomorphic)JSなWEBアプリケーション
数ある飲食店検索サービスの中でも、もっさりしない、使い心地を追求。
React/Reduxとは
- 実装するのは仮想DOMに対する変更
- 実DOMの更新はReactの中でおこなう
Redux
- stateの管理を容易にするためのフレームワーク
- globalな単一のstate
- redux middlewareが大事
React/Reduxで失敗しないための3選
❶ Tansition(画面遷移時に起こっていること )
- 実装前に開発者全員が理解しておく必要ある
- onEnterはreplaceStateを使う
onEnterのタイミングではURLが切り替わっているためpushだと履歴が残る
- onEnterはreplaceStateを使う
- router-middlewareのdata fetch戦略
- 全data fetchが終わるまでRouterContextのrenderまたせる
- data fetachの後、終了時にイベントが発行しておくといい
- 画面遷移時のデータ検索をどこでやるか
- iPhoneの画面スワイプでの戻る/進む問題 → 一瞬戻る前の画面がチラつくことがある
- popState時にRouterContextのrenderを止めていると発生
- 画面スワイプした瞬間、まだ戻り元の画面がunmountされていないため
- 細かいところだからそんなに気にしなくても良いかもしれないが、
うちはUXデザイナーが結構細かいので、できる限りを対応した。
でもChromeは無理そう。
- どこかを直すとどこかがおかしくなりやすい
- reduxはglobal stateで古い情報が残っているので注意
- スマホは端末依存の挙動不審が結構あるので最初から実機確認する
❷ Code splitting
- minifyして2MGとかになった。やってられん大きさ
- 変更箇所以外jsのhashを変えずに、ブラウザキャッシュを最大限に利用する
- 画面ごとのJS分割
- react-routerとwebpackのreauire.ensureを組み合わせて実現可能
- 画面遷移時のJSダウンロード
- 分割したJSをSSR時に出力するhtmlの
<script>
に含める
- 分割したJSをSSR時に出力するhtmlの
- Script Load error
- webpack1.x系だとreauire.ensureのscript load error が拾えない → 画面停止する
- script load error handler使う
- 3rd Partyの分割
- モジュールID問題 - OccurenceOrderPlugin(true)を使うとentryに
- module IDの順番に気をつける
❸ SSR
- サーバではstateとcontentsで構成される
- SSRの有無に限らずクライアント側でのrenderは必ず実行する必要がある
- 不要なSSRが実行されないようhistory APIでの画面遷移を基本にする
パフォーマンスどうだったか
- RendertoString 60~80ms
- そこそこ重かった
- 何に時間がかかっているのか調べた → 自作のcomponentがお粗末な作りだと覿面に影響するようだ
じゃあSSR諦めるか?いや、UXの観点からもあきらめない・・・!
やったこと:①Partial Rendering
-
Lazy LoadではなくLazy Render使った
- RendertoString 60~80ms から 10~20ms に改善!
-
SEO的にはどうか?
- Fetch as Googleの結果
Partial Renderingでもスクロール以下含め全コンテンツ読まれる - PageSpeedInsightsの結果
普通のSPAは減点
- Fetch as Googleの結果
やったこと:②SSR Chache
- Partial RenderingとLazy Render
参考:③Composite Rendering
- 一定時間のリクエスト数に応じて当できてにRendering方式を切り替える
ZEIT謹製 "Introducing Now and Next.js"
途中から話についていけなくなりましたはい。
【togetter】ZEIT謹製 "Introducing Now and Next.js" #nodefest #nodefestB
- NextJS - 公開されたばっかり
SPAの問題点
- 初期表示が遅い
- ページが増えると他のページに影響する
SSRのメリット
- 初期表示のパフォーマンス
- SEO - SSRはSEOのためじゃない。性能を向上させるためのものだ。-
コード分割+遅延読み込み
CSS
-
glamorライブラリ
- JSのフル機能を使って スタイルが当てられる
- コンポーネントごとに独立 他のページに影響しない
- vendor prefixの自動付与
Linkコンポーネント
- HTMLのanchorと同じ
- クリックした瞬間にコンポーネントを取り込み
getInititialProps
Next.jsはReact知ってればすぐ使えるよ
Next.jsでデプロイを楽にする方法
- イミュータブルデプロイ
- 本番公開するときはには、分かりやすいエイリアス・ドメインを貼る
- URLが常に同じアプリの状態を占める
- 更新がロールバックが一瞬
- ステージング環境が必要なくなる
- オートスケール
- データの永続化
- Dockerfileサポート
- 静的ファイルサポート
microを使ったサーバ実装
nowはデプロイをシンプルにする
PostCSS: Build your own CSS processor
一応目当てだったのですが、特に目新しい情報はなく。API面白そうだから触ってみようかな、ぐらい。
内容はスライドに書いてあることが全てです。
- 会場アンケート
- PostCSS知ってる人多い・使ってる人はその50%ぐらい?
- PostCSSのAPI使ってる人はほとんどいないっぽかった
PostCSSとは
- CSSツールを作るためのフレームワーク、とか言うようになったりしてる
- Bootstrap v5でPostCSSになるかもよってよ
- ただのパーサー
- ASTを操作するためのAPIを提供
昔から似たようなのはあったよ。
- rework by TJ - Jade作った人。
- Custom CSS Processing
現在のPostCSSのバージョンは5。PostCSS v5。
PostCSS製ツール
- Autoprefixer
- stylelint
- Facebookもstylelintのプラグイン作ってCSSのルール作ってるらしい。
- style-lint-config-*
いろいろ設定ファイルあるよ - style-lint設定ファイルから、stylefmtでフォーマットできる
- CSSModules
- 「React:CSS in JS」 → media queryや擬似要素に難あり
- CSS Modulesチーム「CSSはCSSファイルに書きたい!」
- webpack使う
- css-loader、style-loader
- デフォルトでローカルスコープ
セレクタ名にハッシュをつけて衝突回避
PostCSS.partsでプラグイン探せるよ
プリプロセッサとしてPostCSSを使うメリット
- 必要な機能を選択できる
- カスタマイズが容易 コントリビュートしやすい
- パフォーマンスが良い
注意点
- cssnextは未来のCSSの先取りではない
CSSの仕様はそんなに薄っぺらくないし、CSSからCSSへのトランスパイルである以上、できることに限界はある - プラグインの依存関係に気をつける。読み込み順とか
- プラグインに何かあった時は、書き直す覚悟で
PostCSSのAPI
- ASTの構造
- PostCss in js
増える続けるCSS周りのアーキテクチャ・アプローチ
ツールに使われず、本質を解決するためにツールを使おう
JavaScript による並列処理:共有メモリとロック
専門的なところはチンプンカンプンで、かつ途中PCの充電が切れたが話の面白い方だった。
【Togetter】お互い譲り合い、助け合いが大事だよね……! 二人で生きていくこと(マルチプロセス)の問題を考える。 #nodefest #nodefestB
【スライド資料】JavaScript による並列処理:共有メモリとロック
mozilla - NPO
- 企業とは違う価値観でブラウザを開発してる
- 異なる価値観で開発することによりイノベーションが起きるのではないかと期待して心情としてやってる
[デモ]スクエニのゲーム「乖離性ミリオンアーサー」
- これJSだけで動いてるのすごくね?
- ゲームではとにかくスピードが求められる
- こういうのはメインスレッド固まって落ちないように、裏側でやりたいよねってゆー話。
OS - プロセススケジューリング
JavaScript - 非同期処理を行うことで、実行時間を他のプログラムに譲れる
僕は元々Cとかやってたんで、なんでJavaScriptはこんなにコールバックかいてるんだろうと思ってた
window.setImmediateっていうすごいAPIがあるようだ
→ 本当は1つの処理なのに記述が分かれちゃうのはちょっと嫌だね