「第65回 HTML5とか勉強会 ー React最新情報」レポ

第65回 HTML5とか勉強会 ー React最新情報に行ってきました。
レポといっても自分がメモしたことと、所感くらいです。
まとめが高速アップされてましたのでもっと詳しく知りたい方はこちらをどうぞ～。

• 第65回 HTML5とか勉強会 ー React最新情報 に行ってきたメモ #html5j
• togetter

HTML5カンファレンス楽しみ(´∀｀*)ｳﾌﾌ

The state of React.js 2016

The state of React.js 2016 by koba04

Who Uses
ReactといえばFacebookですが、ほかにもいろいろなところが使ってるそうです。

• Facebook：コメントのところとか
• Instagram：全体的に使ってる。あとGraphQLも
• Netflix：テレビのレンダラも使われてる
• airbnb：（エアビーエヌビー読み方知らなかった／(^o^)＼）
• Twitter（mobile）：Reduxとreact-router
• Uber：（私まったく使わないので知らなかった(；ﾟдﾟ)ｺﾞｸﾘ…）
• AbemaTV：（挙がらなかったけど、このあと話あるからね！）

ライブラリとしての、サービス・実装との相性なんかもあるかと思いますが、やっぱりこういうサービスが多いんですね。
それか、こういうサービスを運営してるようなところじゃないと、Reactを実務で使えないのか…
どっちもか…

Why

• たぶんみんなパフォーマンス向上とか求めてるんじゃないよね
• メンテナブルUIを求めて

Component

• Function Component
• つまりStatelessFunctionComponents(SFC)
• 純粋な関数として作る
• ES2015 Class Component
• これはコンストラクタ内でやろうぜ！
• High Order Components(HOC)
• React.createClassオワコン
• mixing→HOCやれ
• autobinding→ES Class Fields & Static Properties
• shouldComponentUpdeteには罠がある
• react-addons-perf使うと無駄な処理してるとこ見つかる
• why-did-you-updateとかもあるよ

Props

• setProps→消えた
• replaceProps→消えた
• propTypes→TypeScript使え（まじかよ…）

State

• batchedUpdatesにも罠がある
• unstable_batchedUpdatesっていうのあるよ

このへん全然話についていけなかった…

ReactElement

• テキストの暗黙ブロックをspanにしてたのアレやめたから。
• data-react-idもやめたわ。

ﾜｰｲヽ(ﾟ∀ﾟ)ﾒ(ﾟ∀ﾟ)ﾒ(ﾟ∀ﾟ)ﾉﾜｰｲ

そうそうこれこれ！Reactで吐き出されるHTMLがきれいなところが大好きなんだけど、このふたつがモヤモヤしてたからほんとに嬉しい！

Ref & DOM
前項の感動に打ち震えていてすべて聞き逃しました(；´∀｀)…うわぁ…

Context

• ライブラリとかが使う用API
• 使うなとは言わないが自分で使うことはあまりない

Test

• ShallowRendererｷﾀ――(ﾟ∀ﾟ)――!!
• airbnb/enzyme
• simulate(‘click’)とかできる！すごい！

ESLint
使おうね。
TypeScriptとかでもそうなんだけど、そもそものエラーを事前に検知するのがいい。
わかる。それはわかる。
ただ、React（view）っていう意味だと私の場合、できあがったHTML自体をバリデータにかけないと気が済まないから、「Lint通ってるしー動いてるしー何がいけないのー？」みたいな感じでHTML/CSSを壊してほったらかしにするエンジニアは許さん。
許さんぞぉぉぉ

ReactNative

• もちろんFacebookアプリでも使われてる
• リポジトリ活発
• サードパーティーコンポーネントも増えてる
• just a renderer
• 今はviewだけをReactNativeにしてる
• 本体はWebと同じ
• 本体のReactに修正入ったら同時に修正されるから素敵じゃん？
• makeit.com参考になるよ！

Architecture

• react-basic
• Tiny React Renderer→JSON吐いてくれる

Future

• 今何が起きてるかとかはcore-notesチェック
• React Coreをシンプルにしていく
• 今Viewがでかいときも全部同期して重いけど、priorityつける実装を始めてる

メモだけでえらい量になりました。
本体だけじゃなくて周辺の技術も多すぎて全然ついていけてないです(´ε｀；)ｳｰﾝ…
VisualStudioでやるならとか関係なく、もうTypeScript必須な感じなのかなぁ
TSX…か…

なぜReduxを使うのか

なぜReduxを使うのか by Yuki Kodama

• Googleトレンドでも右肩あがり
• 背景にあるアイディアを学ぼう

Fluxは何を解決したか？

• DispatcherをとおってActionをStoreに
• バケツリレーはいらなくなった
• でもStore間はデータやりとりできない
• 親コンポーネントをわざわざ作る
• Actionを通るのでそこを見ておけば問題を発見しやすい
• まだつらい

Redux

• ReducerがActionから受け取ってStateを新しく作りViewに伝える
• Store(State)
• Reducer
• Middleware
• Store Enhancer
• …とかいろいろ出てくるけど全部Storeの住人だよ
• SingleStore,SingleState
• それを複数のReducerで構築する
• 状態管理だけやってくれる
• あとは好きにMiddlewareとか使えよっていうこと
• 入れ子は可能
• だけどお勧めしません

非同期処理

• redux-thunk使うとpromiseチェーンもできる
• でもActionCreaterに押し込むのヤバイ
• redux-saga良い
• yield call()でAPIの処理が終わるの待ってくれる

今やってるやつは$.ajaxを使ってるから、これをどうにかしたいんですよね。
FetchAPI使うか、redux-saga導入するか…
せっかくだから何かに置き換える作業しておきたいですね。
FetchAPIはIEがNGなのと、Edgeも14以降じゃないとたしか使えないのでこれを業務で試すのはまず無理だ(´・ω・｀)

Relay

relay by Kazuhito Hokamura

• サーバサイドはGraphQL
• クライアントサイドはReact
• Relayはこれを組み合わせたフルスタックフレームワーク
• GraphQLはRESTとかRPCと同じレイヤー
• リクエストに対してレスポンスがほぼ1対1で紐づいてる
• ほしいフィールドだけ選んだりするのも簡単
• Relay.QLの中身なんにもない
• 裏ではBabelでコンパイルしてる
• 型チェックあり
• Relayわりとつらみある
• そもそもGraphQLの知識と、サーバが必要
• 結局Babelいる
• 参考資料やアプリが少ない
• ページネーションのやり方わかんね
• でもRailsみたいになってくれるかもって淡い期待

GraphQLは聞いたことあるけどよく知らなかった。
Facebook製でReactとも深い関係にあるんですね～。
データの取り方がすごくスッキリしていてよさそう！しかしこれ使う自分自身がフルスタックじゃないと一人でモックすら作れなそうだ(；´Д｀)

How to style React components

How to style React Components by @Quramy

• みんながUIコンポーネントに期待することって
• カプセル化されてるとか
• 見た目と振る舞いが揃ってるとか
• CSSって壊れやすいよね？
• 他の誰かが上書きして簡単に壊れる
• Component内でも同じclassName出てきたり階層が異なると大変なことになる
• Globalなんだもん

いやいや、まてまて、まって、壊すやつが悪くない？？？
って思っちゃうんですが、同じように思ったデザイナーさん落ち着いてください。
たしかに既存のスタイル指定やclassをgrepもしないで勝手に新しいセレクタ生み出したりするやつが悪いと思います。
HTML/CSSを理解しないで適当にいじって壊すやつが悪いですよ。

でもここで言ってるのはCSSクソだよねとかってことではなく、そういった適当な人間が起こすミスを防ぐ方法もないし、設計で解決できそうな部分もあるということですね。

CSS in JS

• スタイルのオブジェクトをJSで定義
• 要素のインラインスタイルにセットされる
• Component内にスタイルを閉じ込めることができる
• JSの関数でスタイルの合成とかもできる
• JSにすることで、不要コードの検出とかも簡単
• デメリットは、疑似要素、疑似クラス、メディアクエリとかが使えない
• それをサポートするライブラリもあるにはある
• Radiumとか

私個人的にはこれはもう、ないなって感じです…

なによりもまず、これ、デザイナーが修正できるの？
ってなりますね。
デザイナー（～HTMLコーダー）までの作業と、フロントエンドエンジニアの作業を完全に切り離す必要があるんじゃないでしょうか。
完成形のHTML/CSSを書き上げてもらってから、それをコンポーネント化するって感じ。
ウォーターフォールになりそうで嫌ですね。

逆に、JSバリバリ書けるWebデザイナーさんがいるなら、コンポーネント化まで全部任せちゃえますよね。
チームの構成次第ですがどっちにしてもこれは完全にエンジニアさんがCSSと闘うための実装方法な気がします。

あと…

ライブラリあるって言われても、完全に実装できるわけじゃないですしね。
CSSの疑似要素や疑似クラス、メディアクエリとかアニメーション使うことのメリットが消えちゃうんですよ。
それをライブラリ入れてどうこうしたり、その部分だけjQueryライブラリ入れちゃおうぜ～みたいな人が出てこないことを祈ります。
もしそうなると、文書構造上不要な要素を増やさずに装飾できたり、JSであれこれ処理しなくてもアニメーションさせられる、そういうのを覆して、結局全部JSでやってた時代に戻っちゃいますからね。

それからインラインスタイルというのも、すべてのタグにalign=”center”とかつけてた時代を彷彿とさせます。
今まではstyleにまとめたり、外部CSSファイルにすることで余分なソースを減らしたりしてたのに、これでHTMLのソースが膨大になってしまいます。
昔に比べたらブラウザの性能も上がって、通信環境も良くなって、体感の差はあまりないのかもしれませんが、これじゃなんのために美しいコードを書いたり必死にminifyしたりしてるのかわからなくなります(´・ω・｀)

そこで次に登場するのが…

CSS Modules

• CSSファイルはいつもどおり作る
• JS側がそれを見て自動でclassを定義する
• 定義したclassがES 2015 Modulesみたいになる
• Module bundler使ってCSSファイルのclassを隠せる
• class同士の合成もできる
• Sassの@extendとか、@apply ruleみたいな感じ
• postcss-modules使うと元classと生成classの対比JSONが吐き出せる
• 他の言語（Rubyとか）からも使えるよ

CSS in JSに比べるとだいぶマシです！
でも正直、CSSを書ける人間にとっては、別に普通にCSSファイル読めばいいじゃんって感じです。
だってもとのCSSファイルが「壊れた」ら、その内容を見てclass生成するんですもんね…

CSSは壊れるんじゃない。
人間が、お前たちエンジニアが壊してしまうんだ。

Atomic Design powered by React

Atomic Design powered by React @ AbemaTV

• Web版フロントエンドの話
• 先にスマホアプリが進んでいた
• Web版の仕様ない（あるある）
• 画面デザインない（あるある）
• リリース日は決まってる（あるあるある）
• 空気読んで開発はじめる（あるあるあるあry
• 画面仕様の変更に対応しやすいコンポーネント粒度ほしい
• チームで明確にしたい

ATOMIC DESIGN

• Atoms（原子）：
  ボタン、アイコン、チェックボックスなど、それ以上分割できないコンポーネント
• Molecules（分子）：
  チェックボックスにラベルがついたものとか、ボタン＋アイコンとか、メディア（イメージ＋テキスト）とか
• Organisms（有機体）：
  ヘディング・アイコン・メディアを組み合わせた記事情報だとか、グローバルナビなんかもそう
• 個人の感覚に依存しない粒度決定
• コンポーネントを再利用しづらくなる原因は、特定のデータ構造に依存しちゃうこと（デザイナーが考える部分もあるな）
• コンポーネントをstatelessにして、純粋関数的にする
• コンポーネントのリスト作っておいて管理する
• CAではデザイナーはコード書いてなかったけど、AbemaTVではデザイナーさんがコード書くようになった

ATOMIC DESIGNいいですね！
手法に名前があるってのがいい。
コンポーネントのリストとかも。

わりとちゃんとしたWeb制作会社にいたから大手企業のサイト作るときなんかは必ずパーツリストを何ページも用意していたんで、やってないところには浸透させたかった。
そういうのがない現場でそういうものを作ろうとしても、既存の設計がそもそもバラバラだからパーツが共通化できてなくて泣いた思い出。
新規プロジェクトのときはそういうものも作ったりしていけるんだけどね。

コンポーネントっていう概念をデザイナーやコーダーに認識させるっていうのに苦労したし、せっかくコンポーネントっぽく作っておいたパーツリストも、エンジニアさんがちゃんと確認してくれなくて適当にほかのパーツのソース持ってきちゃったりとか。
いろんな思い出がよみがえってきた…( ﾟ ρ ﾟ )

サイバーエージェントさんではこれまでデザイナーさんがコード書いてなかったっていう話なんですけどね。

私ガールフレンド（仮）の微課金ユーザーなんですけど、あれ、今でこそChromeで快適にプレイできるんですが、以前Androidの標準「ブラウザ」ではとても遊べたもんじゃなかったんですよね。
サーバとかスクリプト部分の問題もあるかもしれませんが、画像がものすごく多いんです。

たしかCAの技術ブログで読んだんですが、単調なブロックの積み木構造になっていて、なぜそうしているかというと、更新作業が頻繁にあるので、スキルの差異に影響されないように誰でも簡単に修正ができるようになってるとかだったと思います。

まあわかります。
画像で幅きっちり固定に組んでしまっておけば、画像の差し替えするだけで崩れるってことはないですからね。

そこでたとえばボタンをCSSで描画するとかしないで、画像だったりします。

あと課金ゲームなんでしょっちゅういろんな数字が表示されるんですね。
あと○日とか、ポイント○○pt、とか。
その数字が、1文字ずつ画像に置き換えられてたりとかします。

そりゃ重いです…

デザイナーがある程度コード書けたり、チーム内でHTML/CSSのスキルレンジがもう少し高いところで絞れていれば、もっとパフォーマンス良くできそうにも思えるんですけどね。
ただああいうゲーム、どう考えてもリファクタリングする余裕なさそう。

感想

すごく勉強になりました～。
全部知ってて飽きちゃうな～っていう内容よりも、若干ついていけないくらいのほうが、あとで調べたりして勉強するのでいいかもしれません。
ただやっぱり聴き逃してしまうこともあるので、スライドだけじゃ思い出せない部分とかあとから知る方法が欲しいですね。
むしろ、スライドに書いてないところの話の内容のほうが重要だったりしますし！
やはり動画配信あると嬉しいです。

今回ライブ配信されていたので結構多くの方がこの内容を聴いたんじゃないかな～と思います。
ちなみに会場は約200人ほどいて席はほとんど埋まっていましたが…
女性は1桁しかいませんでした！Σ(´∀｀；)

み、みんなもっとReact楽しもう…よ…！