Firestore のセッティングではまった
GW前くらいから朝活の記録をする時間がなかなかとれなくていたのですが、細々と活動は続けています。。
今はりあクト！シリーズ3作目をやっています。
Firestore のセッティングではまった
本の通り順調に進めていましたが、 1-2. Firebase プロジェクトの作成と初期化 のところで、 Firestore Setup でエラーがでました。
=== Project Setup ? Please select an option: Use an existing project ? Select a default Firebase project for this directory: mangarel-demo (mangarel-demo) === Firestore Setup ? What file should be used for Firestore Rules? firestore.rules ? What file should be used for Firestore indexes? firestore.indexes.json Error: Error fetching Firestore indexes
ちょっとググってみましたが、これはGCPコンソールで - Firestoreの設定を Datastore モードから Native モードに変更 - API の有効化 のふたつを実行する必要がありました。
おなじところではまる場合は debug オプションをつけて Firebase 初期化をおこなうと、ヒントが得られます！
$ firebase init --debug
デバッグをもっと簡単に
「りあクト！」続編を読み始めました。
React Developer Tools の使い方のところでちょっとはまったのでメモ。
サンプルコードは yarn start でビルドとサーバーたちあげを行うようスクリプトが書かれているのですが、
これが「development モード」らしくて、
そのままだと Chrome の React dev tools が動かないんです。
「production モード」で起動してくれみたいなメッセージがでます。
ググってみたらデフォルトが production モードで yarn run dev とかすると devlopment モードになるみたいな情報は見つかったんだけど、
サンプルコードのスクリプトがどこで明示的に dev モードを使用しているのかわからなかった。。
ので、 yarn run build したときに表示されるメッセージの通りに起動しました。
$ yarn run build $ serve -s build
しかしいざ Chrome Dev Tools で開くと、本で説明があるように表示されなくて、これはもしかしたら Chrome Dev Tools がアップデートした可能性。。
今日はここまで！
.gitignore がなかった（/node_modules を push していた）・第9章まででいったん読了とする
朝活続けていますが、こちらをマメに更新していなかった。。
サンプルコードをいじっているとき Git がやたら重いなぁと思っていたら、
.gitignore がなくて /node_modules を含めてしまっていたことが原因とわかりました。
なんでだろう？と思ったときにちゃんと調べないといけないな、と反省。
本文の方は第9章の React Router の部分まではざーっと読んだので、今回はここまででいったん読了として、 （今のところReduxを業務で使っていないので…） 明日から続編を読もうと思っています。
React Router の使い方
サンプルコードを写経途中。
BrowserRouter
index.tsx で <App /> を <BrowserRouter> というコンポーネントでラップすることで、
下の階層のコンポーネントで HTML5 の History API を利用した各種 の機能が使えるようになる。
ReactDOM.render( <BrowserRouter>
<App />
</BrowserRouter>, document.getElementById('root'),
);
Helmet
どこからでも HTML ドキュメン トヘッダが上書きできるようになるので、ページごとに <title> がセットできるようになる。
link
Effect Hook でライフサイクルを扱う
Effect Hook でライフサイクルを扱う
クラスコンポーネントのライフサイクルメソッド componentDidMount(), componentDidUpdate(), componentWillUnmount() に相当する機能を実現するもの
クラスコンポーネントのライフサイクルメソッドは、「このタイミングでこの処理をする」という発想だったのに対し、Effect Hook では「この処理はこのタイミングとこのタイミングでやる」という発想になっている。
useEffect()(() => {
doSomething();
return clearSomething();
}, [watchVar]);
useEffect()の第一引数に、引数なしの関数を設定すると、コンポーネントのレンダリングの直前に実行される（ここではdoSomething()）useEffect()の第二引数は、変数の配列で、省略可能。配列の中の変数が、前回のレンダリング時と変わらなければ、第一引数で渡された関数の中身の副作用処理実行がキャンセルされることになる- コンポーネントのアンマウント時にreturn 文が返される（ここでは
clearSomething()が実行される） - 第二引数を省略すると、レンダリングのたびに
doSomething()が実行される - 第二引数を空配列にすると、
doSomething()は初回のレンダリングでしか実行されない
こちらのほうが、コード量は減るかもしれない？
というわけで早速書いてみました。
Hooks・State Hook で Local State の管理・Git が重たいような気がする
Hooks
Hooks は様々な React の機能をクラスを使わずに利用 できるようにするもの。 Local State とか Lifecycle とか。
この Hooks の発表が React Conf 2018 の基調講演のなかでされたということなんだけど、ここでずいぶん流れが変わってしまっているんだろうなぁ。
それ以前のコードとか、技術書とかに思いを馳せる。
State Hook で Local State の管理
いつものようにサンプルコードを写経しました。といっても今回はすでに書いたコードを Hooks を使って書き換えただけ。
しかし本文にもあるけれど、行数減るし、こっちのほうが見通しがいいような気がします。
Git が重たいような気がする
ところでサンプルコードをコミットしたりしていて気になったので、私用環境の Git がなんか重い？遅い。
ファイルが多いから単純に処理に時間がかかっているんでしょうか？
リポジトリサイズが大きくなると、動作が極端に遅くなる
なるほど。しかし create したばかりの React app が大きいとは思えない…
関数コンポーネント・コンポーネントとコンテナ
関数コンポーネント
今後はクラスコンポーネントではなく関数コンポーネントを優先して書いていく流れ、とのこと。
以前書いたクラスコンポーネントのコードを関数コンポーネントに書き換えてみた。
コンポーネントとコンテナ
Presentational Component を「コンポーネント」、Container Component を「コンテナ」と呼ぶことが多いらしい。
クラスと関数、とはまた別の側面の分類。
本文より一部抜粋↓
| Presentational Component | Container Component |
|---|---|
| 「コンポーネント」 | 「コンテナ」 |
| 「どのように見えるか」に関心をもつ | 「どのように機能するか」に関心をもつ |
| データやふるまいを Props として一方的に受け取る | データやふるまいを他のコンポーネントに受け渡す |
| 自身の状態はもたない（UIの状態はのぞく） | しばしばデータの状態をもつ |
| データの変更に介入しない | しばしばデータの変更に介入して、任意の処理をおこなう |
| ProsやFunctionalみたいなコード | LocalStateみたいなコード |
React らしいきれいなコンポーネントの作りかた
- 関数コンポーネントで見た目だけを整えた Presentational Component をつくる
- それをインポ ートして Hooks や HOC で必要な機能を追加していって、別途 Container Component をつくる
