Skip to content

Commit

Permalink
translate FAQ - Component State (#105)
Browse files Browse the repository at this point in the history
* translate Component State

* update words

* misc

* Update content/docs/faq-state.md

Co-Authored-By: ginpei <ginpei@gmail.com>

* Update content/docs/faq-state.md

Co-Authored-By: ginpei <ginpei@gmail.com>

* Update content/docs/faq-state.md

Co-Authored-By: ginpei <ginpei@gmail.com>

* Update content/docs/faq-state.md

Co-Authored-By: ginpei <ginpei@gmail.com>

* Update content/docs/faq-state.md

Co-Authored-By: ginpei <ginpei@gmail.com>

* Update content/docs/faq-state.md

Co-Authored-By: ginpei <ginpei@gmail.com>

* Update content/docs/faq-state.md

Co-Authored-By: ginpei <ginpei@gmail.com>

* spaces between en and ja
  • Loading branch information
ginpei authored and koba04 committed Feb 14, 2019
1 parent d97c593 commit 67aad91
Showing 1 changed file with 41 additions and 41 deletions.
82 changes: 41 additions & 41 deletions content/docs/faq-state.md
Original file line number Diff line number Diff line change
@@ -1,106 +1,106 @@
---
id: faq-state
title: Component State
title: コンポーネントの state
permalink: docs/faq-state.html
layout: docs
category: FAQ
---

### What does `setState` do? {#what-does-setstate-do}
### `setState` は何をしているのですか? {#what-does-setstate-do}

`setState()` schedules an update to a component's `state` object. When state changes, the component responds by re-rendering.
`setState()` はコンポーネントの `state` オブジェクト更新をスケジュールします。state が更新されると、コンポーネントはそれに再レンダーで応じます。

### What is the difference between `state` and `props`? {#what-is-the-difference-between-state-and-props}
### `state` `props` の違いは何ですか? {#what-is-the-difference-between-state-and-props}

[`props`](/docs/components-and-props.html) (short for "properties") and [`state`](/docs/state-and-lifecycle.html) are both plain JavaScript objects. While both hold information that influences the output of render, they are different in one important way: `props` get passed *to* the component (similar to function parameters) whereas `state` is managed *within* the component (similar to variables declared within a function).
[`props`](/docs/components-and-props.html)"properties" を短くしたもの)と [`state`](/docs/state-and-lifecycle.html) は、両方ともプレーンな JavaScript のオブジェクトです。どちらもレンダー結果に影響を及ぼす情報を持ってはいますが、ある重要な一点が異なっています。つまり、`props` は(関数引数のように)コンポーネント**渡されるのに対し、`state` は(関数内で宣言された変数のように)コンポーネント*の内部*で制御されます。

Here are some good resources for further reading on when to use `props` vs `state`:
`props` `state` のどちらをいつ使うべきかについて、こちらでより詳しく読むことができます。
* [Props vs State](https://github.com/uberVU/react-guide/blob/master/props-vs-state.md)
* [ReactJS: Props vs. State](http://lucybain.com/blog/2016/react-state-vs-pros/)

### Why is `setState` giving me the wrong value? {#why-is-setstate-giving-me-the-wrong-value}
### `setState` が誤った値を返すのはなぜですか? {#why-is-setstate-giving-me-the-wrong-value}

In React, both `this.props` and `this.state` represent the *rendered* values, i.e. what's currently on the screen.
React では、`this.props` `this.state` のいずれも、*レンダーされた*もの、つまりスクリーン上の値を表しています。

Calls to `setState` are asynchronous - don't rely on `this.state` to reflect the new value immediately after calling `setState`. Pass an updater function instead of an object if you need to compute values based on the current state (see below for details).
`setState` 呼び出しは非同期です。呼び出し直後から `this.state` が新しい値を反映することを期待しないでください。もし現在の state に基づいた値を計算する必要がある場合は、オブジェクトの代わりに更新関数を渡してください。(詳しくは以下を参照)

Example of code that will *not* behave as expected:
このコード例は期待した通りには*動きません*

```jsx
incrementCount() {
// Note: this will *not* work as intended.
// 補足:これは意図通りに*動きません*
this.setState({count: this.state.count + 1});
}

handleSomething() {
// Let's say `this.state.count` starts at 0.
// `this.state.count` は 0 から始まるとします。
this.incrementCount();
this.incrementCount();
this.incrementCount();
// When React re-renders the component, `this.state.count` will be 1, but you expected 3.
// React がコンポーネントを再レンダーしても、`this.state.count` は意図通りの 3 ではなく 1 になります。

// This is because `incrementCount()` function above reads from `this.state.count`,
// but React doesn't update `this.state.count` until the component is re-rendered.
// So `incrementCount()` ends up reading `this.state.count` as 0 every time, and sets it to 1.
// これは、上記の `incrementCount()` 関数は `this.state.count` の値を読むのですが、
// しかしコンポーネントが再レンダーされるまで React `this.state.count` を更新しないためです。
// そして `incrementCount()` は値が 0 のままの `this.state.count` を毎回読み、そして 1 をセットしてしまいます。

// The fix is described below!
// 対処法は下で説明していますよ!
}
```

See below for how to fix this problem.
この問題を解決するには以下を見てください。

### How do I update state with values that depend on the current state? {#how-do-i-update-state-with-values-that-depend-on-the-current-state}
### どうやって現在の state に依存する値を更新したらいいですか? {#how-do-i-update-state-with-values-that-depend-on-the-current-state}

Pass a function instead of an object to `setState` to ensure the call always uses the most updated version of state (see below).
`setState` へオブジェクトを渡す代わりに関数を渡してください。その関数は常に最新の状態の state を使って呼ばれることが保証されています。(次項参照)

### What is the difference between passing an object or a function in `setState`? {#what-is-the-difference-between-passing-an-object-or-a-function-in-setstate}
### `setState` へオブジェクトを渡すのと関数を渡すのとのでは何が違いますか? {#what-is-the-difference-between-passing-an-object-or-a-function-in-setstate}

Passing an update function allows you to access the current state value inside the updater. Since `setState` calls are batched, this lets you chain updates and ensure they build on top of each other instead of conflicting:
更新関数を渡すと、その関数内で現在の state の値へアクセスできるようになります。`setState` 呼び出しはバッチ処理されるため、更新処理を連結して、それぞれの更新が競合せずに順序だって動作することが保証されます。

```jsx
incrementCount() {
this.setState((state) => {
// Important: read `state` instead of `this.state` when updating.
// 重要:更新には `this.state` ではなく `state` を使います。
return {count: state.count + 1}
});
}

handleSomething() {
// Let's say `this.state.count` starts at 0.
// `this.state.count` は 0 から始まるとします。
this.incrementCount();
this.incrementCount();
this.incrementCount();

// If you read `this.state.count` now, it would still be 0.
// But when React re-renders the component, it will be 3.
// ここで `this.state.count` を読んでもまだ 0 のままです。
// しかし React がコンポーネントを再レンダーするとき、値は 3 になります。
}
```

[Learn more about setState](/docs/react-component.html#setstate)
[setState についてもっと学ぶ](/docs/react-component.html#setstate)

### When is `setState` asynchronous? {#when-is-setstate-asynchronous}
### いつ `setState` は非同期になりますか? {#when-is-setstate-asynchronous}

Currently, `setState` is asynchronous inside event handlers.
現在、`setState` はイベントハンドラの内側では非同期です。

This ensures, for example, that if both `Parent` and `Child` call `setState` during a click event, `Child` isn't re-rendered twice. Instead, React "flushes" the state updates at the end of the browser event. This results in significant performance improvements in larger apps.
例えばクリックイベントの間に `Parent` `Child` の両方が `setState` を呼ぶとき、非同期処理のおかげで `Child` が 2 度レンダーされないことが保証されます。その代わりに React はブラウザイベントの最後に state の更新を「フラッシュ (flush)」します。これにより大規模アプリのパフォーマンスが大幅に向上します。

This is an implementation detail so avoid relying on it directly. In the future versions, React will batch updates by default in more cases.
これは実装の詳細ですので、この仕組みに直接依存しないようにしてください。将来のバージョンにおいて、React はより多くの場合にバッチ更新するようになります。

### Why doesn't React update `this.state` synchronously? {#why-doesnt-react-update-thisstate-synchronously}
### どうして React `this.state` を同期的に更新しないのですか? {#why-doesnt-react-update-thisstate-synchronously}

As explained in the previous section, React intentionally "waits" until all components call `setState()` in their event handlers before starting to re-render. This boosts performance by avoiding unnecessary re-renders.
前項で説明したように、全てのコンポーネントがそのイベントハンドラ内で `setState()` を呼ぶまで、React は再レンダー前に意図的に「待つ」ようになっています。これにより不必要な再レンダーが防がれ、パフォーマンスが向上します。

However, you might still be wondering why React doesn't just update `this.state` immediately without re-rendering.
とはいえ、React がどうして再レンダーなしに `this.state` を即時更新しないのか、まだ疑問に思っているかもしれません。

There are two main reasons:
これには主に 2 つの理由があります。

* This would break the consistency between `props` and `state`, causing issues that are very hard to debug.
* This would make some of the new features we're working on impossible to implement.
* 同期的更新が `props` `state` の間の一貫性を破壊し、非常にデバッグが難しい問題を引き起こしうるため。
* 同期的更新が、我々が取り組んでいる新機能のいくつかを実装不可能にしうるため。

This [GitHub comment](https://github.com/facebook/react/issues/11527#issuecomment-360199710) dives deep into the specific examples.
この [GitHub コメント](https://github.com/facebook/react/issues/11527#issuecomment-360199710)は特定の例について詳しく解説しています。

### Should I use a state management library like Redux or MobX? {#should-i-use-a-state-management-library-like-redux-or-mobx}
### Redux や MobX のような state 管理ライブラリを使うべきでしょうか? {#should-i-use-a-state-management-library-like-redux-or-mobx}

[Maybe.](https://redux.js.org/faq/general#when-should-i-use-redux)
[時には必要かもしれません。](https://redux.js.org/faq/general#when-should-i-use-redux)

It's a good idea to get to know React first, before adding in additional libraries. You can build quite complex applications using only React.
まずは他のライブラリを追加する前に React を理解することをお勧めします。React だけでも非常に複雑なアプリケーションを作り上げることができます。

0 comments on commit 67aad91

Please sign in to comment.