Hooks・State Hook で Local State の管理・Git が重たいような気がする

Hooks

Hooks は様々な React の機能をクラスを使わずに利用 できるようにするもの。 Local State とか Lifecycle とか。

この Hooks の発表が React Conf 2018 の基調講演のなかでされたということなんだけど、ここでずいぶん流れが変わってしまっているんだろうなぁ。

それ以前のコードとか、技術書とかに思いを馳せる。

State Hook で Local State の管理

いつものようにサンプルコードを写経しました。といっても今回はすでに書いたコードを Hooks を使って書き換えただけ。

github.com

しかし本文にもあるけれど、行数減るし、こっちのほうが見通しがいいような気がします。

Git が重たいような気がする

ところでサンプルコードをコミットしたりしていて気になったので、私用環境の Git がなんか重い?遅い。

ファイルが多いから単純に処理に時間がかかっているんでしょうか?

techracho.bpsinc.jp

リポジトリサイズが大きくなると、動作が極端に遅くなる

なるほど。しかし create したばかりの React app が大きいとは思えない…

関数コンポーネント・コンポーネントとコンテナ

関数コンポーネント

今後はクラスコンポーネントではなく関数コンポーネントを優先して書いていく流れ、とのこと。

以前書いたクラスコンポーネントのコードを関数コンポーネントに書き換えてみた。

github.com

コンポーネントとコンテナ

Presentational Component を「コンポーネント」、Container Component を「コンテナ」と呼ぶことが多いらしい。

クラスと関数、とはまた別の側面の分類。

本文より一部抜粋↓

Presentational Component Container Component
コンポーネント 「コンテナ」
「どのように見えるか」に関心をもつ 「どのように機能するか」に関心をもつ
データやふるまいを Props として一方的に受け取る データやふるまいを他のコンポーネントに受け渡す
自身の状態はもたない(UIの状態はのぞく) しばしばデータの状態をもつ
データの変更に介入しない しばしばデータの変更に介入して、任意の処理をおこなう
ProsやFunctionalみたいなコード LocalStateみたいなコード

React らしいきれいなコンポーネントの作りかた

  • 関数コンポーネントで見た目だけを整えた Presentational Component をつくる
  • それをインポ ートして Hooks や HOC で必要な機能を追加していって、別途 Container Component をつくる

コンポーネントのライフサイクルを知るためののサンプルコードを写経

github.com

ちなみに私のコードはサンプルコードにちょっと変更を加えていて、 componentDidUpdate で timeLeft が 0 のときに「60秒たちました!」というアラートメッセージを出すようにしました。

しかし今の状態だと、カウンターには 1 が表示されているときにこのアラートが出ます。 なんとなく 0 のときに出て欲しいのに。

でもこのコードだと 0 が表示される前にリセットされちゃうんですよね。。

f:id:katoriexxxkatorie:20200323061946p:plain

reset だけじゃなくて start stop も実装してもっと細かく管理してあげるといいのかな。

私用環境を整理する・昨日はデザインパターン読書会だった

私用環境を整理する

先日この↑本を読んでいて、そうだなーと共感したのが 仕事のPCを私用のPCを分ける という話。

そもそも会社に行って仕事をする、ということは場所を切り替えることで意識を切り替えていたわけだけど、 場所が切り替わらなくなった場合、マシンを切り替えるといい、ということ。

本当にこれはそうでそのように実践しているわけですが、

つまりセットアップもそれぞれでしています。

そうすると仕事環境と私用環境に差が出てきてしまうので、ときどきお手入れが必要になります。

私用環境は、そんなじ長い時間使わなかったりするので、ついついお手入れをさぼりがち。。 というわけで今久しぶりに私用環境のお手入れをしています。

みなさんこういうときどうしているのかなぁ。

お手入れは、おもに作業中の困ったに対して都度都度丁寧にやっていくこととした。 つまり、仕事環境と一気にあわせるぞ!というのではなく、朝活中などに出くわした環境差異に、その時やっていることの手をいったん止めて、その都度ちゃんと向き合うこと。

今日のお手入れ

  • Mac OS を Catalina にアップグレード(仕事環境はまだ High Sierra だけど)
  • peco が入っていなかった!ひどい

昨日はデザインパターン読書会だった

増補改訂版Java言語で学ぶデザインパターン入門

増補改訂版Java言語で学ぶデザインパターン入門

  • 作者:結城 浩
  • 発売日: 2004/06/19
  • メディア: 大型本

  • Java である
  • 今どき Iterator とか実装しないでしょう

という点などがあり、Rubyist にはあまり読まれない本なのかしら…と思いつつ、やっぱり「デザインパターン」を学ぶには相変わらず最有力候補っぽい?

しかし素養のない私には、読んでいて新しい発見もいろいろある。

こちらをながめつつ、「Ruby 力をあげていきたい」という気持ちは復刊されたこちらのほうがいいのだろうな!

コンポーネントのライフサイクル

コンポーネントのライフサイクル

初期化され、マウントされ、レンダリングされ、再レンダリングされ、アンマウントされ…というサイクルのなかで、

それぞれのフェーズに介入して処理を差し込むメソッドが用意されている。

Mounting フェーズ

  • constructor [void]
  • static getDerivedStateFromProps(props, state) [State | null]
  • render() [React.ReactNode]
  • componentDidMount() [void]

Updating フェーズ

  • static getDerivedStateFromProps(props, state) [State | null]
  • shouldComponentUpdate(nextProps, nextState) [boolean]
  • render() [React.ReactNode]
  • getSnapshotBeforeUpdate(prevProps, prevState) [Snapshot | null]
  • componentDidUpdate(provProps, prevState, snapshot?) [void]

Upmounting フェーズ

  • componentWillUnmount() [void]

Error Handling フェーズ

  • componentDidCatch(error, info) [void]
  • static getDerivedStateFromError(error) [State]

こうして見てみるとだいたい「メソッド名で何ができそうか」見当がつきますねぇ。 こういうのがあるよ、というのはまず覚えておく。

本文中に、ライフサイクルのなかで各フェーズとそれぞれのメソッドがどういう順番に呼ばれるかが表現された図があって、わかりやすかったです。

React コンポーネントのライフサイク ルって、バージョン 16.3 から 17 にかけて大きな変更が予定されててね

おっと。インターネットの便利情報では16系のメソッドが使われている可能性があるので、注意しましょう。

開発するときに心がけたいこと(のひとつ)

技術書典8が新型コロナウイルス感染症の影響により中止となったため、 オンラインで応援祭が開催されています。(2020年4月5日まで)

それで昨日こちらを購入しました。

techbookfest.org

テストコミュニティには以前何度か参加したことがあり、ふだん自分がいるRuby界隈の方々から聞くのとまた別方向からの「開発」の話を聞くのがとても新鮮でした。

その頃から「開発」に関わる人たちがどんな気持ちでお仕事しているのかを知ることは、自分が開発をしていくなかでとても大切なことであると思うようになりました。

たとえばデザインを担当する方、PdM的な役割を担当する方、CSなどサービスを利用するお客様と直接接する方、など…

そのひとつとして、QAの方の気持ちを知りたくて、↑を読みました。

QAの方々が「テストするときに心がけていること」って、開発するときに心がけるといいことにつながるのでは、と思います。

コンポーネントと props

コンポーネントと props

コード写したり本文読んでいたんですが、やっぱりちょっと「コンポーネント」という考え方が身についていない。

ja.reactjs.org

概念的には、コンポーネントJavaScript の関数と似ています。(“props” と呼ばれる)任意の入力を受け取り、画面上に表示すべきものを記述する React 要素を返します。

なるほど、「何はなくともコンポーネント」。 ボタンもひとつのコンポーネントなんですね。

今回のサンプルコードの場合だと、 App という親コンポーネントのなかで、Card という子コンポーネントが作られている。 さらにそのなかで…という感じなのですね。

とするとデータの流れが単一方向というのはこういう感じなのかな。

f:id:katoriexxxkatorie:20200312062853p:plain

で、親コンポーネントが自身の値を書き換えたいときは

親コンポーネントが自身の状態を変更する関数を子コンポーネントに渡して、 フォーム入力時に発火されるイベントにその関数を仕込んでおく

今回の場合だと、親 App コンポーネントにおいて定義した increment()decrement() を、子 Button に Props として渡して、コンポーネント内でクリックイベントに仕込んでおくことで、親 App の props が書き換わるようになっている。