<h2 id="h8c81c46478"><span style="color:#a4c520">useStateとは何か？</span></h2><p>useState はReact hooks のひとつ。useStateを使うことで状態の管理ができるようになります。<br>useStateは第一引数には管理したい状態の初期値を設定します。<br>返却値としては、管理したい状態とその状態を変更するための関数の配列が返ります。分割代入で取得するのが一般的です。</p><pre><code>const [状態, 状態を変更する関数] = useState(初期値);
const [count, setCount] = useState(0);</code></pre><p><br></p><h2 id="h1a2facf864"><span style="color:#a4c520">クラスコンポーネントにおける状態管理</span></h2><p>クラスコンポーネントでも状態管理をすることができます。<br>以下はクラスコンポーネントを使って状態管理する例です。</p><pre><code>import React from "react";

class SampleWithClassComponent extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      count: 0,
    };
  }
  render() {
    return (
      &lt;div&gt;
        &lt;p&gt;current count is {this.state.count}&lt;/p&gt;
        &lt;button onClick={() =&gt; this.setState({ count: this.state.count + 1 })}&gt;
          {" "}
          +1{" "}
        &lt;/button&gt;
        &lt;button onClick={() =&gt; this.setState({ count: this.state.count - 1 })}&gt;
          {" "}
          -1{" "}
        &lt;/button&gt;
      &lt;/div&gt;
    );
  }
}

export default SampleWithClassComponent;</code></pre><p><br></p><h2 id="h146e260859"><span style="color:#a4c520">useStateを使った状態管理</span></h2><p>上記処理を関数コンポーネントでuseStateを使用して書き換えてみます。<br>行数が少なく、すっきりすることがわかると思います。</p><pre><code>import React, { useState } from "react";

const SampleWithArrowComponent = () =&gt; {
  const [count, setCount] = useState(0);
  return (
    &lt;div&gt;
      &lt;p&gt;current count is {count}&lt;/p&gt;
      &lt;button onClick={() =&gt; setCount(count + 1)}&gt;+1&lt;/button&gt;
      &lt;button onClick={() =&gt; setCount(count - 1)}&gt;
        -1
      &lt;/button&gt;
    &lt;/div&gt;
  );
};
export default SampleWithArrowComponent;</code></pre><p><br><br><br><br></p>

useStateについて知る

<p>普段他の方のPRをレビューする機会があるのですが、その際にどういった観点からコードを評価すれば良いのかについて考えたので以下に記載します。<br></p><h3 id="h086f001100">PRの規模は大きすぎないか</h3><p>まず確認するのはPRの規模です。具体的にはPRのFile Chagedのところです。<br>修正ファイル数が少ない方がレビューの負担が軽くなるかと思います。<br>大体20ファイルを超えてくると見る方もかなり大変になってきますのでPR自体を分割するなどするようにしています。</p><h3 id="h5db666cd90">PRの提出の仕方が互換性の観点から適切か</h3><p>大きな機能開発などを細かくPR提出する際に個々のPRのみでは互換性が保てない時はPRがdevelop, mainブランチではなく、トピックブランチに向いているかなどを確認するようにしています。</p><h3 id="h59eb64ead0">PRの目的（仕様）とコードが乖離してないか</h3><p>こちらは最も大事な点だと思うのですが、自分でも失念しがちな点です。。<br>レビュアーとしてはPRのコメントや仕様書のリンクを貼っておいていただけると助かると思います。<br>一方、レビューイとしては自分が設計+開発をどちらも担当している場合はドキュメントや仕様書に設計方針や仕様を明示し、カウンターパート（非システム部門）と認識を共有しておく必要があると思います。レビューイが開発のみを担当する場合は設計担当者と認識齟齬がないようにしておく必要があると思います。テストコードのみからなるPRをトピックブランチに提出するのも一つの手としてありうるかと思います。また、API開発などでは<a href="https://swagger.io/specification/" target="_blank" rel="noopener noreferrer">OpenAPI</a>などを使用することでコードの中で仕様書を管理したりそれをテストコードとして使用したりできるので活用するのも大事です。</p><h3 id="h89ddc4adcb">テストが網羅的に書けているか</h3><p>実行コードの仕様としてテストコードは大事です。<br>なので、よく実行コードとテストコードの修正を別PRで提出する方がいるのですが、できれば一緒に提出していただきたいです。テストが網羅的に書けているかもチェックします。Rubyの場合は<a href="https://github.com/simplecov-ruby/simplecov" target="_blank" rel="noopener noreferrer">SimpleCov</a>がレポートを出してくれるので大変便利です。</p><h3 id="h6098af0e40">パフォーマンスで改善の余地はないか</h3><p>パフォーマンスも改善の余地がないか確認します。DBに投げられるSQLを確認したり、余分なクエリが発生していないかなどを確認します。Ruby開発の場合は<a href="https://github.com/flyerhzm/bullet" target="_blank" rel="noopener noreferrer">bullet</a>を導入していると便利です。</p><h3 id="h46acf04d6a">リリース時に手動作業等の特殊作業が必要でないか</h3><p>DBのテーブルの型を変更する時やデータパッチを行う場合は自動デプロイの後に手動対応が必要なのでレビューイが意識できていない場合は特にPRのコメントに「FYI」としてメモしたりします。</p><h3 id="ha214098e44">まとめ</h3><p>以上がPRレビューの際に気をつけていることでした。他にもあると思うので今後思いついたらまた記事にしていこうと思います。<br></p>

PRをレビューする時に気をつけること

<p>最近ブログを移転しました。<br><br>以前は<code>ruby + jekyll + github.io</code>で運用していたのですが、<code>TypeScript（Next.js） + vercel + MicroCMS</code> に移転しました。<br><br>記事は現在移動中です。<br>今後もいろんな記事を書いていこうと思います。<br><br></p>

技術的なことや趣味、読んだ本についての感想などを投稿してきます。

最新記事 (3ページ目)

カテゴリー

TKA5