doc: translate strict mode to zh-hant

content/docs/strict-mode.md

@@ -1,65 +1,64 @@
 ---
 id: strict-mode
-title: Strict Mode
+title: 嚴格模式
 permalink: docs/strict-mode.html
 ---
 
-`StrictMode` is a tool for highlighting potential problems in an application. Like `Fragment`, `StrictMode` does not render any visible UI. It activates additional checks and warnings for its descendants.
+`嚴格模式`是一個用來突顯應用程式裡潛在問題的工具。如同 `Fragment` 一樣，`嚴格模式`不會 render 任何可見的 UI。它為了底下的所有的依賴們啟動了額外的檢查和警告。
 
-> Note:
+> 注意：
 >
-> Strict mode checks are run in development mode only; _they do not impact the production build_.
+> 嚴格模式檢查只會在開發模式中執行；_它們不應該影響正式環境_。
 
-You can enable strict mode for any part of your application. For example:
-`embed:strict-mode/enabling-strict-mode.js`
+你可以在應用程式的任何地方打開嚴格模式。例如：`embed:strict-mode/enabling-strict-mode.js`
 
-In the above example, strict mode checks will *not* be run against the `Header` and `Footer` components. However, `ComponentOne` and `ComponentTwo`, as well as all of their descendants, will have the checks.
+在上面的範例裡，嚴格模式檢查將*不會*跑在 `Header` 和 `Footer` 元件上。然而 `ComponentOne` 和 `ComponentTwo`，以及它們底下的所有子依賴，都會被檢查。
 
-`StrictMode` currently helps with:
-* [Identifying components with unsafe lifecycles](#identifying-unsafe-lifecycles)
-* [Warning about legacy string ref API usage](#warning-about-legacy-string-ref-api-usage)
-* [Warning about deprecated findDOMNode usage](#warning-about-deprecated-finddomnode-usage)
-* [Detecting unexpected side effects](#detecting-unexpected-side-effects)
-* [Detecting legacy context API](#detecting-legacy-context-api)
+`嚴格模式`目前可以幫助：
+* [發現擁有不安全生命週期的 component](#identifying-unsafe-lifecycles)
+* [警告使用了 legacy string ref API](#warning-about-legacy-string-ref-api-usage)
+* [警告使用到了被棄用的 findDOMNode](#warning-about-deprecated-finddomnode-usage)
+* [偵測意想不到的副作用](#detecting-unexpected-side-effects)
+* [偵測 legacy context API](#detecting-legacy-context-api)
 
-Additional functionality will be added with future releases of React.
+其他功能會在未來版本的 React 釋出時被加進去。
 
-### Identifying unsafe lifecycles {#identifying-unsafe-lifecycles}
+### 發現不安全的生命週期 {#identifying-unsafe-lifecycles}
 
-As explained [in this blog post](/blog/2018/03/27/update-on-async-rendering.html), certain legacy lifecycle methods are unsafe for use in async React applications. However, if your application uses third party libraries, it can be difficult to ensure that these lifecycles aren't being used. Fortunately, strict mode can help with this!
+如[這篇文章](/blog/2018/03/27/update-on-async-rendering.html)所述，某些遺留的生命週期在非同步的 React 應用程式裡使用是不安全的。然而，如果你的應用程式使用到第三方套件，確認這些生命週期有沒有被使用到是很困難的。幸好嚴格模式可以在這點幫助我們！
 
-When strict mode is enabled, React compiles a list of all class components using the unsafe lifecycles, and logs a warning message with information about these components, like so:
+當嚴格模式被打開的時候，React 編譯了一整串用到這些不安全生命週期的 class component，然後記錄了這些 component 的警告訊息，例如：
 
 ![](../images/blog/strict-mode-unsafe-lifecycles-warning.png)
 
-Addressing the issues identified by strict mode _now_ will make it easier for you to take advantage of async rendering in future releases of React.
+_現在_ 就關注這些被嚴格模式所發現的問題，會幫助你在 React 將來的版本裡處理非同步 render 的時候更容易。
 
-### Warning about legacy string ref API usage {#warning-about-legacy-string-ref-api-usage}
+### 警告使用到了 legacy string ref API {#warning-about-legacy-string-ref-api-usage}
 
-Previously, React provided two ways for managing refs: the legacy string ref API and the callback API. Although the string ref API was the more convenient of the two, it had [several downsides](https://github.com/facebook/react/issues/1373) and so our official recommendation was to [use the callback form instead](/docs/refs-and-the-dom.html#legacy-api-string-refs).
+以前 React 提供了兩種管理 ref 的方式：legacy string ref API 和 callback API。雖然 string ref API 在兩者之間是比較方便的，但它有很多[缺點](https://github.com/facebook/react/issues/1373)，所以我們的官方推薦是[使用 callback form](/docs/refs-and-the-dom.html#legacy-api-string-refs).
 
-React 16.3 added a third option that offers the convenience of a string ref without any of the downsides:
+React 16.3 加上了第三種選擇，提供了 string ref 的便利性且免除了那些缺點：
 `embed:16-3-release-blog-post/create-ref-example.js`
 
-Since object refs were largely added as a replacement for string refs, strict mode now warns about usage of string refs.
+因為 object ref 已經大量取代了 string ref，嚴格模式現在會在你使用 string ref 的時候警告你。
 
-> **Note:**
+> **注意：**
 >
-> Callback refs will continue to be supported in addition to the new `createRef` API.
+> 除了新的 `createRef` API 以外，callback ref 會持續被支援。
 >
-> You don't need to replace callback refs in your components. They are slightly more flexible, so they will remain as an advanced feature.
+> 你不需要改掉你 component 裡的 callback ref。它們稍微更有彈性，所以它們會持續是一個進階性的功能。
 
-[Learn more about the new `createRef` API here.](/docs/refs-and-the-dom.html)
+[學習更多關於新的 `createRef` API。](/docs/refs-and-the-dom.html)
 
-### Warning about deprecated findDOMNode usage {#warning-about-deprecated-finddomnode-usage}
+### 警告使用到了被棄用的 findDOMNode {#warning-about-deprecated-finddomnode-usage}
 
-React used to support `findDOMNode` to search the tree for a DOM node given a class instance. Normally you don't need this because you can [attach a ref directly to a DOM node](/docs/refs-and-the-dom.html#creating-refs).
+React 過去支援了 `findDOMNode` 來用 class instance 搜尋 tree 裡面的 DOM 節點。通常你不需要這個，因為你可以 [直接把一個 ref 附到你的 DOM 節點](/docs/refs-and-the-dom.html#creating-refs)。
 
-`findDOMNode` can also be used on class components but this was breaking abstraction levels by allowing a parent to demand that certain children was rendered. It creates a refactoring hazard where you can't change the implementation details of a component because a parent might be reaching into its DOM node. `findDOMNode` only returns the first child, but with the use of Fragments, it is possible for a component to render multiple DOM nodes. `findDOMNode` is a one time read API. It only gave you an answer when you asked for it. If a child component renders a different node, there is no way to handle this change. Therefore `findDOMNode` only worked if components always return a single DOM node that never changes.
+`findDOMNode` 也可以被使用在 class component 上，但這是一個破壞抽象層的用法，它允許了 parent 來要求 render 某個特定的 children。它產生了重構的風險，因為 parent 可能會進入到某個 DOM 節點，所以你不能隨意改變 component 的實作細節。`findDOMNode` 只會回傳第一個 child，但如果使用了 Fragment，有可能某個 component 會 render 多個 DOM 節點。`findDOMNode` 是一個只能讀一次的 API。它只在你要求的時候告訴你答案。如果一個 child component render 了不同的節點，沒有任何方法可以處理這樣的改變。所以 `findDOMNode` 只在元件永遠回傳一個單一且永遠不改變的 DOM 節點時有用。
 
-You can instead make this explicit by passing a ref to your custom component and pass that along to the DOM using [ref forwarding](/docs/forwarding-refs.html#forwarding-refs-to-dom-components).
+你可以藉由傳遞 ref 到你的客製化 component，且把它傳到使用 [ref forwarding](/docs/forwarding-refs.html#forwarding-refs-to-dom-components) 的 DOM，使它變得明顯。
 
-You can also add a wrapper DOM node in your component and attach a ref directly to it.
+你也可以在你的 component 加上一個包裹的 DOM 節點，然後把 ref 直接附在它上面。
 
 ```javascript{4,7}
 class MyComponent extends React.Component {
@@ -73,52 +72,52 @@ class MyComponent extends React.Component {
 }
 ```
 
-> Note:
+> 注意：
 >
-> In CSS, the [`display: contents`](https://developer.mozilla.org/en-US/docs/Web/CSS/display#display_contents) attribute can be used if you don't want the node to be part of the layout.
+> 在 CSS 裡，如果你不想要某個節點成為 layout 的一部份，[`display: contents`](https://developer.mozilla.org/en-US/docs/Web/CSS/display#display_contents) attribute 可以被使用。
 
-### Detecting unexpected side effects {#detecting-unexpected-side-effects}
+### 偵測意想不到的副作用 {#detecting-unexpected-side-effects}
 
-Conceptually, React does work in two phases:
-* The **render** phase determines what changes need to be made to e.g. the DOM. During this phase, React calls `render` and then compares the result to the previous render.
-* The **commit** phase is when React applies any changes. (In the case of React DOM, this is when React inserts, updates, and removes DOM nodes.) React also calls lifecycles like `componentDidMount` and `componentDidUpdate` during this phase.
+概念上，React 在兩種面相上能夠運作：
+* **render** 面相決定了必須做出什麼改變到例如 DOM 的地方。在這個面相上，React 呼叫 `render` 然後比較了它與上一次 render 的結果。
+* **commit** 面相是每當 React 運用到任何改變的時候。（在 React DOM 的例子，當 React 插入、更新、或移除 DOM 節點。）React 也在這個面相上呼叫了像是 `componentDidMount` 和 `componentDidUpdate` 的生命週期。
 
-The commit phase is usually very fast, but rendering can be slow. For this reason, the upcoming async mode (which is not enabled by default yet) breaks the rendering work into pieces, pausing and resuming the work to avoid blocking the browser. This means that React may invoke render phase lifecycles more than once before committing, or it may invoke them without committing at all (because of an error or a higher priority interruption).
+Commit 面相通常非常快，但 render 可能會很慢。為了這個原因，將來的非同步模式（還沒被預設成開啟）會把 render 的工作切成小塊，暫停和恢復這些工作藉以避免阻擋瀏覽器。 這表示 React 可能會在 commit 之前調用多次 render 面相的生命週期，或是他會不管有沒有 commit 就調用它們（因為錯誤或是更高優先性的中斷）。
 
-Render phase lifecycles include the following class component methods:
+Render 面相的生命週期包含了以下 class component 函式:
 * `constructor`
 * `componentWillMount`
 * `componentWillReceiveProps`
 * `componentWillUpdate`
 * `getDerivedStateFromProps`
 * `shouldComponentUpdate`
 * `render`
-* `setState` updater functions (the first argument)
+* `setState` updater functions (第一個參數)
 
-Because the above methods might be called more than once, it's important that they do not contain side-effects. Ignoring this rule can lead to a variety of problems, including memory leaks and invalid application state. Unfortunately, it can be difficult to detect these problems as they can often be [non-deterministic](https://en.wikipedia.org/wiki/Deterministic_algorithm).
+因為以上函式可能會被呼叫不只一次，不包含副作用是很重要的。忽視這個規則可能會導致各種問題，包含記憶體滲漏，和不合法的應用程式 state。不幸的是，偵測這些問題很困難，因為它們通常是 [non-deterministic](https://en.wikipedia.org/wiki/Deterministic_algorithm)。
 
-Strict mode can't automatically detect side effects for you, but it can help you spot them by making them a little more deterministic. This is done by intentionally double-invoking the following methods:
+嚴格模式無法自動檢測 side effect，但它可以藉由使這些 side effect 變得更有確定性，來幫助你發現它們。它藉由故意調用兩次下面的函式來完成這個功能：
 
 * Class component `constructor` method
 * The `render` method
-* `setState` updater functions (the first argument)
-* The static `getDerivedStateFromProps` lifecycle
+* `setState` updater functions (第一個參數)
+* 靜態的 `getDerivedStateFromProps` 生命週期
 
-> Note:
+> 注意：
 >
-> This only applies to development mode. _Lifecycles will not be double-invoked in production mode._
+> 這個只在開發模式發生。_生命週期不會被重複調用在正式環境。_
 
-For example, consider the following code:
+例如，考慮以下程式碼：
 `embed:strict-mode/side-effects-in-constructor.js`
 
-At first glance, this code might not seem problematic. But if `SharedApplicationState.recordEvent` is not [idempotent](https://en.wikipedia.org/wiki/Idempotence#Computer_science_meaning), then instantiating this component multiple times could lead to invalid application state. This sort of subtle bug might not manifest during development, or it might do so inconsistently and so be overlooked.
+第一眼看這段程式碼，可能不會覺得它有問題。但如果 `SharedApplicationState.recordEvent` 不是 [idempotent](https://en.wikipedia.org/wiki/Idempotence#Computer_science_meaning) 的話，多次實體化這個 component 可能會導致不合法的應用程式 state。這種細微的錯誤可能在開發期間不會出現，或者會不一致地出現，因此被忽略了。
 
-By intentionally double-invoking methods like the component constructor, strict mode makes patterns like this easier to spot.
+通過有意地雙重調用如 component constructor，嚴格模式使這種模式更容易被發現。
 
-### Detecting legacy context API {#detecting-legacy-context-api}
+### 檢測 legacy context API {#detecting-legacy-context-api}
 
-The legacy context API is error-prone, and will be removed in a future major version. It still works for all 16.x releases but will show this warning message in strict mode:
+Legacy context API 是容易出錯的，並將在以後的主要版本中刪除。它仍然適用於所有 16.x 版本，但將在嚴格模式下顯示以下警告訊息：
 
 ![](../images/blog/warn-legacy-context-in-strict-mode.png)
 
-Read the [new context API documentation](/docs/context.html) to help migrate to the new version.
+閱讀[新的 context API 文件](/docs/context.html)，以助於遷移到新版本。