Fix textlint problems

src/content/learn/choosing-the-state-structure.md

@@ -280,7 +280,7 @@ label { display: block; margin-bottom: 5px; }
 
 </Sandpack>
 
-このフォームには 3 つの state 変数があります。`firstName`、`lastName`、そして `fullName`です。しかし、`fullName` は冗長です。**レンダー中に `fullName` は常に `firstName` と `lastName` から計算できるので、state から削除しましょう**。
+このフォームには 3 つの state 変数があります。`firstName`、`lastName`、そして `fullName` です。しかし、`fullName` は冗長です。**レンダー中に `fullName` は常に `firstName` と `lastName` から計算できるので、state から削除しましょう**。
 
 以下のようにします。
 
@@ -568,7 +568,7 @@ button { margin-top: 10px; }
 
 重複がなくなり、必要な state だけが残っています！
 
-これで、*選択された*項目を編集すると、下のメッセージもすぐに更新されるようになります。これは、`setItems` が再レンダーをトリガし、`items.find(...)` がタイトル更新後の項目を見つけてくるためです。*選択された項目*のデータ全体を state に格納する必要はありませんでした。なぜなら*選択された項目 ID* だけが本質的なものであるからです。残りはレンダー時に計算することができます。
+これで、*選択された*項目を編集すると、下のメッセージもすぐに更新されるようになります。これは、`setItems` が再レンダーをトリガし、`items.find(...)` がタイトル更新後の項目を見つけてくるためです。*選択された項目*のデータ全体を state に格納する必要はありませんでした。なぜなら*選択された項目 ID* だけが本質的なものだからです。残りはレンダー時に計算することができます。
 
 ## 深くネストされた state を避ける {/*avoid-deeply-nested-state*/}
 
@@ -1823,7 +1823,7 @@ button { margin: 10px; }
 
 <Recap>
 
-* 2つの state 変数が常に一緒に更新される場合は、それらを 1 つにまとめることを検討する。
+* 2 つの state 変数が常に一緒に更新される場合は、それらを 1 つにまとめることを検討する。
 * 「ありえない」state を作成しないよう、state 変数を注意深く選択する。
 * state は、更新時に間違いが発生しづらいやり方で構成する。
 * 冗長で重複した state を避け、同期する必要がないようにする。

src/content/reference/react/useCallback.md

@@ -87,7 +87,7 @@ function ProductPage({ productId, referrer, theme }) {
 
 言い換えると、`useCallback` は依存配列が変更されるまでの再レンダー間で関数をキャッシュします。
 
-**これが有用な場合を例を通じて見ていきましょう**。
+**例を通して、これが有用な場合を見ていきましょう**。
 
 例えば、`ProductPage` から `ShippingForm` コンポーネントに `handleSubmit` 関数を渡しているとします。
 
@@ -197,7 +197,7 @@ function ProductPage({ productId, referrer }) {
 その違いはキャッシュできる*内容*です。
 
 * **[`useMemo`](/reference/react/useMemo) はあなたの関数の呼び出し*結果*をキャッシュします**。この例では、`product` が変更されない限り、`computeRequirements(product)` の呼び出し結果をキャッシュします。これにより、`ShippingForm` を不必要に再レンダーすることなく、`requirements` オブジェクトを下位に渡すことができます。必要に応じて、React はレンダー中にあなたが渡した関数を呼び出して結果を計算します。
-* **`useCallback` は*関数自体*をキャッシュします**。`useMemo`とは異なり、あなたが提供する関数を呼び出しません。代わりに、あなたが提供した関数をキャッシュして、`productId` または `referrer` が変更されない限り、`handleSubmit` *自体*が変更されないようにします。これにより、`ShippingForm` を不必要に再レンダーすることなく、`handleSubmit` 関数を下位に渡すことができます。ユーザーがフォームを送信するまであなたのコードは実行されません。
+* **`useCallback` は*関数自体*をキャッシュします**。`useMemo` とは異なり、あなたが提供する関数を呼び出しません。代わりに、あなたが提供した関数をキャッシュして、`productId` または `referrer` が変更されない限り、`handleSubmit` *自体*が変更されないようにします。これにより、`ShippingForm` を不必要に再レンダーすることなく、`handleSubmit` 関数を下位に渡すことができます。ユーザがフォームを送信するまであなたのコードは実行されません。
 
 すでに [`useMemo`](/reference/react/useMemo) に詳しい場合、`useCallback` を次のように考えると役立つかもしれません。
 
@@ -216,7 +216,7 @@ function useCallback(fn, dependencies) {
 
 #### すべてに useCallback を追加すべきか？ {/*should-you-add-usecallback-everywhere*/}
 
-あなたのアプリがこのサイトのように、ほとんどのインタラクションが大まかなもの（ページ全体やセクション全体の置き換えなど）である場合、メモ化は通常不要です。一方、あなたのアプリが描画エディターのようなもので、ほとんどのインタラクションが細かい（形状の移動など）場合、メモ化は非常に役立つかもしれません。
+あなたのアプリがこのサイトのように、ほとんどのインタラクションが大まかなもの（ページ全体やセクション全体の置き換えなど）である場合、メモ化は通常不要です。一方、あなたのアプリが描画エディタのようなもので、ほとんどのインタラクションが細かい（形状の移動など）場合、メモ化は非常に役立つかもしれません。
 
 `useCallback` で関数をキャッシュすることが有用なのはいくつかのケースに限られます。