2020.7.16 Nkzn
- 中川 幸哉 / Yukiya Nakagawa
- Nkzn / なかざん
- 京都とあまり関わりがないように見えますが、天皇家・公家の流刑地として人気の佐渡島がある関係で、佐渡島には京都由来の文化やなまりが今でも残っています
- ところで新潟県はラーメン激戦区です
- 私もラーメンが好きです
- 自宅の近所に第一旭の暖簾分けがあり、ラーメン好きとしては大変お世話になっております
- 今回も本当は京都に行ってラーメンを食べたかった
- 本当に食べたかった
- 今日は個人事業主として来ましたが、普段はウォーターセル株式会社で農業支援システムのアグリノートというのを作ってます
- 京都の九条ネギ農家さんにも熱心なユーザーさんがいたりします
- Android担当をするために入社した創業メンバーです
- サブシステムや派生システムでクライアントを全方位対応する内にJS方面のスキルが育った
- Reactは2015年にCordovaでiOSアプリを作るときに採用したことをきっかけに、時代の荒波に揉まれながらやってきた
- 最近だと技術書典WebサイトをReactの関数コンポーネント + React Hooksでリプレイスした
- AngularJS(Angular v1)は2015年ごろにPoCである程度触った
- 技術書典WebサイトをAngular(v8?)からReactにリプレイスした経験のおかげで、Angularもそれとなく読める
- 会社のReact導入前の2013〜2014年ごろがCoffeeScript + Backbone.Marionetteで、横目に見ていたので横目に見ていた程度の話しかできません
- 会社でRuby on RailsをAPIサーバーとして使っており、開発で困ったときに実装を読みに行ったりするので、ほんの少しだけRailsの話題についていけます(ただしレールから外れている)
- 第一部:座学
- 広く浅くやっていきます
- 「こういう分野があるよ」「乱立しているように見えるけど歴史的経緯を踏まえるとこれが王者だよ」といった話を中心に行います
- 第二部:ハンズオン
- https://github.com/Nkzn/react-hands-on-mfk をクローン
- npmとvscodeで進めていく想定で作りました
- READMEに手順が書いてあるので進めていく
- 途中状態のプロジェクトも用意してあるので、よくわからなくなったら次の手順のプロジェクトを眺めてください
- ECMAScriptに新しい文法を提案したい場合は、必ずBabelを通すことになっている
- https://tc39.es/process-document/
- https://azu.github.io/slide-what-is-ecmascript/slide/12.html
- Stage 2以降はBabel Pluginの実装が提供されるので、新しい文法を一足先に利用したい場合はプラグインを入れると良い
- TypeScriptはStage 3になった仕様しか取り込まないので、新しすぎる文法を使う場合は注意が必要
- プロポーザルはGitHubで管理されている
- React Nativeはクロスプラットフォームモバイルアプリ開発の夢を見るか #DroidKaigi
- p24からVDOMの解説がある
- なぜ仮想DOMという概念が俺達の魂を震えさせるのか - Qiita(Virtual DOM Advent Calendar 2014)
- 仮想DOMで魂が震えてから一年、仮想DOMとFluxの今 - Qiita(Virtual DOM Advent Calendar 2015)
- Reduxが王者となるまで「俺が考えた最強のFlux」が乱立した
- Redux = Flux + Reducer + Middleware
- アプリの状態管理を安全に行うためのFluxとRedux:CodeZine(コードジン)
- Single Source of Truthを「全部Storeに置け」と解釈してしまうアンチパターンがある
- redux-sagaというGeneratorモリモリの異世界へ転生してしまった件について
- なんだかんだで周辺ツールが一番充実しているのはReduxなので、何かFluxが欲しい場合はReduxを軽めに使うと良い
- いまここ
- React Hooksの使い方を学ぼう~関数コンポーネントの状態管理を行う:CodeZine(コードジン)
- 小さな状態管理がやりやすくなった
- 関数コンポーネントだけでもシステムが組める
- クラスコンポーネントは継承や副作用という、現代のプログラミングパラダイムにおけるプログラマーの苦手ポイントを的確に濫用させる誘惑に満ちているため、鋼の心を持っている人以外は使わないほうがいい
- ライフサイクル(
componentDidMount
など)を細かく制御したい場合には今後も有用だが、ほとんどの場合上記デメリットのほうが勝るはず - JSXやVirtual DOMツリーから見れば、「名前」「props」というインターフェースさえあれば使えるので、クラスでしかできないことはライフサイクル制御くらいしかないかも
- ライフサイクル(
- Virtual DOMに更新があったツリーと更新がなかったツリーを適切に検知させることができれば勝利
- とにかくChromeにReact Deveveloper Toolsを入れるんだ
- 正直あんまり詳しくないので記事読んでもらったほうがいい
- Nkznが常に気をつけているのは↓くらい
- リストにはkeyをちゃんと付ける
- 大量のデータがある場合は画面外を描画しない
- propsに渡す値(参照)が毎回変わってしまうことを避ける
- propsが変わると再描画対象になりやすくなるため
- カスタムフックから外部に出す値は、基本的にメモ化する(
useMemo
やuseCallback
を噛ませる)
- DOMツリーにスタイルを適用してレイアウトや装飾を施していくという基本方針は従来と同じ
className
というpropsがDOMのclass
属性に翻訳されるため、CSSファイルからスタイルを当てることもできる-
function Text(props) { const style = { color: 'red', }; return ( <div style={{ height: '16pt' }}> <span style={style}>{props.label}</span> <div className="my-label success">{props.message}</div> </div> ); }
- CSS-in-JS
- オブジェクト形式でスタイルを記述して、オブジェクトのまま
style
属性に突っ込む - 条件分岐で装飾を切り替えるのが非常に簡単
- DOMに落とし込まれた時点では
style
属性にベタ書きされる
- オブジェクト形式でスタイルを記述して、オブジェクトのまま
- いくらか方向性は見えてきたものの、デファクトスタンダードが定まっていない
- Scoped CSSの概念は大規模開発においては必須
- いくつかのパターンがある
- パターン1:CSS-in-JSの効率化
- ビルド時にCSSファイルの生成とclassNameの割り当てを行う
- https://emotion.sh/docs/introduction
- パターン2:CSS記法で書きたい
- パターン3:CSSファイルで書きたい
- ESLintが無双の王者になったので何も気にせずにESLintを使いましょう
- JSLint, JSHint, TSLintなどなどは皆死にました
- TypeScriptもESLintでチェックする方向で概ね勝負がついた
- recommended系を入れておけば標準的なやつがだいたい入るので便利
- https://eslint.org/docs/user-guide/configuring#using-the-configuration-from-a-plugin
.eslintrc
の例-
{ "plugins": [ "react" ], "extends": [ "eslint:recommended", "plugin:react/recommended" ], "rules": { "react/no-set-state": "off" } }
- TypeScript向けにはparserの設定があるため少しだけ煩雑
- Lintルールはベストプラクティスとアンチパターンの宝庫
- なぜ存在するのか調べると歴史的経緯を学べてお得
- Prettierが王者になりました
- 良い感じに揃えてくれる(好みに合わない人はいるかもしれない)
- JavaScriptもTypeScriptも整えてくれる
- Prettierで整形した結果がESLintに注意されるという不幸が多発したため、Prettier側が公式ESLint Pluginを出した
- テストランナー
- describe, itなどを書くためのやつ
- 所定の記法でテストコードを書いておくと順次実行してくれる
- mochaとか
- アサーションライブラリ
- assertとかを書くためのやつ
- テスト結果のエラー表示をわかりやすくしてくれたりする
- chaiとか
- Reactに限っていえば、全部入りテスティングフレームワークのJest一択
- https://jestjs.io/ja/
- Facebook製なので……
- 好みのライブラリを組み合わせるのも良いですが、やっぱり全部入りは楽です
- Reactコンポーネントが生成したVirtual DOMのダンプ(JSON形式)をテスト対象にするための機能(snapshot)もあるけど、限られた状況でのUIテストとして有効なだけなので、あまりオススメできない
- テストの方針としては「リファクタリングして頑張ってReact依存を切り離したモジュールを作ってテストする」という、ありふれた話になりそう
- 動くドキュメント
- 特定のpropsを与えたときの見た目をWebページ化できる
- ロジックを実装するよりも画面部品を作っていくほうが得意な人の主戦場になったりする
- 新規サービスの実装中に存在してくれるとそれなりに便利
- アンチパターンとして、運用フェーズに入った瞬間に見る目が減るのでメンテナンス対象から外れて陳腐化する
- Visual Regression Test(CIでスクショの差分チェックをするテスト手法)の分野で価値が再評価されている