From 9fbf620a2a0706a8da7460db31b5d3fbdc72249f Mon Sep 17 00:00:00 2001
From: Hossein Ahmadi <hossein.ahmadi98@outlook.com>
Date: Sat, 27 Jun 2020 19:41:07 +0430
Subject: [PATCH 01/15] React.Component translated

---
 content/docs/reference-react-component.md | 330 +++++++++++-----------
 1 file changed, 165 insertions(+), 165 deletions(-)

diff --git a/content/docs/reference-react-component.md b/content/docs/reference-react-component.md
index bf0ab7c52..b85b99fff 100644
--- a/content/docs/reference-react-component.md
+++ b/content/docs/reference-react-component.md
@@ -15,11 +15,11 @@ redirect_from:
   - "tips/use-react-with-other-libraries.html"
 ---
 
-This page contains a detailed API reference for the React component class definition. It assumes you're familiar with fundamental React concepts, such as [Components and Props](/docs/components-and-props.html), as well as [State and Lifecycle](/docs/state-and-lifecycle.html). If you're not, read them first.
+این صفحه حاوی جزئیات دقیق منابع API کلاس کامپوننت ری‌اکت می‌باشد. فرض شده است که شما با مفاهیم بنادین ری‌اکت مانند [کامپوننت ها و Props](/docs/components-and-props.html) و [State و چرخه حیات](/docs/state-and-lifecycle.html) آشنا هستید. در غیر‌اینصورت ابتدا آن‌ها را مطالعه نمایید.
 
-## Overview {#overview}
+## بررسی اجمالی {#overview}
 
-React lets you define components as classes or functions. Components defined as classes currently provide more features which are described in detail on this page. To define a React component class, you need to extend `React.Component`:
+ری‌اکت به شما اجازه می‌دهد تا کامپوننت‌ها را به عنوان کلاس یا تابع تعریف کنید. کامپوننت‌هایی که به عنوان کلاس تعریف می‌شوندُ در حال حاضر امکانات بیشتری را فراهم می‌کنند که در این صفحه با جزئیات کامل تشریح شده است. برای تعریف یک کلاس کامپوننت ری‌اکتُ شما به گسترش `React.Component` نیاز دارید:
 
 ```js
 class Welcome extends React.Component {
@@ -29,36 +29,36 @@ class Welcome extends React.Component {
 }
 ```
 
-The only method you *must* define in a `React.Component` subclass is called [`render()`](#render). All the other methods described on this page are optional.
+تنها متدی که شما *باید* در یک زیرکلاس `React.Component` تعریف کنید، [`render()`](#render) نام دارد. تمامی متدهای دیگر تشریح شده در این صفحه، اختیاری هستند.
 
-**We strongly recommend against creating your own base component classes.** In React components, [code reuse is primarily achieved through composition rather than inheritance](/docs/composition-vs-inheritance.html).
+**ما به شدت مخالف ایجاد کلاس‌های کامپونت مادر خودتان هستیم**. در کاپوننت‌های ری‌اکت، [استفاده مجدد از کد بیشتر از طریق ترکیب قابل دستیابی است تا وراثت](/docs/composition-vs-inheritance.html).
 
->Note:
+>نکته:
 >
->React doesn't force you to use the ES6 class syntax. If you prefer to avoid it, you may use the `create-react-class` module or a similar custom abstraction instead. Take a look at [Using React without ES6](/docs/react-without-es6.html) to learn more.
+>ری‌اکت شما را مجبور به استفاده از قوانین کلاس‌ها در ES6 نمی‌کند. اگر ترجیح می‌دهید که از این قوانین استفاده کنید، می‌توانید از ماژول `create-react-class` یا تجریدهای شخصی‌سازی شده مشابه استفاده نمایید. برای اطلاعات بیشتر به [Using React without ES6](/docs/react-without-es6.html) نگاهی بیاندازید.
 
-### The Component Lifecycle {#the-component-lifecycle}
+### چرخه‌ی حیات کامپوننت {#the-component-lifecycle}
 
-Each component has several "lifecycle methods" that you can override to run code at particular times in the process. **You can use [this lifecycle diagram](http://projects.wojtekmaj.pl/react-lifecycle-methods-diagram/) as a cheat sheet.** In the list below, commonly used lifecycle methods are marked as **bold**. The rest of them exist for relatively rare use cases.
+هر کامپوننت چندین "متد چرخه‌ی حیات" دارد که شما می‌توانید بازنویسی کنید تا در زمان‌های خاص فرآیند اجرا، کد شما اجرا شود. **شما می‌توانید از [این دیاگرام چرخه‌حیات](http://projects.wojtekmaj.pl/react-lifecycle-methods-diagram/) به عنوان راهنما استفاده کنید.** در لیست زیر، متدهای چرخه‌ی حیات رایج به صورت **برجسته** نشانه‌گذاری شده‌اند. باقی آن‌ها برای موارد نادر استفاده وجود دارند.
 
-#### Mounting {#mounting}
+#### اجرای اولیه {#mounting}
 
-These methods are called in the following order when an instance of a component is being created and inserted into the DOM:
+این متدها به ترتیب زیر هنگام ایجاد یک نمونه از کامپوننت و درج آن در DOM صدا زده می‌شوند:
 
 - [**`constructor()`**](#constructor)
 - [`static getDerivedStateFromProps()`](#static-getderivedstatefromprops)
 - [**`render()`**](#render)
 - [**`componentDidMount()`**](#componentdidmount)
 
->Note:
+>نکته:
 >
->These methods are considered legacy and you should [avoid them](/blog/2018/03/27/update-on-async-rendering.html) in new code:
+>این متدها موروثی در نظر گرفته می‌شوند و شما باید از آن‌ها در کد جدید [خودداری کنید](/blog/2018/03/27/update-on-async-rendering.html):
 >
 >- [`UNSAFE_componentWillMount()`](#unsafe_componentwillmount)
 
-#### Updating {#updating}
+#### بروزرسانی {#updating}
 
-An update can be caused by changes to props or state. These methods are called in the following order when a component is being re-rendered:
+یک بروزرسانی می‌تواند به وسیله تغییر دادن state یا props رخ دهد. این متدها هنگامی که یک کامپوننت دوباره رندر می‌شود به ترتیب زیر صدا زده می‌شوند:
 
 - [`static getDerivedStateFromProps()`](#static-getderivedstatefromprops)
 - [`shouldComponentUpdate()`](#shouldcomponentupdate)
@@ -66,50 +66,50 @@ An update can be caused by changes to props or state. These methods are called i
 - [`getSnapshotBeforeUpdate()`](#getsnapshotbeforeupdate)
 - [**`componentDidUpdate()`**](#componentdidupdate)
 
->Note:
+>نکته:
 >
->These methods are considered legacy and you should [avoid them](/blog/2018/03/27/update-on-async-rendering.html) in new code:
+>این متدها موروثی در نظر گرفته می‌شوند و شما باید از آن‌ها در کد جدید [خودداری کنید](/blog/2018/03/27/update-on-async-rendering.html):
 >
 >- [`UNSAFE_componentWillUpdate()`](#unsafe_componentwillupdate)
 >- [`UNSAFE_componentWillReceiveProps()`](#unsafe_componentwillreceiveprops)
 
-#### Unmounting {#unmounting}
+#### نابود شدن {#unmounting}
 
-This method is called when a component is being removed from the DOM:
+این متدها هنگامی که یک کامپوننت از DOM پاک می‌شود صدا زده می‌شوند:
 
 - [**`componentWillUnmount()`**](#componentwillunmount)
 
-#### Error Handling {#error-handling}
+#### کنترل خطا {#error-handling}
 
-These methods are called when there is an error during rendering, in a lifecycle method, or in the constructor of any child component.
+این متدها هنگام بروز خطا در زمان رندر شدن، در یکی از متدهای چرخه‌ی حیات و یا در سازنده هر کدام از کامپوننت‌های فرزند صدا زده می‌شوند:
 
 - [`static getDerivedStateFromError()`](#static-getderivedstatefromerror)
 - [`componentDidCatch()`](#componentdidcatch)
 
-### Other APIs {#other-apis}
+### دیگر API‌ها {#other-apis}
 
-Each component also provides some other APIs:
+همچنین هر کامپوننت API های دیگری نیز فراهم می‌کند:
 
   - [`setState()`](#setstate)
   - [`forceUpdate()`](#forceupdate)
 
-### Class Properties {#class-properties}
+### ویژگی‌های کلاس {#class-properties}
 
   - [`defaultProps`](#defaultprops)
   - [`displayName`](#displayname)
 
-### Instance Properties {#instance-properties}
+### ویژگی‌های Instance {#instance-properties}
 
   - [`props`](#props)
   - [`state`](#state)
 
 * * *
 
-## Reference {#reference}
+## مرجع {#reference}
 
-### Commonly Used Lifecycle Methods {#commonly-used-lifecycle-methods}
+### متدهای چرخه‌ی حیات رایج {#commonly-used-lifecycle-methods}
 
-The methods in this section cover the vast majority of use cases you'll encounter creating React components. **For a visual reference, check out [this lifecycle diagram](http://projects.wojtekmaj.pl/react-lifecycle-methods-diagram/).**
+متدهای این بخش اکثریت قریب به اتفاق موارد کاربردی که شما هنگام ایجاد کامپوننت‌های ری‌اکت با آن‌ها مواجه می‌شوید را پوشش می‌دهد. **برای یک مرجع بصری، [این دیاگرام چرخه‌ی حیات](http://projects.wojtekmaj.pl/react-lifecycle-methods-diagram/) را بررسی کند.**
 
 ### `render()` {#render}
 
@@ -117,23 +117,23 @@ The methods in this section cover the vast majority of use cases you'll encounte
 render()
 ```
 
-The `render()` method is the only required method in a class component.
+`render()` تنها متد ضروری در یک کلاس کامپوننت است.
 
-When called, it should examine `this.props` and `this.state` and return one of the following types:
+هنگام فراخوانی، باید `this.props` و `this.state` را بررسی کند و یکی از موارد زیر را بازگرداند:
 
-- **React elements.** Typically created via [JSX](/docs/introducing-jsx.html). For example, `<div />` and `<MyComponent />` are React elements that instruct React to render a DOM node, or another user-defined component, respectively.
-- **Arrays and fragments.** Let you return multiple elements from render. See the documentation on [fragments](/docs/fragments.html) for more details.
-- **Portals**. Let you render children into a different DOM subtree. See the documentation on [portals](/docs/portals.html) for more details.
-- **String and numbers.** These are rendered as text nodes in the DOM.
-- **Booleans or `null`**. Render nothing. (Mostly exists to support `return test && <Child />` pattern, where `test` is boolean.)
+- **المنت‌های ری‌اکت.** معمولا با [JSX](/docs/introducing-jsx.html) ایجاد می‌شود. برای مثال، `<div />` و `<MyComponent />` المنت‌های ری‌اکت هستند که ری‌اکت را راهنمایی می‌کنند تا یک نود DOM، یا کامپوننت دیگری که توسط کاربر تعریف شده‌است را رندر کند.
+- **آرایه‌ها و فرگمنت‌ها.** به شما اجازه می‌دهد تا چند المنت را از رندر بازگردانید. مستندات [فرگمنت‌ها](/docs/fragments.html) را برای اطلاعات بیشتر مطالعه کنید.
+- **پرتال‌ها.** به شما اجازه می‌دهد تا فرزندان را در یک زیردرخت متفاوت DOM رندر کنید. مستندات [پرتال‌ها](/docs/portals.html) را برای اطلاعات بیشتر مطالعه کنید.
+- **رشته متنی و اعداد.** این‌ها به عنوان نودهای متنی در DOM رندر می‌شوند.
+- **متغیرهای بولی یا `null`.** چیزی رندر نمی‌کنند. (به طور کلی برای پشتیبانی از الگوی `return test && <Child />`، هنگامی که `test` یک متغیر بولی است وجود دارد.)
 
-The `render()` function should be pure, meaning that it does not modify component state, it returns the same result each time it's invoked, and it does not directly interact with the browser.
+تابع `render()` باید خالص باشد، به این معنی که نباید state را تغییر دهد، هر بار که فراخوانی می‌شود نتیجه یکسان بازمی‌گرداند و به صورت مستقیم با مرورگر تعاملی ندارد.
 
-If you need to interact with the browser, perform your work in `componentDidMount()` or the other lifecycle methods instead. Keeping `render()` pure makes components easier to think about.
+اگر به تعامل با مرورگر نیاز دارید، عملیاتتان را در `componentDidMount()` یا دیگر متدهای چرخه‌ی حیات انجام دهید. خالص نگه داشتن `render()` فکر کردن به کامپوننت‌ها را آسان‌تر می‌کند.
 
-> Note
+> نکته:
 >
-> `render()` will not be invoked if [`shouldComponentUpdate()`](#shouldcomponentupdate) returns false.
+> در صورتی که [`shouldComponentUpdate()`](#shouldcomponentupdate)، false بازگرداند، `render()` فراخوانی نمی‌شود.
 
 * * *
 
@@ -143,16 +143,16 @@ If you need to interact with the browser, perform your work in `componentDidMoun
 constructor(props)
 ```
 
-**If you don't initialize state and you don't bind methods, you don't need to implement a constructor for your React component.**
+**اگر state را در ابتدا مقداردهی نمی‌کنید و متدها را bind نمی‌کنید، نیازی به پیاده‌سازی سازنده برای کامپوننت ری‌اکت خود نیست.**
 
-The constructor for a React component is called before it is mounted. When implementing the constructor for a `React.Component` subclass, you should call `super(props)` before any other statement. Otherwise, `this.props` will be undefined in the constructor, which can lead to bugs.
+سازنده‌ی یک کامپوننت ری‌اکت قبل از اجرای اولیه‌اش صدا زده می‌شود. هنگام پیاده‌سازی سازنده برای یک زیرکلاس `React.Component`، شما باید `super(props)` را قبل از هر قطعه کدی صدا بزنید. درغیراینصورت، `this.props` در سازنده undefined خواهد بود که می‌تواند باعث بروز باگ شود.
 
-Typically, in React constructors are only used for two purposes:
+معمولا، سازنده‌ها تنها به دو دلیل در ری‌اکت استفاده می‌شوند:
 
-* Initializing [local state](/docs/state-and-lifecycle.html) by assigning an object to `this.state`.
-* Binding [event handler](/docs/handling-events.html) methods to an instance.
+* مقداردهی اولیه‌ی [state محلی](/docs/state-and-lifecycle.html) توسط انتصاب یک آبجکت به `this.state`.
+* Bind کردن متدهای [event handler](/docs/handling-events.html) به یک instance.
 
-You **should not call `setState()`** in the `constructor()`. Instead, if your component needs to use local state, **assign the initial state to `this.state`** directly in the constructor:
+شما **به هیچ عنوان نیابد `setState()` را در `constructor()`** صدا بزنید. برای این کار، اگر کامپوننت شما به استفاده از state محلی نیاز دارد، **state اولیه را مستقیما برابر `this.state`** در سازنده قرار دهید:
 
 ```js
 constructor(props) {
@@ -163,13 +163,13 @@ constructor(props) {
 }
 ```
 
-Constructor is the only place where you should assign `this.state` directly. In all other methods, you need to use `this.setState()` instead.
+سازنده تنها جایی‌است که باید `this.state` را مسقیما برابر مقداری قرار دهید. در دیگر متدها، نیاز دارید تا از `this.setState()` استفاده کنید.
 
-Avoid introducing any side-effects or subscriptions in the constructor. For those use cases, use `componentDidMount()` instead.
+از معرفی هرگونه تاثیر جانبی و یا ثبت اشتراک در سازنده خودداری نمایید. برای چنین موارد، از `componentDidMount()` استفاده کنید.
 
->Note
+>نکته:
 >
->**Avoid copying props into state! This is a common mistake:**
+>**از کپی کردن props در state خودداری نمایید! این یک اشتباه رایج است:**
 >
 >```js
 >constructor(props) {
@@ -179,11 +179,11 @@ Avoid introducing any side-effects or subscriptions in the constructor. For thos
 >}
 >```
 >
->The problem is that it's both unnecessary (you can use `this.props.color` directly instead), and creates bugs (updates to the `color` prop won't be reflected in the state).
+>مشکل اینجاست که هردو کار غیرضروری است (شما می‌توانید مستقیما از `this.props.color` استفاده کنید )، و باگ ایجاد می‌کند (بروزرسانی‌های `color` در prop تاثیری بر روی state نمی‌گذارد).
 >
->**Only use this pattern if you intentionally want to ignore prop updates.** In that case, it makes sense to rename the prop to be called `initialColor` or `defaultColor`. You can then force a component to "reset" its internal state by [changing its `key`](/blog/2018/06/07/you-probably-dont-need-derived-state.html#recommendation-fully-uncontrolled-component-with-a-key) when necessary.
+>**تنها در صورتی که می‌خواهید عمدا بروزرسانی‌های prop را نادیده بگیرید از این الگو استفاده کنید.** در این صورت، منطقی است که prop را تغییر نام دهید که `initialColor` یا `defaultColor` صدا زده شود. در مواقع لزوم، می‌توانید یک کامپوننت را به وسیله [تغییر `key`](/blog/2018/06/07/you-probably-dont-need-derived-state.html#recommendation-fully-uncontrolled-component-with-a-key) به "reset" کردن state داخلی‌اش مجبور کنید.
 >
->Read our [blog post on avoiding derived state](/blog/2018/06/07/you-probably-dont-need-derived-state.html) to learn about what to do if you think you need some state to depend on the props.
+>[پست وبلاگ مربوط به خودداری از state مشتق شده](/blog/2018/06/07/you-probably-dont-need-derived-state.html) را بخوانید تا در صورتی که فکر می‌کنید نیاز به وابستگی بعضی state ها به props دارید، چگونگی انجام دادن آن را یاد بگیرید.
 
 
 * * *
@@ -194,11 +194,11 @@ Avoid introducing any side-effects or subscriptions in the constructor. For thos
 componentDidMount()
 ```
 
-`componentDidMount()` is invoked immediately after a component is mounted (inserted into the tree). Initialization that requires DOM nodes should go here. If you need to load data from a remote endpoint, this is a good place to instantiate the network request.
+`componentDidMount()` فورا پس از اجرا و نصب اولیه‌ی یک کامپوننت (زمانی که در درخت درج می‌شود) صدا زده می‌شود. مقداردهی اولیه‌ای که نودهای DOM نیاز دارند باید اینجا باشد. در صورتی که نیاز دارید که از یک endpoint راه دور داده دریافت کنید، اینجا محل خوبی برای پیاده‌سازی درخواست‌‌های شبکه است.
 
-This method is a good place to set up any subscriptions. If you do that, don't forget to unsubscribe in `componentWillUnmount()`.
+این متد مکان خوبی برای تنظیم کردن هرگونه اشتراکی می‌باشد. اگر اینکار را انجام دهید، لغو اشتراک در `componentWillUnmount()` فراموش نکنید.
 
-You **may call `setState()` immediately** in `componentDidMount()`. It will trigger an extra rendering, but it will happen before the browser updates the screen. This guarantees that even though the `render()` will be called twice in this case, the user won't see the intermediate state. Use this pattern with caution because it often causes performance issues. In most cases, you should be able to assign the initial state in the `constructor()` instead. It can, however, be necessary for cases like modals and tooltips when you need to measure a DOM node before rendering something that depends on its size or position.
+شما **ممکن است `setState()` را فورا** در `componentDidMount()` **صدا بزنید.** این باعث یک رندر اضافی می‌شود، اما قبل از اینکه مرورگر صفحه را بروز کند اتفاق می‌افتد و تضمین می‌کند که حتی با وجود اینکه `render()` در این مورد دو بار صدا زده خواهد شد، کاربر state واسطی را نخواهد دید. از این الگو با‌احتیاط استفاده کنید چرا که اغلب موارد باعث مشکلات پرفورمنس و بهره‌وری خواهد شد. در عوض در اکثر موارد، شما باید بتوانید state اولیه را در `constructor()` مقداردهی کنید. به هر حال اینکار می‌تواند برای مواردی مانند modal ها و یا tooltip ها، زمانی که شما نیاز به بررسی یک نود DOM قبل از رندر شدن چیزی که وابسته به ابعاد و مکانش است دارید، ضروری می‌باشد.
 
 * * *
 
@@ -208,9 +208,9 @@ You **may call `setState()` immediately** in `componentDidMount()`. It will trig
 componentDidUpdate(prevProps, prevState, snapshot)
 ```
 
-`componentDidUpdate()` is invoked immediately after updating occurs. This method is not called for the initial render.
+`componentDidUpdate()` بلافاصله پس از رخ دادن هر بروزرسانی صدا زده می‌شود. این متد برای رندر اولیه صدا زده نمی‌شود.
 
-Use this as an opportunity to operate on the DOM when the component has been updated. This is also a good place to do network requests as long as you compare the current props to previous props (e.g. a network request may not be necessary if the props have not changed).
+از این فرصت برای انجام عملیات بر روی DOM در زمانی که کامپوننت بروز شده‌است استفاده کنید. همچنین مکان مناسبی برای انجام درخواست‌های شبکه،  مادامی که props فعلی را با props قبلی مقایسه می‌کنید می‌باشد (برای مثال درخواست شبکه در صورتی که props تغییری نکرده است ضروری نیست ).
 
 ```js
 componentDidUpdate(prevProps) {
@@ -221,13 +221,13 @@ componentDidUpdate(prevProps) {
 }
 ```
 
-You **may call `setState()` immediately** in `componentDidUpdate()` but note that **it must be wrapped in a condition** like in the example above, or you'll cause an infinite loop. It would also cause an extra re-rendering which, while not visible to the user, can affect the component performance. If you're trying to "mirror" some state to a prop coming from above, consider using the prop directly instead. Read more about [why copying props into state causes bugs](/blog/2018/06/07/you-probably-dont-need-derived-state.html).
+شما ممکن است **`setState()` را فورا** در `componentDidUpdate()` **صدا بزنید** اما در نظر داشته باشید که مانند مثال بالا **باید در یک شرط قرار داشته باشد.** در غیر اینصورت شما در یک حلقه‌ی بی‌نهایت گرفتار خواهید شد. همچنین باعث رندر اضافی می‌شود که گرچه برای کاربر قابل مشاهده نیست، می‌تواند بر روی پرفورمنس و بهره‌وری کامپوننت تاثیر گذارد. اگر تلاش می‌کنید تا بعضی state ها را به یک prop که از بالا می‌آید "mirror" کنید، استفاده مستقیم از prop را به عنوان جایگزین در نظر بگیرید. در مورد [چرا کپی کردن props در state باعث باگ می‌شود؟](/blog/2018/06/07/you-probably-dont-need-derived-state.html) بخوانید.
 
-If your component implements the `getSnapshotBeforeUpdate()` lifecycle (which is rare), the value it returns will be passed as a third "snapshot" parameter to `componentDidUpdate()`. Otherwise this parameter will be undefined.
+اگر کامپوننت شما چرخه‌ی حیات `getSnapshotBeforeUpdate()` را پیاده‌سازی می‌کند (که نادر است)، مقداری که برمی‌گرداند به عنوان پارامتر سوم "snapshot" به `componentDidUpdate()` پاس داده می‌شود. در غیر اینصورت این پارامتر undefined خواهد بود.
 
-> Note
+> نکته
 >
-> `componentDidUpdate()` will not be invoked if [`shouldComponentUpdate()`](#shouldcomponentupdate) returns false.
+> اگر [`shouldComponentUpdate()`](#shouldcomponentupdate)، false بازگرداند، `componentDidUpdate()` اجرا نخواهد شد.
 
 * * *
 
@@ -237,15 +237,15 @@ If your component implements the `getSnapshotBeforeUpdate()` lifecycle (which is
 componentWillUnmount()
 ```
 
-`componentWillUnmount()` is invoked immediately before a component is unmounted and destroyed. Perform any necessary cleanup in this method, such as invalidating timers, canceling network requests, or cleaning up any subscriptions that were created in `componentDidMount()`.
+`componentWillUnmount()` بلافاصله قبل از اینکه یک کامپوننت نابود شود صدا زده می‌شود. هر گونه پاکسازی ضروری مانند غیرفعالسازی تایمرها، کنسل کردن درخواست‌های شبکه و یا لغو اشتراک‌های ایجاد شده در `componentDidMount()`، در این متد انجام می‌پذیرد.
 
-You **should not call `setState()`** in `componentWillUnmount()` because the component will never be re-rendered. Once a component instance is unmounted, it will never be mounted again.
+در `componentWillUnmount()` **نباید `setState()` را صدا بزنید** چرا که کامپوننت هیچگاه دوباره رندر نخواهد شد. به محض اینکه یک instance کامپوننت نابود می‌شود، هرگز دوباره نصب و اجرا نخواهد شد.
 
 * * *
 
-### Rarely Used Lifecycle Methods {#rarely-used-lifecycle-methods}
+### متدهای چرخه‌ی حیات با کاربرد کم {#rarely-used-lifecycle-methods}
 
-The methods in this section correspond to uncommon use cases. They're handy once in a while, but most of your components probably don't need any of them. **You can see most of the methods below on [this lifecycle diagram](http://projects.wojtekmaj.pl/react-lifecycle-methods-diagram/) if you click the "Show less common lifecycles" checkbox at the top of it.**
+متدهای این بخش به موارد استفاده غیررایج مربوط هستند. آن‌ها یک زمانی کاربردی بودند، اما کامپوننت‌های شما احتمالا نیازی به هیچ‌یک از آن‌ها نخواهند داشت. **شما می‌توانید اکثر این متدها را در [این دیاگرام چرخه‌ی حیات](http://projects.wojtekmaj.pl/react-lifecycle-methods-diagram/) ببینید. برای این منظور بر روی "Show less common lifecycles" در بالای ان کلیک کنید.**
 
 
 ### `shouldComponentUpdate()` {#shouldcomponentupdate}
@@ -254,17 +254,17 @@ The methods in this section correspond to uncommon use cases. They're handy once
 shouldComponentUpdate(nextProps, nextState)
 ```
 
-Use `shouldComponentUpdate()` to let React know if a component's output is not affected by the current change in state or props. The default behavior is to re-render on every state change, and in the vast majority of cases you should rely on the default behavior.
+از `shouldComponentUpdate()` استفاده کنید تا به ری‌اکت اجازه دهید تا در صورتی که خروجی کامپوننت توسط تغییر کنونی در state یا props متاثر نشده است بداند. رفتار پیش‌فرض این متد، رندر دوباره به ازای هر تغییر در state است، که در اکثریت قریب به اتفاق موارد شما باید به رفتار پیش‌فرض آن اعتماد کنید.
 
-`shouldComponentUpdate()` is invoked before rendering when new props or state are being received. Defaults to `true`. This method is not called for the initial render or when `forceUpdate()` is used.
+`shouldComponentUpdate()` قبل از رندر شدن در هنگام دریافت state یا props جدید صدا زده می‌شود. به طور پیش‌فرض مقدار `true` برمی‌گرداند. این متد هنگام رندر اولیه یا زمانی که `forceUpdate()` استفاده می‌شود صدا زده نمی‌شود.
 
-This method only exists as a **[performance optimization](/docs/optimizing-performance.html).** Do not rely on it to "prevent" a rendering, as this can lead to bugs. **Consider using the built-in [`PureComponent`](/docs/react-api.html#reactpurecomponent)** instead of writing `shouldComponentUpdate()` by hand. `PureComponent` performs a shallow comparison of props and state, and reduces the chance that you'll skip a necessary update.
+این متد تنها به عنوان یک **[بهینه‌سازی پرفورمنس و بهره‌وری](/docs/optimizing-performance.html)** وجود دارد. برای جلوگیری از یک رندر از آن استفاده نکنید چرا که باعث بروز باگ‌ها می‌شود. استفاده از **[`PureComponent`](/docs/react-api.html#reactpurecomponent) داخلی** را به جای نوشتن دستی `shouldComponentUpdate()` **در نظر بگیرید.** `PureComponent` یک مقایسه سطحی میان props و state انجام می‌دهد و شانس اینکه شما یک بروزرسانی ضروری را رد کنی کاهش می‌دهد.
 
-If you are confident you want to write it by hand, you may compare `this.props` with `nextProps` and `this.state` with `nextState` and return `false` to tell React the update can be skipped. Note that returning `false` does not prevent child components from re-rendering when *their* state changes.
+اگر شما از نوشتن دستی آن مطمئن هستید، شما ممکن است `this.props` را با `nextProps` و `this.state` را با `nextState` مقایسه کنید و در صورتی که بروزرسانی می‌تواند رد شود با بازگرداندن `false` این مورد را به ری‌اکت اطلاع دهید. توجه داشته باشید که بازگرداندن `false`، کامپوننت‌‌های فرزند را در هنگام تغییرات state *آن‌ها*، از رندر شدن دوباره منع نمی‌کند.
 
-We do not recommend doing deep equality checks or using `JSON.stringify()` in `shouldComponentUpdate()`. It is very inefficient and will harm performance.
+ما بررسی برابری‌های عمیق یا استفاده از `JSON.stringify()` را در `shouldComponentUpdate()` پیشنهاد نمی‌کنیم چرا که بسیار ناکارآمد است و به پرفورمنس ضربه می‌زند.
 
-Currently, if `shouldComponentUpdate()` returns `false`, then [`UNSAFE_componentWillUpdate()`](#unsafe_componentwillupdate), [`render()`](#render), and [`componentDidUpdate()`](#componentdidupdate) will not be invoked. In the future React may treat `shouldComponentUpdate()` as a hint rather than a strict directive, and returning `false` may still result in a re-rendering of the component.
+در حال حاضر، اگر `shouldComponentUpdate()`، مقدار `false` بازگرداند، [`UNSAFE_componentWillUpdate()`](#unsafe_componentwillupdate)، [`render()`](#render) و [`componentDidUpdate()`](#componentdidupdate) صدا زده نخواهند شد. در آینده ممکن است ری‌اکت با `shouldComponentUpdate()` به جای یک بخشنامه سختگیرانه، مانند یک راهنمایی رفتار کند و امکان دوباره رندر شدن کامپوننت در صورت بازگرداندن `false` همچنان موجود باشد.
 
 * * *
 
@@ -274,22 +274,22 @@ Currently, if `shouldComponentUpdate()` returns `false`, then [`UNSAFE_component
 static getDerivedStateFromProps(props, state)
 ```
 
-`getDerivedStateFromProps` is invoked right before calling the render method, both on the initial mount and on subsequent updates. It should return an object to update the state, or null to update nothing.
+`getDerivedStateFromProps` درست بعد از فراخوانی متد رندر، در هر دو حالت نصب و اجرای اولیه و بروزرسانی‌های بعد از آن صدا زده می‌شود. این متد باید یک آبجکت برای بروزرسانی state، و یا null برای عدم بروزرسانی بازگرداند.
 
-This method exists for [rare use cases](/blog/2018/06/07/you-probably-dont-need-derived-state.html#when-to-use-derived-state) where the state depends on changes in props over time. For example, it might be handy for implementing a `<Transition>` component that compares its previous and next children to decide which of them to animate in and out.
+این متد برای [موارد استفاده نادر](/blog/2018/06/07/you-probably-dont-need-derived-state.html#when-to-use-derived-state) که state وابسته به تغییرات props در طول زمان است وجود دارد. برای مثال، ممکن است برای پیاده‌سازی یک کامپوننت `<Transition>` که فرزند قبلی و بعدی خود را برای تصمیم‌گیری اینکه برای کدام‌یک انیمیشن ورود و برای کدام‌یک انیمیشن خروج را اعمال کند مقایسه می‌کند، کاربردی باشد.
 
-Deriving state leads to verbose code and makes your components difficult to think about.  
-[Make sure you're familiar with simpler alternatives:](/blog/2018/06/07/you-probably-dont-need-derived-state.html)
+اشتقاق state باعث بلندی کد می‌شود و فکر کردن در مورد کامپوننت شما را سخت می‌کند.
+[مطمئن شوید با جایگزین‌های ساده‌تر آشنا هستید:](/blog/2018/06/07/you-probably-dont-need-derived-state.html)
 
-* If you need to **perform a side effect** (for example, data fetching or an animation) in response to a change in props, use [`componentDidUpdate`](#componentdidupdate) lifecycle instead.
+* اگر نیاز به **انجام یک تاثیر بیرونی** (برای مثال fetch کردن داده یا اعمال انیمیشن) در پاسخ یک تغییر در props دارید، از متد چرخه‌ی حیات [`componentDidUpdate`](#componentdidupdate) به عنوان جایگزین استفاده کنید.
 
-* If you want to **re-compute some data only when a prop changes**, [use a memoization helper instead](/blog/2018/06/07/you-probably-dont-need-derived-state.html#what-about-memoization).
+* اگر می‌خواهید **بعضی داده‌ها را فقط زمان تغییرات یک props محاسبه کنید**، [از یک memoization به عنوان جایگزین استفاده کنید](/blog/2018/06/07/you-probably-dont-need-derived-state.html#what-about-memoization).
 
-* If you want to **"reset" some state when a prop changes**, consider either making a component [fully controlled](/blog/2018/06/07/you-probably-dont-need-derived-state.html#recommendation-fully-controlled-component) or [fully uncontrolled with a `key`](/blog/2018/06/07/you-probably-dont-need-derived-state.html#recommendation-fully-uncontrolled-component-with-a-key) instead.
+* اگر میخواهید **بعضی state ها را زمان تغییرات یک prop "reset" کنید**، ساخت یک کامپوننت [کاملا کنترل شده](/blog/2018/06/07/you-probably-dont-need-derived-state.html#recommendation-fully-controlled-component) یا [کاملا کنترل نشده با یک `key`](/blog/2018/06/07/you-probably-dont-need-derived-state.html#recommendation-fully-uncontrolled-component-with-a-key) را به عنوان جایگزین در نظر بگیرید.
 
-This method doesn't have access to the component instance. If you'd like, you can reuse some code between `getDerivedStateFromProps()` and the other class methods by extracting pure functions of the component props and state outside the class definition.
+این متد به instance کامپوننت دسترسی ندارد. اگر مایل هستید، می‌توانید از بعضی کدها میان `getDerivedStateFromProps()` و دیگر متدهای کلاس برای استخراج توابع خالص props کامپوننت و state، خارج از تعریف کلاس دوباره استفاده کنید.
 
-Note that this method is fired on *every* render, regardless of the cause. This is in contrast to `UNSAFE_componentWillReceiveProps`, which only fires when the parent causes a re-render and not as a result of a local `setState`.
+در نظر داشته باشید این متد بدون در نظر گرفتن دلیل، با *هر* رندر اجرا می‌شود. بنابراین با `UNSAFE_componentWillReceiveProps`، که تنها زمانی که والد باعث یک رندر دوباره است و در نتیجه یک `setState` محلی نیست، در تضاد است.
 
 * * *
 
@@ -299,41 +299,41 @@ Note that this method is fired on *every* render, regardless of the cause. This
 getSnapshotBeforeUpdate(prevProps, prevState)
 ```
 
-`getSnapshotBeforeUpdate()` is invoked right before the most recently rendered output is committed to e.g. the DOM. It enables your component to capture some information from the DOM (e.g. scroll position) before it is potentially changed. Any value returned by this lifecycle will be passed as a parameter to `componentDidUpdate()`.
+`getSnapshotBeforeUpdate()` درست قبل از آخرین خروجی رندر شده‌ای که به DOM سپرده شده‌است صدا زده می‌شود و کامپوننت شما را توانا می‌سازد تا بعضی اطلاعات را (مانند اسکرول کردن مکان صفحه) قبل از اینکه بالقوه تغییر کند از DOM بگیرد. هر مقداری که توسط ین چرخه‌ی حیات بازگردد به عنوان یک پارامتر به `componentDidUpdate()` پاس داده خواهد شد.
 
-This use case is not common, but it may occur in UIs like a chat thread that need to handle scroll position in a special way.
+این مورد استفاده رایج نیست، اما ممکن است در UI هایی مانند صفحه‌ی چت که کنترل مکان اسکرول به شکلی خاص نیاز است، رخ دهد.
 
-A snapshot value (or `null`) should be returned.
+یک مثدار snapshot (یا `null`) باید بازگردانده شود.
 
-For example:
+برای مثال:
 
 `embed:react-component-reference/get-snapshot-before-update.js`
 
-In the above examples, it is important to read the `scrollHeight` property in `getSnapshotBeforeUpdate` because there may be delays between "render" phase lifecycles (like `render`) and "commit" phase lifecycles (like `getSnapshotBeforeUpdate` and `componentDidUpdate`).
+در مثال بالا، خواندن ویژگی `scrollHeight` در `getSnapshotBeforeUpdate` مهم است چرا که ممکن است تاخیرهایی بین فاز "رندر شدن" چرخه‌ی حیات (مانند `render`) و فاز "commit" چرخه‌ی حیات (مانند `getSnapshotBeforeUpdate` و `componentDidUpdate`) وجود داشته باشد.
 
 * * *
 
 ### Error boundaries {#error-boundaries}
 
-[Error boundaries](/docs/error-boundaries.html) are React components that catch JavaScript errors anywhere in their child component tree, log those errors, and display a fallback UI instead of the component tree that crashed. Error boundaries catch errors during rendering, in lifecycle methods, and in constructors of the whole tree below them.
+[Error boundaries](/docs/error-boundaries.html) کامپوننت‌های ری‌اکت هستند که خطاهای جاوااسکریپت را هر جایی در درخت کامپوننت‌های فرزندشان می‌گیرند، آن ارورها را در کنسول در قالب لاگ نشان می‌دهند و یک UI به جای درخت کامپوننتی که کرش کرده است نمایش می‌دهد. Error boundaries خطاها را هنگام رندر شدن، در متدهای چرخه‌ی حیات و در سازنده‌های تمام درخت زیر آن‌ها می‌گیرند.
 
-A class component becomes an error boundary if it defines either (or both) of the lifecycle methods `static getDerivedStateFromError()` or `componentDidCatch()`. Updating state from these lifecycles lets you capture an unhandled JavaScript error in the below tree and display a fallback UI.
+یک کلاس کامپوننت در صورتی که هر یک از متدهای چرخه‌ی حیات `static getDerivedStateFromError()` یا `componentDidCatch()` یا هردو تعریف شده باشند یک error boundary می‌شود. بروزرسانی state از این متدهای چرخه‌ی حیات به شما اجازه می‌دهد تا خطاهای کنترل نشده‌ی جاوااسکریپتی در درخت زیر آن را بگیرید و یک UI مناسب نمایش دهید.
 
-Only use error boundaries for recovering from unexpected exceptions; **don't try to use them for control flow.**
+فقط برای بازیابی از خطاهای غیرقابل انتظار از error boundaries استفاده کنید; **برای کنترل جریان از آن‌ها استفاده نکنید.**
 
-For more details, see [*Error Handling in React 16*](/blog/2017/07/26/error-handling-in-react-16.html).
+برای اطلاعات بیشتر، [*کنترل خطاها در ری‌اکت 16*](/blog/2017/07/26/error-handling-in-react-16.html) را ببینید.
 
-> Note
+> نکته
 > 
-> Error boundaries only catch errors in the components **below** them in the tree. An error boundary can’t catch an error within itself.
+> Error boundaries تنها خطاهای کامپوننت‌های **زیر** خودشان در درخت را می‌گیرند. یک error boundary نمی‌تواند خطای درون خودش را بگیرد.
 
 ### `static getDerivedStateFromError()` {#static-getderivedstatefromerror}
 ```javascript
 static getDerivedStateFromError(error)
 ```
 
-This lifecycle is invoked after an error has been thrown by a descendant component.
-It receives the error that was thrown as a parameter and should return a value to update state.
+این چرخه‌ی حیات بعد از اینکه یک خطا توسط کامپوننت‌های زاده اولادش رخ داد صدا زده می‌شود.
+خطایی که رخ داده است را به عنوان یک پارامتر دریافت می‌کند و باید یک مثدار برای بروزرسانی state بازگرداند.
 
 ```js{7-10,13-16}
 class ErrorBoundary extends React.Component {
@@ -358,10 +358,10 @@ class ErrorBoundary extends React.Component {
 }
 ```
 
-> Note
+> نکته
 >
-> `getDerivedStateFromError()` is called during the "render" phase, so side-effects are not permitted.
-For those use cases, use `componentDidCatch()` instead.
+> `getDerivedStateFromError()` در فاز "رندر شدن" صدا زده می‌شود، بنابراین تاثیرات جانبی مجاز نیستند.
+برای آن موارد، از `componentDidCatch()` استفاده کنید.
 
 * * *
 
@@ -371,15 +371,14 @@ For those use cases, use `componentDidCatch()` instead.
 componentDidCatch(error, info)
 ```
 
-This lifecycle is invoked after an error has been thrown by a descendant component.
-It receives two parameters:
+این چرخه‌ی حیات بعد از اینکه یک خطا توسط کامپوننت‌های زاده اولاد رخ دهد صدا زده می‌شود.
+دو پارامتر دریافت می‌کند:
 
-1. `error` - The error that was thrown.
-2. `info` - An object with a `componentStack` key containing [information about which component threw the error](/docs/error-boundaries.html#component-stack-traces).
+1. `error` - خطایی که رخ داده است.
+2. `info` - یک آبجت با کلید `componentStack` شامل [اطلاعات در مورد اینکه در کدام کامپوننت خطا رخ داده است](/docs/error-boundaries.html#component-stack-traces).
 
-
-`componentDidCatch()` is called during the "commit" phase, so side-effects are permitted.
-It should be used for things like logging errors:
+`componentDidCatch()` در فاز "commit" صدا زده می‌شود، بنابراین تاثیرات جانبی مجاز هستند.
+باید برای چیزهایی مانند لاگ انداختن خطاها استفاده شود:
 
 ```js{12-19}
 class ErrorBoundary extends React.Component {
@@ -413,16 +412,16 @@ class ErrorBoundary extends React.Component {
 }
 ```
 
-> Note
+> نکته
 > 
-> In the event of an error, you can render a fallback UI with `componentDidCatch()` by calling `setState`, but this will be deprecated in a future release.
-> Use `static getDerivedStateFromError()` to handle fallback rendering instead.
+> هنگام رویداد یک خطا، شما می‌توانید با صدا زدن `setState` یک UI به وسیله `componentDidCatch()` رندر کند، اما این در انتشارهای آینده منسوخ خواهد شد.
+> از `static getDerivedStateFromError()` برای کنترل رندر کردن UI هنگام بروز خطا استفاده نمایید.
 
 * * *
 
-### Legacy Lifecycle Methods {#legacy-lifecycle-methods}
+### متدهای چرخه‌ی حیات قدیمی {#legacy-lifecycle-methods}
 
-The lifecycle methods below are marked as "legacy". They still work, but we don't recommend using them in the new code. You can learn more about migrating away from legacy lifecycle methods in [this blog post](/blog/2018/03/27/update-on-async-rendering.html).
+متدهای چرخه‌ی حیات زیر به عنوان "قدیمی" نشانه گذاری شده‌اند. آن‌ها همچنان کار می‌کنند، اما ما استفاده از آن‌ها را در کدهای جدید پیشنهاد نمی‌کنیم. شما می‌توانید [در این مطلب وبلاگ](/blog/2018/03/27/update-on-async-rendering.html) در مورد مهاجرت از متدهای چرخه‌ی حیات قدیمی بیشتر یاد بگیرید.
 
 ### `UNSAFE_componentWillMount()` {#unsafe_componentwillmount}
 
@@ -430,15 +429,15 @@ The lifecycle methods below are marked as "legacy". They still work, but we don'
 UNSAFE_componentWillMount()
 ```
 
-> Note
+> نکته
 >
-> This lifecycle was previously named `componentWillMount`. That name will continue to work until version 17. Use the [`rename-unsafe-lifecycles` codemod](https://github.com/reactjs/react-codemod#rename-unsafe-lifecycles) to automatically update your components.
+> این چرخه‌ی حیات قبلا `componentWillMount` نام داشت. این اسم تا نسخه ۱۷ کار خواهد کرد. از [`rename-unsafe-lifecycles` codemod](https://github.com/reactjs/react-codemod#rename-unsafe-lifecycles) برای بروزرسانی خودکار کامپوننت‌هایتان استفاده کنید.
 
-`UNSAFE_componentWillMount()` is invoked just before mounting occurs. It is called before `render()`, therefore calling `setState()` synchronously in this method will not trigger an extra rendering. Generally, we recommend using the `constructor()` instead for initializing state.
+`UNSAFE_componentWillMount()` درست قبل از نصب و اجرای اولیه صدا زده می‌شود. قبل از `render()` صدا زده می‌شود، بنابراین صدا زدن `setState()` به صورت synchronous در این متد باعث رندر اضافه نخواهد شد. عموما، ما استفاده از `constructor()` را برای مقداردهی اولیه state پیشنهاد می‌کنیم.
 
-Avoid introducing any side-effects or subscriptions in this method. For those use cases, use `componentDidMount()` instead.
+از معرفی هرگونه تاثیر جانبی و یا ثبت اشتراک در این متد خودداری کنید. برای چنین موارد استفاده‌ای، از `componentDidMount()` استفاده کنید.
 
-This is the only lifecycle method called on server rendering.
+این تنها متد چرخه‌ی حیاتی است که در رندر شدن سمت سرور صدا زده می‌شود.
 
 * * *
 
@@ -448,25 +447,26 @@ This is the only lifecycle method called on server rendering.
 UNSAFE_componentWillReceiveProps(nextProps)
 ```
 
-> Note
+> نکته
 >
-> This lifecycle was previously named `componentWillReceiveProps`. That name will continue to work until version 17. Use the [`rename-unsafe-lifecycles` codemod](https://github.com/reactjs/react-codemod#rename-unsafe-lifecycles) to automatically update your components.
+> این چرخه‌ی حیات قبلا `componentWillReceiveProps` نام داشت. این نام تا نسخه 17 کار خواهد کرد. برای بروزرسانی خودکار کامپوننت‌هایتان از [`rename-unsafe-lifecycles` codemod](https://github.com/reactjs/react-codemod#rename-unsafe-lifecycles) استفاده نمایید.
 
-> Note:
+> نکته:
 >
-> Using this lifecycle method often leads to bugs and inconsistencies
+> استفاده از این متد چرخه‌ی حیات اغلب منجر به باگ‌ها و ناپایداری‌ها می‌شود
 >
-> * If you need to **perform a side effect** (for example, data fetching or an animation) in response to a change in props, use [`componentDidUpdate`](#componentdidupdate) lifecycle instead.
-> * If you used `componentWillReceiveProps` for **re-computing some data only when a prop changes**, [use a memoization helper instead](/blog/2018/06/07/you-probably-dont-need-derived-state.html#what-about-memoization).
-> * If you used `componentWillReceiveProps` to **"reset" some state when a prop changes**, consider either making a component [fully controlled](/blog/2018/06/07/you-probably-dont-need-derived-state.html#recommendation-fully-controlled-component) or [fully uncontrolled with a `key`](/blog/2018/06/07/you-probably-dont-need-derived-state.html#recommendation-fully-uncontrolled-component-with-a-key) instead.
+> * اگر نیاز به **انجام یک اثر جانبی** (برای مثال fetch کردن داده و یا اعمال انیمیشن) در پاسخ یک تغییر در props دارید، از چرخه‌ی حیات [`componentDidUpdate`](#componentdidupdate) به عنوان جایگزین استفاده نمایید.
+> اگر از `componentWillReceiveProps` برای **محاسبه مجدد برخی داده‌ها زمانی که یک prop تغییر می‌کند** دارید استفاده می‌کردید، [از یک راهنمای memoization استفاده نمایید](/blog/2018/06/07/you-probably-dont-need-derived-state.html#what-about-memoization).
+> * اگر از `componentWillReceiveProps` برای **"reset" کردن بعضی state ها هنگام تغییر یک prop** استفاده می‌کردید، ایجاد یک کامپوننت [کاملا کنترل شده](/blog/2018/06/07/you-probably-dont-need-derived-state.html#recommendation-fully-controlled-component) یا [کاملا کنترل نشده با یک `key`](/blog/2018/06/07/you-probably-dont-need-derived-state.html#recommendation-fully-uncontrolled-component-with-a-key) به عنوان جایگزین را در نظر بگیرید.
 >
-> For other use cases, [follow the recommendations in this blog post about derived state](/blog/2018/06/07/you-probably-dont-need-derived-state.html).
+> برای چنین مواردی، [پیشنهادهای این مطلب وبلاگ در مورد state مشتق شده را دنبال کنید](/blog/2018/06/07/you-probably-dont-need-derived-state.html).
 
-`UNSAFE_componentWillReceiveProps()` is invoked before a mounted component receives new props. If you need to update the state in response to prop changes (for example, to reset it), you may compare `this.props` and `nextProps` and perform state transitions using `this.setState()` in this method.
+`UNSAFE_componentWillReceiveProps()` قبل از اینکه یک کامپوننت ایجاد شده props جدید دریافت کند صدا زده می‌شود. اگر نیاز به بروزرسانی state در پاسخ به تغییرات prop دارید (برای مثال reset کردن آن)، ممکن است `this.props` و `nextProps` را مقایسه کنید و یک تغییر state به وسیله `this.setState()` را در این متد انجام دهید.
 
-Note that if a parent component causes your component to re-render, this method will be called even if props have not changed. Make sure to compare the current and next values if you only want to handle changes.
+توجه داشته باشید که اگر یک کامپوننت والد، دلیل دوباره رندر شدن کامپوننت شما باشد، حتی اگر props تغییری نکرده باشد، این متد صدا زده می‌شود. بنابراین اگر می‌خواهید تغییرات را کنترل کنید، از مقیسه مقدار فعلی و بعدی آن مطمئن شوید.
 
-React doesn't call `UNSAFE_componentWillReceiveProps()` with initial props during [mounting](#mounting). It only calls this method if some of component's props may update. Calling `this.setState()` generally doesn't trigger `UNSAFE_componentWillReceiveProps()`.
+ری‌اکت `UNSAFE_componentWillReceiveProps()` را با props اولیه هنگام [نصب و اجرای اولیه](#mounting) صدا نمی‌زند. فقط زمانی این متد صدا زده می‌شود که بعضی از props کامپوننت احتمال تغییر داشته باشند.
+صدا زدن `this.setState()` عموما باعث اجرای `UNSAFE_componentWillReceiveProps()` نمی‌شود.
 
 * * *
 
@@ -476,27 +476,27 @@ React doesn't call `UNSAFE_componentWillReceiveProps()` with initial props durin
 UNSAFE_componentWillUpdate(nextProps, nextState)
 ```
 
-> Note
+> نکته
 >
-> This lifecycle was previously named `componentWillUpdate`. That name will continue to work until version 17. Use the [`rename-unsafe-lifecycles` codemod](https://github.com/reactjs/react-codemod#rename-unsafe-lifecycles) to automatically update your components.
+> این چرخه‌ی حیات قبلا `componentWillUpdate` نام داشت. این اسم تا نسخه 17 کار می‌کند. برای بروزرسانی خودکار کامپوننت‌هایتان از [`rename-unsafe-lifecycles` codemod](https://github.com/reactjs/react-codemod#rename-unsafe-lifecycles) استفاده نمایید.
 
-`UNSAFE_componentWillUpdate()` is invoked just before rendering when new props or state are being received. Use this as an opportunity to perform preparation before an update occurs. This method is not called for the initial render.
+`UNSAFE_componentWillUpdate()` درست قبل از رندر شدن، زمانی که props یا state جدید دریافت می‌شوند صدا زده می‌شود. از این مورد به عنوان یک فرصت برای انجام آماده‌سازی‌های لازم قبل از بروز بروزرسانی استفاده نمایید. این متد برای رندر اولیه صدا زده نمی‌شود.
 
-Note that you cannot call `this.setState()` here; nor should you do anything else (e.g. dispatch a Redux action) that would trigger an update to a React component before `UNSAFE_componentWillUpdate()` returns.
+توجه داشته باشید که نمی‌توانید `this.setState()` را اینجا صدا بزنید; همچنین هیچ کار دیگری که باعث بروز یک بروزرسانی برای یک کامپوننت ری‌اکت (e.g. dispatch a Redux action) می‌شود تا قبل از اینکه `UNSAFE_componentWillUpdate()` مقداری را بازگرداند نباید انجام دهید.
 
-Typically, this method can be replaced by `componentDidUpdate()`. If you were reading from the DOM in this method (e.g. to save a scroll position), you can move that logic to `getSnapshotBeforeUpdate()`.
+معمولا، این متد می‌تواند به وسیله `componentDidUpdate()` جایگزین شود. اگر شما در این متد چیزی را از DOM می‌خوانید (برای مثال ذخیره محل اسکرول)، شما می‌توانید آن منطق را به `getSnapshotBeforeUpdate()` منتقل کنید.
 
-> Note
+> نکته
 >
-> `UNSAFE_componentWillUpdate()` will not be invoked if [`shouldComponentUpdate()`](#shouldcomponentupdate) returns false.
+> `UNSAFE_componentWillUpdate()` در صورتی که [`shouldComponentUpdate()`](#shouldcomponentupdate) مقدار false بازگرداند فراخوانی نمی‌شود.
 
 * * *
 
-## Other APIs {#other-apis-1}
+## دیگر API ها {#other-apis-1}
 
-Unlike the lifecycle methods above (which React calls for you), the methods below are the methods *you* can call from your components.
+برخلاف متدهای چرخه‌ی حیات بالا (که ری‌اکت برای شما صدا می‌زند)، متدهای زیر، متدهایی هستند که *شما* می‌توانید از کامپوننت‌هایتان صدا بزنید.
 
-There are just two of them: `setState()` and `forceUpdate()`.
+فقط دو تا از آن‌ها وجود دارد: `setState()` و `forceUpdate()`.
 
 ### `setState()` {#setstate}
 
@@ -504,21 +504,21 @@ There are just two of them: `setState()` and `forceUpdate()`.
 setState(updater, [callback])
 ```
 
-`setState()` enqueues changes to the component state and tells React that this component and its children need to be re-rendered with the updated state. This is the primary method you use to update the user interface in response to event handlers and server responses.
+`setState()` تغییرات را در state کامپوننت درج می‌کند و به ری‌اکت می‌گوید که این کامپوننت و فزندانش نیاز به یک رندر دوباره با state بروز شده دارند. این متد اصلی است که شما برای بروزرسانی رابط کاربری در پاسخ به کنترل کننده‌های رویدادها و پاسخ‌های سرور استفاده می‌نمایید.
 
-Think of `setState()` as a *request* rather than an immediate command to update the component. For better perceived performance, React may delay it, and then update several components in a single pass. React does not guarantee that the state changes are applied immediately.
+`setState()` را به عنوان یک *درخواست* و نه یک دستور برای بروزرسانی کامپوننت در نظر بگیرید. برای حس کردن پرفورمنس بهتر، ری‌اکت ممکن است آن را به تاخیر بیاندازد، و سپس چندین کامپوننت را در یک لحظه بروز کند. ری‌اکت تضمین نمی‌کند که تغییرات state فورا اعمال شوند.
 
-`setState()` does not always immediately update the component. It may batch or defer the update until later. This makes reading `this.state` right after calling `setState()` a potential pitfall. Instead, use `componentDidUpdate` or a `setState` callback (`setState(updater, callback)`), either of which are guaranteed to fire after the update has been applied. If you need to set the state based on the previous state, read about the `updater` argument below.
+`setState()` همیشه در لحظه کامپوننت را بروز نمی‌کند. ممکن است تغییر را بسته‌بندی کرده و یا به تاخیر انداخته باشد. این موضوع خواندن `this.state` درست پس از صدا زدن `setState()` را به یک تله تبدیل کرده‌است. به جای اینکار، از `componentDidUpdate` یا یک `setState` callback (`setState(updater, callback)`) استفاده کنید، که اجرا شدن هر دو پس از اینکه بروزرسانی اعمال شده است، تضمین شده است. اگر نیاز به ست کردن state بر اساس state قبلی دارید، در مورد آرگومان `updater` در زیر بخوانید.
 
-`setState()` will always lead to a re-render unless `shouldComponentUpdate()` returns `false`. If mutable objects are being used and conditional rendering logic cannot be implemented in `shouldComponentUpdate()`, calling `setState()` only when the new state differs from the previous state will avoid unnecessary re-renders.
+`setState()` همیشه منجر به یک رندر دوباره می‌شود مگر اینکه `shouldComponentUpdate()` مقدار `false` را بازگرداند. اگر در حال استفاده از آبجکت‌های قابل تغییر هستید و منطق رندرشدن شرطی نمی‌تواند در `shouldComponentUpdate()` پیاده‌سازی شود، صدا زدن `setState()` تنها زمانی که state جدید با state قبلی متفاوت است از رندر دوباره غیرضروری جلوگیری می‌کند.
 
-The first argument is an `updater` function with the signature:
+اولین آگومان یک تابع `updater` با امضا است:
 
 ```javascript
 (state, props) => stateChange
 ```
 
-`state` is a reference to the component state at the time the change is being applied. It should not be directly mutated. Instead, changes should be represented by building a new object based on the input from `state` and `props`. For instance, suppose we wanted to increment a value in state by `props.step`:
+`state` یک مرجع برای state کامپوننت در زمانی که تغییرات اعمال می‌شوند، می‌باشد. نباید مستقیما تغییر کند. به جای این کار، تغییرات باید با ساخت یک آبجکت جدید بر اساس `state` و `props` ورودی بیان شوند. برای نمونه، فرض کنید می‌خواهیم یک مقدار در state را بر اساس `props.step` افزایش دهیم: 
 
 ```javascript
 this.setState((state, props) => {
@@ -526,23 +526,23 @@ this.setState((state, props) => {
 });
 ```
 
-Both `state` and `props` received by the updater function are guaranteed to be up-to-date. The output of the updater is shallowly merged with `state`.
+هر دو مقدار `state` و `props` دریافت شده در تابع updater ضمانت بروز بودن را دارند. خروجی updater به طور سطحی با `state` ترکیب می‌شود.
 
-The second parameter to `setState()` is an optional callback function that will be executed once `setState` is completed and the component is re-rendered. Generally we recommend using `componentDidUpdate()` for such logic instead.
+دومین پارامتر `setState()` یک تابع callback اختیاری است که یکبار زمانی که `setState` به طور کامل اجرا شده و کامپوننت دوباره رندر شده‌است، اجرا می‌شود. معمولا ما استفاده از `componentDidUpdate()` را برای چنین منطق‌هایی پیشنهاد می‌کنیم.
 
-You may optionally pass an object as the first argument to `setState()` instead of a function:
+شما ممکن است به شکل اختیاری یک آبجکت را به جای تابع به عنوان آرگومان اول `setState()` پاس دهید:
 
 ```javascript
 setState(stateChange[, callback])
 ```
 
-This performs a shallow merge of `stateChange` into the new state, e.g., to adjust a shopping cart item quantity:
+این یک ترکیب سطحی `stateChange` با state جدید را اجرا می‌کند. برای مثال، تنظیم مقدار آیتم‌های یک سبد خرید:
 
 ```javascript
 this.setState({quantity: 2})
 ```
 
-This form of `setState()` is also asynchronous, and multiple calls during the same cycle may be batched together. For example, if you attempt to increment an item quantity more than once in the same cycle, that will result in the equivalent of:
+این شکل `setState()` نیز asynchronous است و چندین فراخوانی در یک چرخه ممکن است باعث دسته‌بندی با یکدیگر شود. برای مثال، اگر اقدام به افزایش مقدار یک آیتم در یک چرحه یکسان بیش از یکبار کنید، نتیجه برابر خواهد بود با:
 
 ```javaScript
 Object.assign(
@@ -553,7 +553,7 @@ Object.assign(
 )
 ```
 
-Subsequent calls will override values from previous calls in the same cycle, so the quantity will only be incremented once. If the next state depends on the current state, we recommend using the updater function form, instead:
+فراخوانی‌های متوالی باعث بازنشانی مقدارها از صدازدن‌های قبلی در چرخه یکسان خواهد شد، بنابراین مقدار تنها یکبار افزایش پیدا خواهد کرد. اگر state بعدی وابسته به state فعلی است، ما استفاده از شکل تابعی updater به جای این روش را پیشنهاد می‌کنیم:
 
 ```js
 this.setState((state) => {
@@ -561,11 +561,11 @@ this.setState((state) => {
 });
 ```
 
-For more detail, see:
+برای اطلاعات بیشتر موارد زیر را ببینید:
 
-* [State and Lifecycle guide](/docs/state-and-lifecycle.html)
-* [In depth: When and why are `setState()` calls batched?](https://stackoverflow.com/a/48610973/458193)
-* [In depth: Why isn't `this.state` updated immediately?](https://github.com/facebook/react/issues/11527#issuecomment-360199710)
+* [راهنمای State و چرخه‌ی حیات](/docs/state-and-lifecycle.html)
+* [در اعماق: کی و چرا صدا زدن‌های `setState()` دسته‌بندی می‌شوند؟ ](https://stackoverflow.com/a/48610973/458193)
+* [در اعماق: چرا `this.state` فورا بروزرسانی نمی‌شود؟ ](https://github.com/facebook/react/issues/11527#issuecomment-360199710)
 
 * * *
 
@@ -575,19 +575,19 @@ For more detail, see:
 component.forceUpdate(callback)
 ```
 
-By default, when your component's state or props change, your component will re-render. If your `render()` method depends on some other data, you can tell React that the component needs re-rendering by calling `forceUpdate()`.
+به طور پیش‌فرض، زمانی که state یا props کامپوننتتان تغییر می‌کند، کامپوننت شما دوباره رندر خواهد شد. اگر متد `render()` شما وابسته به دیگر داده‌ها است، شما می‌توانید به وسیله `forceUpdate()` به ری‌اکت بگویید که کامپوننت نیاز به رندر دوباره دارد.
 
-Calling `forceUpdate()` will cause `render()` to be called on the component, skipping `shouldComponentUpdate()`. This will trigger the normal lifecycle methods for child components, including the `shouldComponentUpdate()` method of each child. React will still only update the DOM if the markup changes.
+صدازدن `forceUpdate()` باعث می‌شود `render()` کامپوننت، بدون توجه به نتیجه `shouldComponentUpdate()` صدا زده شود. اینکار باعث اجرای متدهای چرخه‌ی حیات عادی کامپوننت‌های فرزند، شامل متد `shouldComponentUpdate()` هر یک از فرزندان می‌‌شود. ری‌اکت همچنان فقط زمانی DOM را بروز می‌کند که نشانه گذاری تغییر کند.
 
-Normally you should try to avoid all uses of `forceUpdate()` and only read from `this.props` and `this.state` in `render()`.
+در حالت عادی باید تلاش کنید تا از تمامی استفاده‌های `forceUpdate()` خودداری نمایید و در `render()` فقط از `this.props` و `this.state` داده‌ها را بخوانید.
 
 * * *
 
-## Class Properties {#class-properties-1}
+## ویژگی‌های کلاس {#class-properties-1}
 
 ### `defaultProps` {#defaultprops}
 
-`defaultProps` can be defined as a property on the component class itself, to set the default props for the class. This is used for undefined props, but not for null props. For example:
+`defaultProps` می‌تواند به عنوان یک ویژگی خود کلاس کامپوننت، برای ست کردن props های پیش‌فرض کلاس تعریف شود. این برای props تعریف نشده استفاده می‌شود، اما نه برای props هایی که مقدار null دارند. برای مثال:
 
 ```js
 class CustomButton extends React.Component {
@@ -599,7 +599,7 @@ CustomButton.defaultProps = {
 };
 ```
 
-If `props.color` is not provided, it will be set by default to `'blue'`:
+اگر `props.color` فراهم نشده باشد، به طور پیش‌فرض با مقدار `'blue'` ست خواهد شد:
 
 ```js
   render() {
@@ -607,7 +607,7 @@ If `props.color` is not provided, it will be set by default to `'blue'`:
   }
 ```
 
-If `props.color` is set to null, it will remain null:
+اگر برای `props.color` مقدار null ست شده باشد، null باقی خواهد ماند:
 
 ```js
   render() {
@@ -619,24 +619,24 @@ If `props.color` is set to null, it will remain null:
 
 ### `displayName` {#displayname}
 
-The `displayName` string is used in debugging messages. Usually, you don't need to set it explicitly because it's inferred from the name of the function or class that defines the component. You might want to set it explicitly if you want to display a different name for debugging purposes or when you create a higher-order component, see [Wrap the Display Name for Easy Debugging](/docs/higher-order-components.html#convention-wrap-the-display-name-for-easy-debugging) for details.
+رشته متنی `displayName` در پیام‌های عیب‌یابی استفاده می‌شوند. معمولا، شما نیازی به ست کردن صریح آن ندارید چرا که نام آن از اسم تابع یا کلاسی که کامپوننت را تعریف می‌کند گرفته می‌شود. اگر برای اهداف عیب‌یابی و یا هنگام ایجاد یک کامپوننت مرتبه بالاتر می‌خواهید نام متفاوتی را نمایش دهید، می‌توانید خودتان نام جدیدی را صریحا برای آن ست کنید. [نام نمایش را برای عیب‌یابی آسان پوشش دهید](/docs/higher-order-components.html#convention-wrap-the-display-name-for-easy-debugging) را برای اطلاعات بیشتر ببینید.
 
 * * *
 
-## Instance Properties {#instance-properties-1}
+## ویژگی‌های Instance {#instance-properties-1}
 
 ### `props` {#props}
 
-`this.props` contains the props that were defined by the caller of this component. See [Components and Props](/docs/components-and-props.html) for an introduction to props.
+`this.props` شامل props هایی است که توسط صدازننده این کامپوننت تعریف شده‌اند. [کامپوننت و Props](/docs/components-and-props.html) را برای آشنایی بیشتر با props ببینید.
 
-In particular, `this.props.children` is a special prop, typically defined by the child tags in the JSX expression rather than in the tag itself.
+به خصوص، `this.props.children` یک prop مخصوص است و معمولا به جای خود تگ، در تگ‌های فرند و در قالب JSX تعریف می‌شوند.
 
 ### `state` {#state}
 
-The state contains data specific to this component that may change over time. The state is user-defined, and it should be a plain JavaScript object.
+state شامل داده‌های مشخص این کامپوننت است که ممکن است در طول زمان تغییر کند. state توسط کاربر تعریف می‌شود، و باید یک آبجکت ساده جاواساکریپتی باشد.
 
-If some value isn't used for rendering or data flow (for example, a timer ID), you don't have to put it in the state. Such values can be defined as fields on the component instance.
+اگر بعضی مقادیر برای رندر کردن و یا جریان داده استفاده نمی‌شوند (برای مثال یک timer ID)، شما مجبور نیستید در state قرار دهید. چنین مقادیری می‌توانند به عنوان زمینه روی instance کامپوننت تعریف شوند.
 
-See [State and Lifecycle](/docs/state-and-lifecycle.html) for more information about the state.
+[State و چرخه‌ی حیات](/docs/state-and-lifecycle.html) را برای اطلاعات بیشتر در مورد state ببینید.
 
-Never mutate `this.state` directly, as calling `setState()` afterwards may replace the mutation you made. Treat `this.state` as if it were immutable.
+هیچگاه `this.state` را مستقیما تغییر ندهید، چرا که صدا زدن `setState()` پس از آن ممکن است جایگزین تغییرات شما شود. با `this.state` طوری که تغییرناپذیر است رفتار کنید.

From faf1de4d3136c087786f0aa6a014be06afba7f20 Mon Sep 17 00:00:00 2001
From: Hossein Ahmadi <43136173+hosseinAMD@users.noreply.github.com>
Date: Mon, 6 Jul 2020 10:39:39 +0430
Subject: [PATCH 02/15] Update content/docs/reference-react-component.md

Co-authored-by: Soroush Torkzadeh <soroush.torkzadeh@gmail.com>
---
 content/docs/reference-react-component.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/docs/reference-react-component.md b/content/docs/reference-react-component.md
index b85b99fff..617d17914 100644
--- a/content/docs/reference-react-component.md
+++ b/content/docs/reference-react-component.md
@@ -15,7 +15,7 @@ redirect_from:
   - "tips/use-react-with-other-libraries.html"
 ---
 
-این صفحه حاوی جزئیات دقیق منابع API کلاس کامپوننت ری‌اکت می‌باشد. فرض شده است که شما با مفاهیم بنادین ری‌اکت مانند [کامپوننت ها و Props](/docs/components-and-props.html) و [State و چرخه حیات](/docs/state-and-lifecycle.html) آشنا هستید. در غیر‌اینصورت ابتدا آن‌ها را مطالعه نمایید.
+این صفحه شامل جزئیات دقیق منابع API ری‌اکت برای تعریف کامپوننت از جنس کلاس‌ است. فرض شده‌است که شما با مفاهیم بنادین ری‌اکت مانند [کامپوننت‌ها و Props](/docs/components-and-props.html) و [State و چرخه حیات](/docs/state-and-lifecycle.html) آشنا هستید. در غیر‌این‌صورت ابتدا آن‌ها را مطالعه نمایید.
 
 ## بررسی اجمالی {#overview}
 

From df8a84e2554b5268753e894e8fdc0b76b3df8d1f Mon Sep 17 00:00:00 2001
From: Hossein Ahmadi <43136173+hosseinAMD@users.noreply.github.com>
Date: Mon, 6 Jul 2020 10:39:47 +0430
Subject: [PATCH 03/15] Update content/docs/reference-react-component.md

Co-authored-by: Soroush Torkzadeh <soroush.torkzadeh@gmail.com>
---
 content/docs/reference-react-component.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/docs/reference-react-component.md b/content/docs/reference-react-component.md
index 617d17914..3041ca482 100644
--- a/content/docs/reference-react-component.md
+++ b/content/docs/reference-react-component.md
@@ -19,7 +19,7 @@ redirect_from:
 
 ## بررسی اجمالی {#overview}
 
-ری‌اکت به شما اجازه می‌دهد تا کامپوننت‌ها را به عنوان کلاس یا تابع تعریف کنید. کامپوننت‌هایی که به عنوان کلاس تعریف می‌شوندُ در حال حاضر امکانات بیشتری را فراهم می‌کنند که در این صفحه با جزئیات کامل تشریح شده است. برای تعریف یک کلاس کامپوننت ری‌اکتُ شما به گسترش `React.Component` نیاز دارید:
+ری‌اکت به شما اجازه می‌دهد تا کامپوننت‌ها را به عنوان کلاس یا تابع تعریف کنید. کامپوننت‌هایی که به عنوان کلاس تعریف می‌شوند در حال حاضر امکانات بیشتری را فراهم می‌کنند که در این صفحه با جزئیات کامل تشریح شده‌است. برای تعریف یک کلاس کامپوننت ری‌اکت شما به گسترش `React.Component` نیاز دارید:
 
 ```js
 class Welcome extends React.Component {

From d908d4fe7e6fff973c97706abd9d65d6929ad593 Mon Sep 17 00:00:00 2001
From: Hossein Ahmadi <43136173+hosseinAMD@users.noreply.github.com>
Date: Mon, 6 Jul 2020 10:40:06 +0430
Subject: [PATCH 04/15] Update content/docs/reference-react-component.md

Co-authored-by: Soroush Torkzadeh <soroush.torkzadeh@gmail.com>
---
 content/docs/reference-react-component.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/docs/reference-react-component.md b/content/docs/reference-react-component.md
index 3041ca482..59be53472 100644
--- a/content/docs/reference-react-component.md
+++ b/content/docs/reference-react-component.md
@@ -31,7 +31,7 @@ class Welcome extends React.Component {
 
 تنها متدی که شما *باید* در یک زیرکلاس `React.Component` تعریف کنید، [`render()`](#render) نام دارد. تمامی متدهای دیگر تشریح شده در این صفحه، اختیاری هستند.
 
-**ما به شدت مخالف ایجاد کلاس‌های کامپونت مادر خودتان هستیم**. در کاپوننت‌های ری‌اکت، [استفاده مجدد از کد بیشتر از طریق ترکیب قابل دستیابی است تا وراثت](/docs/composition-vs-inheritance.html).
+**ما به شدت مخالف این هستیم که شما برای خودتان کلاس‌های کامپونت مادر ایجاد کنید**. در کاپوننت‌های ری‌اکت، [استفاده مجدد از کد بیشتر از طریق ترکیب قابل دستیابی است تا وراثت](/docs/composition-vs-inheritance.html).
 
 >نکته:
 >

From 3d61de22c4e0fc5904ed891871cd27a5afe32572 Mon Sep 17 00:00:00 2001
From: Hossein Ahmadi <43136173+hosseinAMD@users.noreply.github.com>
Date: Mon, 6 Jul 2020 10:40:24 +0430
Subject: [PATCH 05/15] Update content/docs/reference-react-component.md

Co-authored-by: Soroush Torkzadeh <soroush.torkzadeh@gmail.com>
---
 content/docs/reference-react-component.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/docs/reference-react-component.md b/content/docs/reference-react-component.md
index 59be53472..05e06683d 100644
--- a/content/docs/reference-react-component.md
+++ b/content/docs/reference-react-component.md
@@ -41,7 +41,7 @@ class Welcome extends React.Component {
 
 هر کامپوننت چندین "متد چرخه‌ی حیات" دارد که شما می‌توانید بازنویسی کنید تا در زمان‌های خاص فرآیند اجرا، کد شما اجرا شود. **شما می‌توانید از [این دیاگرام چرخه‌حیات](http://projects.wojtekmaj.pl/react-lifecycle-methods-diagram/) به عنوان راهنما استفاده کنید.** در لیست زیر، متدهای چرخه‌ی حیات رایج به صورت **برجسته** نشانه‌گذاری شده‌اند. باقی آن‌ها برای موارد نادر استفاده وجود دارند.
 
-#### اجرای اولیه {#mounting}
+#### اجرای اولیه (Mounting) {#mounting}
 
 این متدها به ترتیب زیر هنگام ایجاد یک نمونه از کامپوننت و درج آن در DOM صدا زده می‌شوند:
 

From 8fabc4ef85c4f071121f7e77a40908ab9f32580c Mon Sep 17 00:00:00 2001
From: Hossein Ahmadi <43136173+hosseinAMD@users.noreply.github.com>
Date: Mon, 6 Jul 2020 10:40:34 +0430
Subject: [PATCH 06/15] Update content/docs/reference-react-component.md

Co-authored-by: Soroush Torkzadeh <soroush.torkzadeh@gmail.com>
---
 content/docs/reference-react-component.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/docs/reference-react-component.md b/content/docs/reference-react-component.md
index 05e06683d..a4b281950 100644
--- a/content/docs/reference-react-component.md
+++ b/content/docs/reference-react-component.md
@@ -73,7 +73,7 @@ class Welcome extends React.Component {
 >- [`UNSAFE_componentWillUpdate()`](#unsafe_componentwillupdate)
 >- [`UNSAFE_componentWillReceiveProps()`](#unsafe_componentwillreceiveprops)
 
-#### نابود شدن {#unmounting}
+#### نابود شدن (Unmounting) {#unmounting}
 
 این متدها هنگامی که یک کامپوننت از DOM پاک می‌شود صدا زده می‌شوند:
 

From d0d9ee49823f7370c56606c547dde919f199ea92 Mon Sep 17 00:00:00 2001
From: Hossein Ahmadi <43136173+hosseinAMD@users.noreply.github.com>
Date: Mon, 6 Jul 2020 10:41:15 +0430
Subject: [PATCH 07/15] Update content/docs/reference-react-component.md

Co-authored-by: Soroush Torkzadeh <soroush.torkzadeh@gmail.com>
---
 content/docs/reference-react-component.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/docs/reference-react-component.md b/content/docs/reference-react-component.md
index a4b281950..9852e6b4d 100644
--- a/content/docs/reference-react-component.md
+++ b/content/docs/reference-react-component.md
@@ -133,7 +133,7 @@ render()
 
 > نکته:
 >
-> در صورتی که [`shouldComponentUpdate()`](#shouldcomponentupdate)، false بازگرداند، `render()` فراخوانی نمی‌شود.
+> تابع `render()` فراخوانی نخواهد شد، اگر [`shouldComponentUpdate()`](#shouldcomponentupdate) مقدار false را بازگرداند.```
 
 * * *
 

From f2cf922c020d540331457754acf43dbde88f6d61 Mon Sep 17 00:00:00 2001
From: Hossein Ahmadi <43136173+hosseinAMD@users.noreply.github.com>
Date: Mon, 6 Jul 2020 10:41:46 +0430
Subject: [PATCH 08/15] Update content/docs/reference-react-component.md

Co-authored-by: Soroush Torkzadeh <soroush.torkzadeh@gmail.com>
---
 content/docs/reference-react-component.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/docs/reference-react-component.md b/content/docs/reference-react-component.md
index 9852e6b4d..a921a4663 100644
--- a/content/docs/reference-react-component.md
+++ b/content/docs/reference-react-component.md
@@ -129,7 +129,7 @@ render()
 
 تابع `render()` باید خالص باشد، به این معنی که نباید state را تغییر دهد، هر بار که فراخوانی می‌شود نتیجه یکسان بازمی‌گرداند و به صورت مستقیم با مرورگر تعاملی ندارد.
 
-اگر به تعامل با مرورگر نیاز دارید، عملیاتتان را در `componentDidMount()` یا دیگر متدهای چرخه‌ی حیات انجام دهید. خالص نگه داشتن `render()` فکر کردن به کامپوننت‌ها را آسان‌تر می‌کند.
+اگر به تعامل با مرورگر نیاز دارید، عملیات خود را در `componentDidMount()` یا دیگر متدهای چرخه‌ی حیات انجام دهید. خالص نگه داشتن `render()` فکر کردن به کامپوننت‌ها را آسان‌تر می‌کند.
 
 > نکته:
 >

From 806f3333332839a27c1a94d77aadfc09f6dd9a61 Mon Sep 17 00:00:00 2001
From: Hossein Ahmadi <43136173+hosseinAMD@users.noreply.github.com>
Date: Mon, 6 Jul 2020 10:42:28 +0430
Subject: [PATCH 09/15] Update content/docs/reference-react-component.md

Co-authored-by: Soroush Torkzadeh <soroush.torkzadeh@gmail.com>
---
 content/docs/reference-react-component.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/docs/reference-react-component.md b/content/docs/reference-react-component.md
index a921a4663..cce8b6a12 100644
--- a/content/docs/reference-react-component.md
+++ b/content/docs/reference-react-component.md
@@ -165,7 +165,7 @@ constructor(props) {
 
 سازنده تنها جایی‌است که باید `this.state` را مسقیما برابر مقداری قرار دهید. در دیگر متدها، نیاز دارید تا از `this.setState()` استفاده کنید.
 
-از معرفی هرگونه تاثیر جانبی و یا ثبت اشتراک در سازنده خودداری نمایید. برای چنین موارد، از `componentDidMount()` استفاده کنید.
+از معرفی هرگونه تاثیر جانبی (side-effect) و یا ثبت اشتراک (subscription) در سازنده خودداری نمایید. برای چنین موارد، از `componentDidMount()` استفاده کنید.
 
 >نکته:
 >

From 2036186f0c2a7cc904fe0fc2d5ebc9f44c72dd1e Mon Sep 17 00:00:00 2001
From: Hossein Ahmadi <43136173+hosseinAMD@users.noreply.github.com>
Date: Mon, 6 Jul 2020 10:45:07 +0430
Subject: [PATCH 10/15] Update content/docs/reference-react-component.md

Co-authored-by: Soroush Torkzadeh <soroush.torkzadeh@gmail.com>
---
 content/docs/reference-react-component.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/docs/reference-react-component.md b/content/docs/reference-react-component.md
index cce8b6a12..6976675ef 100644
--- a/content/docs/reference-react-component.md
+++ b/content/docs/reference-react-component.md
@@ -58,7 +58,7 @@ class Welcome extends React.Component {
 
 #### بروزرسانی {#updating}
 
-یک بروزرسانی می‌تواند به وسیله تغییر دادن state یا props رخ دهد. این متدها هنگامی که یک کامپوننت دوباره رندر می‌شود به ترتیب زیر صدا زده می‌شوند:
+یک به‌روز رسانی می‌تواند به وسیله تغییر دادن state یا props رخ دهد. این متدها هنگامی که یک کامپوننت دوباره رندر می‌شود به ترتیب زیر صدا زده می‌شوند:
 
 - [`static getDerivedStateFromProps()`](#static-getderivedstatefromprops)
 - [`shouldComponentUpdate()`](#shouldcomponentupdate)

From 832feab9cfd40ff3a7716420773a50a997ac5de3 Mon Sep 17 00:00:00 2001
From: Hossein Ahmadi <43136173+hosseinAMD@users.noreply.github.com>
Date: Mon, 6 Jul 2020 10:45:44 +0430
Subject: [PATCH 11/15] Update content/docs/reference-react-component.md

Co-authored-by: Soroush Torkzadeh <soroush.torkzadeh@gmail.com>
---
 content/docs/reference-react-component.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/docs/reference-react-component.md b/content/docs/reference-react-component.md
index 6976675ef..33081bd0a 100644
--- a/content/docs/reference-react-component.md
+++ b/content/docs/reference-react-component.md
@@ -56,7 +56,7 @@ class Welcome extends React.Component {
 >
 >- [`UNSAFE_componentWillMount()`](#unsafe_componentwillmount)
 
-#### بروزرسانی {#updating}
+#### به‌روز رسانی {#updating}
 
 یک به‌روز رسانی می‌تواند به وسیله تغییر دادن state یا props رخ دهد. این متدها هنگامی که یک کامپوننت دوباره رندر می‌شود به ترتیب زیر صدا زده می‌شوند:
 

From 3fc672ae35120ab8dfdebadb2208245fd0ac6d43 Mon Sep 17 00:00:00 2001
From: Hossein Ahmadi <43136173+hosseinAMD@users.noreply.github.com>
Date: Mon, 6 Jul 2020 10:55:32 +0430
Subject: [PATCH 12/15] Apply suggestions from code review

Co-authored-by: Soroush Torkzadeh <soroush.torkzadeh@gmail.com>
---
 content/docs/reference-react-component.md | 88 +++++++++++------------
 1 file changed, 44 insertions(+), 44 deletions(-)

diff --git a/content/docs/reference-react-component.md b/content/docs/reference-react-component.md
index 33081bd0a..8401b33d7 100644
--- a/content/docs/reference-react-component.md
+++ b/content/docs/reference-react-component.md
@@ -179,9 +179,9 @@ constructor(props) {
 >}
 >```
 >
->مشکل اینجاست که هردو کار غیرضروری است (شما می‌توانید مستقیما از `this.props.color` استفاده کنید )، و باگ ایجاد می‌کند (بروزرسانی‌های `color` در prop تاثیری بر روی state نمی‌گذارد).
+>مشکل اینجاست که هردو کار غیرضروری است (شما می‌توانید مستقیما از `this.props.color` استفاده کنید )، و باگ ایجاد می‌کند (به‌روز رسانی‌های `color` در prop تاثیری بر روی state نمی‌گذارد).
 >
->**تنها در صورتی که می‌خواهید عمدا بروزرسانی‌های prop را نادیده بگیرید از این الگو استفاده کنید.** در این صورت، منطقی است که prop را تغییر نام دهید که `initialColor` یا `defaultColor` صدا زده شود. در مواقع لزوم، می‌توانید یک کامپوننت را به وسیله [تغییر `key`](/blog/2018/06/07/you-probably-dont-need-derived-state.html#recommendation-fully-uncontrolled-component-with-a-key) به "reset" کردن state داخلی‌اش مجبور کنید.
+>**تنها در صورتی که می‌خواهید عمدا به‌روز رسانی‌های prop را نادیده بگیرید از این الگو استفاده کنید.** در این صورت، منطقی است که prop را تغییر نام دهید که `initialColor` یا `defaultColor` صدا زده شود. در مواقع لزوم، می‌توانید یک کامپوننت را به وسیله [تغییر `key`](/blog/2018/06/07/you-probably-dont-need-derived-state.html#recommendation-fully-uncontrolled-component-with-a-key) به "reset" کردن state داخلی‌اش مجبور کنید.
 >
 >[پست وبلاگ مربوط به خودداری از state مشتق شده](/blog/2018/06/07/you-probably-dont-need-derived-state.html) را بخوانید تا در صورتی که فکر می‌کنید نیاز به وابستگی بعضی state ها به props دارید، چگونگی انجام دادن آن را یاد بگیرید.
 
@@ -196,9 +196,9 @@ componentDidMount()
 
 `componentDidMount()` فورا پس از اجرا و نصب اولیه‌ی یک کامپوننت (زمانی که در درخت درج می‌شود) صدا زده می‌شود. مقداردهی اولیه‌ای که نودهای DOM نیاز دارند باید اینجا باشد. در صورتی که نیاز دارید که از یک endpoint راه دور داده دریافت کنید، اینجا محل خوبی برای پیاده‌سازی درخواست‌‌های شبکه است.
 
-این متد مکان خوبی برای تنظیم کردن هرگونه اشتراکی می‌باشد. اگر اینکار را انجام دهید، لغو اشتراک در `componentWillUnmount()` فراموش نکنید.
+این متد مکان خوبی برای تنظیم کردن هرگونه اشتراک است. اگر این‌کار را انجام می‌دهید، لغو اشتراک در `componentWillUnmount()` فراموش نکنید.
 
-شما **ممکن است `setState()` را فورا** در `componentDidMount()` **صدا بزنید.** این باعث یک رندر اضافی می‌شود، اما قبل از اینکه مرورگر صفحه را بروز کند اتفاق می‌افتد و تضمین می‌کند که حتی با وجود اینکه `render()` در این مورد دو بار صدا زده خواهد شد، کاربر state واسطی را نخواهد دید. از این الگو با‌احتیاط استفاده کنید چرا که اغلب موارد باعث مشکلات پرفورمنس و بهره‌وری خواهد شد. در عوض در اکثر موارد، شما باید بتوانید state اولیه را در `constructor()` مقداردهی کنید. به هر حال اینکار می‌تواند برای مواردی مانند modal ها و یا tooltip ها، زمانی که شما نیاز به بررسی یک نود DOM قبل از رندر شدن چیزی که وابسته به ابعاد و مکانش است دارید، ضروری می‌باشد.
+شما **ممکن است `setState()` را فورا** در `componentDidMount()` **صدا بزنید.** این باعث یک رندر اضافی می‌شود، اما قبل از اینکه مرورگر صفحه را بروز کند اتفاق می‌افتد و تضمین می‌کند که حتی با وجود اینکه `render()` در این مورد دو بار صدا زده خواهد شد، کاربر state واسطی را نخواهد دید. از این الگو با‌احتیاط استفاده کنید چرا که اغلب موارد باعث مشکلات کارایی خواهد شد. در عوض در اکثر موارد، شما باید بتوانید state اولیه را در `constructor()` مقداردهی کنید. به هر حال این‌کار می‌تواند برای مواردی مانند modal ها و یا tooltip ها، زمانی که شما نیاز به بررسی یک نود DOM قبل از رندر شدن چیزی که وابسته به ابعاد و مکانش است دارید، ضروری باشد.
 
 * * *
 
@@ -208,9 +208,9 @@ componentDidMount()
 componentDidUpdate(prevProps, prevState, snapshot)
 ```
 
-`componentDidUpdate()` بلافاصله پس از رخ دادن هر بروزرسانی صدا زده می‌شود. این متد برای رندر اولیه صدا زده نمی‌شود.
+`componentDidUpdate()` بلافاصله پس از رخ دادن هر به‌روز رسانی صدا زده می‌شود. این متد برای رندر اولیه صدا زده نمی‌شود.
 
-از این فرصت برای انجام عملیات بر روی DOM در زمانی که کامپوننت بروز شده‌است استفاده کنید. همچنین مکان مناسبی برای انجام درخواست‌های شبکه،  مادامی که props فعلی را با props قبلی مقایسه می‌کنید می‌باشد (برای مثال درخواست شبکه در صورتی که props تغییری نکرده است ضروری نیست ).
+از این فرصت برای انجام عملیات بر روی DOM در زمانی که کامپوننت بروز شده‌است استفاده کنید. همچنین مکان مناسبی برای انجام درخواست‌های شبکه،  مادامی که props فعلی را با props قبلی مقایسه می‌کنید می‌باشد (برای مثال درخواست شبکه در صورتی که props تغییری نکرده است ضروری نیست).
 
 ```js
 componentDidUpdate(prevProps) {
@@ -221,13 +221,13 @@ componentDidUpdate(prevProps) {
 }
 ```
 
-شما ممکن است **`setState()` را فورا** در `componentDidUpdate()` **صدا بزنید** اما در نظر داشته باشید که مانند مثال بالا **باید در یک شرط قرار داشته باشد.** در غیر اینصورت شما در یک حلقه‌ی بی‌نهایت گرفتار خواهید شد. همچنین باعث رندر اضافی می‌شود که گرچه برای کاربر قابل مشاهده نیست، می‌تواند بر روی پرفورمنس و بهره‌وری کامپوننت تاثیر گذارد. اگر تلاش می‌کنید تا بعضی state ها را به یک prop که از بالا می‌آید "mirror" کنید، استفاده مستقیم از prop را به عنوان جایگزین در نظر بگیرید. در مورد [چرا کپی کردن props در state باعث باگ می‌شود؟](/blog/2018/06/07/you-probably-dont-need-derived-state.html) بخوانید.
+شما ممکن است **`setState()` را فورا** در `componentDidUpdate()` **صدا بزنید** اما در نظر داشته باشید که مانند مثال بالا **باید در یک شرط قرار داشته باشد.** در غیر اینصورت شما در یک حلقه‌ی بی‌نهایت گرفتار خواهید شد. همچنین باعث رندر اضافی می‌شود که گرچه برای کاربر قابل مشاهده نیست، می‌تواند بر روی کارایی کامپوننت تاثیر گذارد. اگر تلاش می‌کنید تا بعضی state ها را به یک prop که از بالا می‌آید "mirror" کنید، استفاده مستقیم از prop را به عنوان جایگزین در نظر بگیرید. در مورد [چرا کپی کردن props در state باعث باگ می‌شود؟](/blog/2018/06/07/you-probably-dont-need-derived-state.html) بخوانید.
 
 اگر کامپوننت شما چرخه‌ی حیات `getSnapshotBeforeUpdate()` را پیاده‌سازی می‌کند (که نادر است)، مقداری که برمی‌گرداند به عنوان پارامتر سوم "snapshot" به `componentDidUpdate()` پاس داده می‌شود. در غیر اینصورت این پارامتر undefined خواهد بود.
 
 > نکته
 >
-> اگر [`shouldComponentUpdate()`](#shouldcomponentupdate)، false بازگرداند، `componentDidUpdate()` اجرا نخواهد شد.
+> اگر [`shouldComponentUpdate()`](#shouldcomponentupdate) مقدار false بازگرداند، `componentDidUpdate()` اجرا نخواهد شد.
 
 * * *
 
@@ -237,7 +237,7 @@ componentDidUpdate(prevProps) {
 componentWillUnmount()
 ```
 
-`componentWillUnmount()` بلافاصله قبل از اینکه یک کامپوننت نابود شود صدا زده می‌شود. هر گونه پاکسازی ضروری مانند غیرفعالسازی تایمرها، کنسل کردن درخواست‌های شبکه و یا لغو اشتراک‌های ایجاد شده در `componentDidMount()`، در این متد انجام می‌پذیرد.
+`componentWillUnmount()` بلافاصله قبل از اینکه یک کامپوننت نابود شود صدا زده می‌شود. هر گونه پاکسازی ضروری مانند غیرفعالسازی تایمرها، لغو درخواست‌های شبکه و یا لغو اشتراک‌های ایجاد شده در `componentDidMount()`، در این متد انجام می‌پذیرد.
 
 در `componentWillUnmount()` **نباید `setState()` را صدا بزنید** چرا که کامپوننت هیچگاه دوباره رندر نخواهد شد. به محض اینکه یک instance کامپوننت نابود می‌شود، هرگز دوباره نصب و اجرا نخواهد شد.
 
@@ -254,15 +254,15 @@ componentWillUnmount()
 shouldComponentUpdate(nextProps, nextState)
 ```
 
-از `shouldComponentUpdate()` استفاده کنید تا به ری‌اکت اجازه دهید تا در صورتی که خروجی کامپوننت توسط تغییر کنونی در state یا props متاثر نشده است بداند. رفتار پیش‌فرض این متد، رندر دوباره به ازای هر تغییر در state است، که در اکثریت قریب به اتفاق موارد شما باید به رفتار پیش‌فرض آن اعتماد کنید.
+با استفاده از `shouldComponentUpdate()` به ری‌اکت می‌فهمانید که خروجی کامپوننت متاثر از تغییر کنونی در state یا props نیست. رفتار پیش‌فرض این متد، رندر دوباره به ازای هر تغییر در state است، که در اکثریت قریب به اتفاق موارد شما باید به رفتار پیش‌فرض آن اعتماد کنید.
 
 `shouldComponentUpdate()` قبل از رندر شدن در هنگام دریافت state یا props جدید صدا زده می‌شود. به طور پیش‌فرض مقدار `true` برمی‌گرداند. این متد هنگام رندر اولیه یا زمانی که `forceUpdate()` استفاده می‌شود صدا زده نمی‌شود.
 
-این متد تنها به عنوان یک **[بهینه‌سازی پرفورمنس و بهره‌وری](/docs/optimizing-performance.html)** وجود دارد. برای جلوگیری از یک رندر از آن استفاده نکنید چرا که باعث بروز باگ‌ها می‌شود. استفاده از **[`PureComponent`](/docs/react-api.html#reactpurecomponent) داخلی** را به جای نوشتن دستی `shouldComponentUpdate()` **در نظر بگیرید.** `PureComponent` یک مقایسه سطحی میان props و state انجام می‌دهد و شانس اینکه شما یک بروزرسانی ضروری را رد کنی کاهش می‌دهد.
+این متد تنها به عنوان یک **[بهینه‌سازی کارایی](/docs/optimizing-performance.html)** وجود دارد. برای جلوگیری از یک رندر از آن استفاده نکنید چرا که باعث بروز باگ‌ها می‌شود. استفاده از **[`PureComponent`](/docs/react-api.html#reactpurecomponent) داخلی** را به جای نوشتن دستی `shouldComponentUpdate()` **در نظر بگیرید.** `PureComponent` یک مقایسه سطحی میان props و state انجام می‌دهد و شانس اینکه شما یک بروزرسانی ضروری را رد کنی کاهش می‌دهد.
 
-اگر شما از نوشتن دستی آن مطمئن هستید، شما ممکن است `this.props` را با `nextProps` و `this.state` را با `nextState` مقایسه کنید و در صورتی که بروزرسانی می‌تواند رد شود با بازگرداندن `false` این مورد را به ری‌اکت اطلاع دهید. توجه داشته باشید که بازگرداندن `false`، کامپوننت‌‌های فرزند را در هنگام تغییرات state *آن‌ها*، از رندر شدن دوباره منع نمی‌کند.
+اگر شما از نوشتن دستی آن مطمئن هستید، شما ممکن است `this.props` را با `nextProps` و `this.state` را با `nextState` مقایسه کنید و در صورتی که به‌روز رسانی می‌تواند رد شود با بازگرداندن `false` این مورد را به ری‌اکت اطلاع دهید. توجه داشته باشید که بازگرداندن `false`، کامپوننت‌‌های فرزند را در هنگام تغییرات state *آن‌ها*، از رندر شدن دوباره منع نمی‌کند.
 
-ما بررسی برابری‌های عمیق یا استفاده از `JSON.stringify()` را در `shouldComponentUpdate()` پیشنهاد نمی‌کنیم چرا که بسیار ناکارآمد است و به پرفورمنس ضربه می‌زند.
+ما استفاده از بررسی‌های برابری‌ عمیق (deep equality checks) یا `JSON.stringify()` را در `shouldComponentUpdate()` پیشنهاد نمی‌کنیم چرا که بسیار ناکارآمد است و به کارایی ضربه می‌زند.
 
 در حال حاضر، اگر `shouldComponentUpdate()`، مقدار `false` بازگرداند، [`UNSAFE_componentWillUpdate()`](#unsafe_componentwillupdate)، [`render()`](#render) و [`componentDidUpdate()`](#componentdidupdate) صدا زده نخواهند شد. در آینده ممکن است ری‌اکت با `shouldComponentUpdate()` به جای یک بخشنامه سختگیرانه، مانند یک راهنمایی رفتار کند و امکان دوباره رندر شدن کامپوننت در صورت بازگرداندن `false` همچنان موجود باشد.
 
@@ -274,7 +274,7 @@ shouldComponentUpdate(nextProps, nextState)
 static getDerivedStateFromProps(props, state)
 ```
 
-`getDerivedStateFromProps` درست بعد از فراخوانی متد رندر، در هر دو حالت نصب و اجرای اولیه و بروزرسانی‌های بعد از آن صدا زده می‌شود. این متد باید یک آبجکت برای بروزرسانی state، و یا null برای عدم بروزرسانی بازگرداند.
+`getDerivedStateFromProps` درست بعد از فراخوانی متد رندر، در هر دو حالت نصب و اجرای اولیه و به‌روز رسانی‌های بعد از آن صدا زده می‌شود. این متد باید یک آبجکت برای به‌روز رسانی state، و یا null برای عدم به‌روز رسانی بازگرداند.
 
 این متد برای [موارد استفاده نادر](/blog/2018/06/07/you-probably-dont-need-derived-state.html#when-to-use-derived-state) که state وابسته به تغییرات props در طول زمان است وجود دارد. برای مثال، ممکن است برای پیاده‌سازی یک کامپوننت `<Transition>` که فرزند قبلی و بعدی خود را برای تصمیم‌گیری اینکه برای کدام‌یک انیمیشن ورود و برای کدام‌یک انیمیشن خروج را اعمال کند مقایسه می‌کند، کاربردی باشد.
 
@@ -285,11 +285,11 @@ static getDerivedStateFromProps(props, state)
 
 * اگر می‌خواهید **بعضی داده‌ها را فقط زمان تغییرات یک props محاسبه کنید**، [از یک memoization به عنوان جایگزین استفاده کنید](/blog/2018/06/07/you-probably-dont-need-derived-state.html#what-about-memoization).
 
-* اگر میخواهید **بعضی state ها را زمان تغییرات یک prop "reset" کنید**، ساخت یک کامپوننت [کاملا کنترل شده](/blog/2018/06/07/you-probably-dont-need-derived-state.html#recommendation-fully-controlled-component) یا [کاملا کنترل نشده با یک `key`](/blog/2018/06/07/you-probably-dont-need-derived-state.html#recommendation-fully-uncontrolled-component-with-a-key) را به عنوان جایگزین در نظر بگیرید.
+* اگر می‌خواهید **بعضی state ها را زمان تغییرات یک prop "بازنشانی (reset)" کنید**، ساخت یک کامپوننت [کاملا کنترل شده](/blog/2018/06/07/you-probably-dont-need-derived-state.html#recommendation-fully-controlled-component) یا [کاملا کنترل نشده با یک `key`](/blog/2018/06/07/you-probably-dont-need-derived-state.html#recommendation-fully-uncontrolled-component-with-a-key) را به عنوان جایگزین در نظر بگیرید.
 
 این متد به instance کامپوننت دسترسی ندارد. اگر مایل هستید، می‌توانید از بعضی کدها میان `getDerivedStateFromProps()` و دیگر متدهای کلاس برای استخراج توابع خالص props کامپوننت و state، خارج از تعریف کلاس دوباره استفاده کنید.
 
-در نظر داشته باشید این متد بدون در نظر گرفتن دلیل، با *هر* رندر اجرا می‌شود. بنابراین با `UNSAFE_componentWillReceiveProps`، که تنها زمانی که والد باعث یک رندر دوباره است و در نتیجه یک `setState` محلی نیست، در تضاد است.
+در نظر داشته باشید این متد بدون در نظر گرفتن دلیل، با *هر* رندر اجرا می‌شود. بنابراین با `UNSAFE_componentWillReceiveProps` که در آن، نه اجرای یک `setState` محلی، بلکه والد باعث یک رندر دوباره می‌شود، در تضاد است.
 
 * * *
 
@@ -301,9 +301,9 @@ getSnapshotBeforeUpdate(prevProps, prevState)
 
 `getSnapshotBeforeUpdate()` درست قبل از آخرین خروجی رندر شده‌ای که به DOM سپرده شده‌است صدا زده می‌شود و کامپوننت شما را توانا می‌سازد تا بعضی اطلاعات را (مانند اسکرول کردن مکان صفحه) قبل از اینکه بالقوه تغییر کند از DOM بگیرد. هر مقداری که توسط ین چرخه‌ی حیات بازگردد به عنوان یک پارامتر به `componentDidUpdate()` پاس داده خواهد شد.
 
-این مورد استفاده رایج نیست، اما ممکن است در UI هایی مانند صفحه‌ی چت که کنترل مکان اسکرول به شکلی خاص نیاز است، رخ دهد.
+این مورد استفاده رایج نیست، اما ممکن است در رابط‌کاربری‌هایی مانند صفحه‌ی چت که کنترل مکان اسکرول به شکلی خاص نیاز است، رخ دهد.
 
-یک مثدار snapshot (یا `null`) باید بازگردانده شود.
+یک مقدار از snapshot (یا `null`) باید بازگردانده شود.
 
 برای مثال:
 
@@ -313,19 +313,19 @@ getSnapshotBeforeUpdate(prevProps, prevState)
 
 * * *
 
-### Error boundaries {#error-boundaries}
+### مرزهای خطا (error boundaries) {#error-boundaries}
 
 [Error boundaries](/docs/error-boundaries.html) کامپوننت‌های ری‌اکت هستند که خطاهای جاوااسکریپت را هر جایی در درخت کامپوننت‌های فرزندشان می‌گیرند، آن ارورها را در کنسول در قالب لاگ نشان می‌دهند و یک UI به جای درخت کامپوننتی که کرش کرده است نمایش می‌دهد. Error boundaries خطاها را هنگام رندر شدن، در متدهای چرخه‌ی حیات و در سازنده‌های تمام درخت زیر آن‌ها می‌گیرند.
 
-یک کلاس کامپوننت در صورتی که هر یک از متدهای چرخه‌ی حیات `static getDerivedStateFromError()` یا `componentDidCatch()` یا هردو تعریف شده باشند یک error boundary می‌شود. بروزرسانی state از این متدهای چرخه‌ی حیات به شما اجازه می‌دهد تا خطاهای کنترل نشده‌ی جاوااسکریپتی در درخت زیر آن را بگیرید و یک UI مناسب نمایش دهید.
+یک کامپوننت از جنس کلاس در صورتی که هر یک از متدهای چرخه‌ی حیات `static getDerivedStateFromError()`، `componentDidCatch()` یا هردوی آن‌ها را پیاده‌سازی کند، یک مرز خطا می‌شود. به‌روز رسانی state از این متدهای چرخه‌ی حیات به شما اجازه می‌دهد تا خطاهای کنترل نشده‌ی جاوااسکریپتی در درخت زیر آن را بگیرید و یک رابط کاربری مناسب نمایش دهید.
 
-فقط برای بازیابی از خطاهای غیرقابل انتظار از error boundaries استفاده کنید; **برای کنترل جریان از آن‌ها استفاده نکنید.**
+از مرزهای خطا تنها برای بازیابی از خطاهای غیرقابل پیش‌بینی استفاده کنید، **برای کنترل جریان از آن‌ها استفاده نکنید.**
 
-برای اطلاعات بیشتر، [*کنترل خطاها در ری‌اکت 16*](/blog/2017/07/26/error-handling-in-react-16.html) را ببینید.
+برای اطلاعات بیشتر، [*کنترل خطاها در ری‌اکت ۱۶*](/blog/2017/07/26/error-handling-in-react-16.html) را ببینید.
 
 > نکته
 > 
-> Error boundaries تنها خطاهای کامپوننت‌های **زیر** خودشان در درخت را می‌گیرند. یک error boundary نمی‌تواند خطای درون خودش را بگیرد.
+> مرزهای خطا تنها می‌توانند خطاهای کامپوننت‌های درخت **زیر** خودشان را بگیرند. یک مرز خطا نمی‌تواند خطای درون خودش را بگیرد.
 
 ### `static getDerivedStateFromError()` {#static-getderivedstatefromerror}
 ```javascript
@@ -333,7 +333,7 @@ static getDerivedStateFromError(error)
 ```
 
 این چرخه‌ی حیات بعد از اینکه یک خطا توسط کامپوننت‌های زاده اولادش رخ داد صدا زده می‌شود.
-خطایی که رخ داده است را به عنوان یک پارامتر دریافت می‌کند و باید یک مثدار برای بروزرسانی state بازگرداند.
+خطایی که رخ داده است را به عنوان یک پارامتر دریافت می‌کند و باید یک مقدار برای به‌روز رسانی state بازگرداند.
 
 ```js{7-10,13-16}
 class ErrorBoundary extends React.Component {
@@ -378,7 +378,7 @@ componentDidCatch(error, info)
 2. `info` - یک آبجت با کلید `componentStack` شامل [اطلاعات در مورد اینکه در کدام کامپوننت خطا رخ داده است](/docs/error-boundaries.html#component-stack-traces).
 
 `componentDidCatch()` در فاز "commit" صدا زده می‌شود، بنابراین تاثیرات جانبی مجاز هستند.
-باید برای چیزهایی مانند لاگ انداختن خطاها استفاده شود:
+باید برای چیزهایی مانند لاگ کردن خطاها استفاده شود:
 
 ```js{12-19}
 class ErrorBoundary extends React.Component {
@@ -431,9 +431,9 @@ UNSAFE_componentWillMount()
 
 > نکته
 >
-> این چرخه‌ی حیات قبلا `componentWillMount` نام داشت. این اسم تا نسخه ۱۷ کار خواهد کرد. از [`rename-unsafe-lifecycles` codemod](https://github.com/reactjs/react-codemod#rename-unsafe-lifecycles) برای بروزرسانی خودکار کامپوننت‌هایتان استفاده کنید.
+> این چرخه‌ی حیات قبلا `componentWillMount` نام داشت. این اسم تا نسخه ۱۷ کار خواهد کرد. از [`rename-unsafe-lifecycles` codemod](https://github.com/reactjs/react-codemod#rename-unsafe-lifecycles) برای به‌روز رسانی خودکار کامپوننت‌هایتان استفاده کنید.
 
-`UNSAFE_componentWillMount()` درست قبل از نصب و اجرای اولیه صدا زده می‌شود. قبل از `render()` صدا زده می‌شود، بنابراین صدا زدن `setState()` به صورت synchronous در این متد باعث رندر اضافه نخواهد شد. عموما، ما استفاده از `constructor()` را برای مقداردهی اولیه state پیشنهاد می‌کنیم.
+`UNSAFE_componentWillMount()` درست قبل از اجرای اولیه صدا زده می‌شود. قبل از `render()` صدا زده می‌شود، بنابراین صدا زدن `setState()` به صورت همزمان (synchronously) در این متد باعث رندر اضافه نخواهد شد. عموما، ما استفاده از `constructor()` را برای مقداردهی اولیه state پیشنهاد می‌کنیم.
 
 از معرفی هرگونه تاثیر جانبی و یا ثبت اشتراک در این متد خودداری کنید. برای چنین موارد استفاده‌ای، از `componentDidMount()` استفاده کنید.
 
@@ -449,7 +449,7 @@ UNSAFE_componentWillReceiveProps(nextProps)
 
 > نکته
 >
-> این چرخه‌ی حیات قبلا `componentWillReceiveProps` نام داشت. این نام تا نسخه 17 کار خواهد کرد. برای بروزرسانی خودکار کامپوننت‌هایتان از [`rename-unsafe-lifecycles` codemod](https://github.com/reactjs/react-codemod#rename-unsafe-lifecycles) استفاده نمایید.
+> این چرخه‌ی حیات قبلا `componentWillReceiveProps` نام داشت. این نام تا نسخه ۱۷ کار خواهد کرد. برای به‌روز رسانی خودکار کامپوننت‌هایتان از [`rename-unsafe-lifecycles` codemod](https://github.com/reactjs/react-codemod#rename-unsafe-lifecycles) استفاده نمایید.
 
 > نکته:
 >
@@ -457,15 +457,15 @@ UNSAFE_componentWillReceiveProps(nextProps)
 >
 > * اگر نیاز به **انجام یک اثر جانبی** (برای مثال fetch کردن داده و یا اعمال انیمیشن) در پاسخ یک تغییر در props دارید، از چرخه‌ی حیات [`componentDidUpdate`](#componentdidupdate) به عنوان جایگزین استفاده نمایید.
 > اگر از `componentWillReceiveProps` برای **محاسبه مجدد برخی داده‌ها زمانی که یک prop تغییر می‌کند** دارید استفاده می‌کردید، [از یک راهنمای memoization استفاده نمایید](/blog/2018/06/07/you-probably-dont-need-derived-state.html#what-about-memoization).
-> * اگر از `componentWillReceiveProps` برای **"reset" کردن بعضی state ها هنگام تغییر یک prop** استفاده می‌کردید، ایجاد یک کامپوننت [کاملا کنترل شده](/blog/2018/06/07/you-probably-dont-need-derived-state.html#recommendation-fully-controlled-component) یا [کاملا کنترل نشده با یک `key`](/blog/2018/06/07/you-probably-dont-need-derived-state.html#recommendation-fully-uncontrolled-component-with-a-key) به عنوان جایگزین را در نظر بگیرید.
+> * اگر از `componentWillReceiveProps` برای **"بازنشانی" کردن بعضی state ها هنگام تغییر یک prop** استفاده می‌کردید، ایجاد یک کامپوننت [کاملا کنترل شده](/blog/2018/06/07/you-probably-dont-need-derived-state.html#recommendation-fully-controlled-component) یا [کاملا کنترل نشده با یک `key`](/blog/2018/06/07/you-probably-dont-need-derived-state.html#recommendation-fully-uncontrolled-component-with-a-key) به عنوان جایگزین را در نظر بگیرید.
 >
 > برای چنین مواردی، [پیشنهادهای این مطلب وبلاگ در مورد state مشتق شده را دنبال کنید](/blog/2018/06/07/you-probably-dont-need-derived-state.html).
 
 `UNSAFE_componentWillReceiveProps()` قبل از اینکه یک کامپوننت ایجاد شده props جدید دریافت کند صدا زده می‌شود. اگر نیاز به بروزرسانی state در پاسخ به تغییرات prop دارید (برای مثال reset کردن آن)، ممکن است `this.props` و `nextProps` را مقایسه کنید و یک تغییر state به وسیله `this.setState()` را در این متد انجام دهید.
 
-توجه داشته باشید که اگر یک کامپوننت والد، دلیل دوباره رندر شدن کامپوننت شما باشد، حتی اگر props تغییری نکرده باشد، این متد صدا زده می‌شود. بنابراین اگر می‌خواهید تغییرات را کنترل کنید، از مقیسه مقدار فعلی و بعدی آن مطمئن شوید.
+توجه داشته باشید که اگر یک کامپوننت والد، دلیل دوباره رندر شدن کامپوننت شما باشد، حتی اگر props تغییری نکرده باشد، این متد صدا زده می‌شود. بنابراین اگر می‌خواهید تغییرات را کنترل کنید، از مقایسه مقدار فعلی و بعدی آن مطمئن شوید.
 
-ری‌اکت `UNSAFE_componentWillReceiveProps()` را با props اولیه هنگام [نصب و اجرای اولیه](#mounting) صدا نمی‌زند. فقط زمانی این متد صدا زده می‌شود که بعضی از props کامپوننت احتمال تغییر داشته باشند.
+ری‌اکت `UNSAFE_componentWillReceiveProps()` را با props اولیه هنگام [اجرای اولیه](#mounting) صدا نمی‌زند. فقط زمانی این متد صدا زده می‌شود که بعضی از props کامپوننت احتمال تغییر داشته باشند.
 صدا زدن `this.setState()` عموما باعث اجرای `UNSAFE_componentWillReceiveProps()` نمی‌شود.
 
 * * *
@@ -478,13 +478,13 @@ UNSAFE_componentWillUpdate(nextProps, nextState)
 
 > نکته
 >
-> این چرخه‌ی حیات قبلا `componentWillUpdate` نام داشت. این اسم تا نسخه 17 کار می‌کند. برای بروزرسانی خودکار کامپوننت‌هایتان از [`rename-unsafe-lifecycles` codemod](https://github.com/reactjs/react-codemod#rename-unsafe-lifecycles) استفاده نمایید.
+> این چرخه‌ی حیات قبلا `componentWillUpdate` نام داشت. این اسم تا نسخه ۱۷ کار می‌کند. برای به‌روز رسانی خودکار کامپوننت‌هایتان از [`rename-unsafe-lifecycles` codemod](https://github.com/reactjs/react-codemod#rename-unsafe-lifecycles) استفاده نمایید.
 
-`UNSAFE_componentWillUpdate()` درست قبل از رندر شدن، زمانی که props یا state جدید دریافت می‌شوند صدا زده می‌شود. از این مورد به عنوان یک فرصت برای انجام آماده‌سازی‌های لازم قبل از بروز بروزرسانی استفاده نمایید. این متد برای رندر اولیه صدا زده نمی‌شود.
+`UNSAFE_componentWillUpdate()` درست قبل از رندر شدن، زمانی که props یا state جدید دریافت می‌شوند صدا زده می‌شود. از این مورد به عنوان یک فرصت برای انجام آماده‌سازی‌های لازم قبل از به‌روز رسانی استفاده نمایید. این متد برای رندر اولیه صدا زده نمی‌شود.
 
-توجه داشته باشید که نمی‌توانید `this.setState()` را اینجا صدا بزنید; همچنین هیچ کار دیگری که باعث بروز یک بروزرسانی برای یک کامپوننت ری‌اکت (e.g. dispatch a Redux action) می‌شود تا قبل از اینکه `UNSAFE_componentWillUpdate()` مقداری را بازگرداند نباید انجام دهید.
+توجه داشته باشید که نمی‌توانید `this.setState()` را اینجا صدا بزنید. همچنین نباید هیچ کار دیگری که باعث اجرای یک به‌روز رسانی برای یک کامپوننت ری‌اکت (مانند dispatch کردن یک اکشن ریداکس) می‌شود انجام دهید، پیش‌از آن‌که  `UNSAFE_componentWillUpdate()` مقداری را بازگرداند.
 
-معمولا، این متد می‌تواند به وسیله `componentDidUpdate()` جایگزین شود. اگر شما در این متد چیزی را از DOM می‌خوانید (برای مثال ذخیره محل اسکرول)، شما می‌توانید آن منطق را به `getSnapshotBeforeUpdate()` منتقل کنید.
+معمولا، این متد می‌تواند با `componentDidUpdate()` جایگزین شود. اگر شما در این متد چیزی را از DOM می‌خوانید (برای مثال ذخیره محل اسکرول)، می‌توانید آن منطق را به `getSnapshotBeforeUpdate()` منتقل کنید.
 
 > نکته
 >
@@ -504,15 +504,15 @@ UNSAFE_componentWillUpdate(nextProps, nextState)
 setState(updater, [callback])
 ```
 
-`setState()` تغییرات را در state کامپوننت درج می‌کند و به ری‌اکت می‌گوید که این کامپوننت و فزندانش نیاز به یک رندر دوباره با state بروز شده دارند. این متد اصلی است که شما برای بروزرسانی رابط کاربری در پاسخ به کنترل کننده‌های رویدادها و پاسخ‌های سرور استفاده می‌نمایید.
+`setState()` تغییرات را در state کامپوننت درج می‌کند و به ری‌اکت می‌گوید که این کامپوننت و فزندانش نیاز به یک رندر دوباره با state بروز شده دارند. این متد اصلی است که شما برای به‌روز رسانی رابط کاربری در پاسخ به کنترل کننده‌های رویدادها (event handlers) و پاسخ‌های سرور استفاده می‌نمایید.
 
-`setState()` را به عنوان یک *درخواست* و نه یک دستور برای بروزرسانی کامپوننت در نظر بگیرید. برای حس کردن پرفورمنس بهتر، ری‌اکت ممکن است آن را به تاخیر بیاندازد، و سپس چندین کامپوننت را در یک لحظه بروز کند. ری‌اکت تضمین نمی‌کند که تغییرات state فورا اعمال شوند.
+`setState()` را به عنوان یک *درخواست* و نه یک دستور برای به‌روز رسانی کامپوننت در نظر بگیرید. برای حس کردن کارایی بهتر، ری‌اکت ممکن است آن را به تاخیر بیاندازد، و سپس چندین کامپوننت را در یک لحظه بروز کند. ری‌اکت تضمین نمی‌کند که تغییرات state فورا اعمال شوند.
 
-`setState()` همیشه در لحظه کامپوننت را بروز نمی‌کند. ممکن است تغییر را بسته‌بندی کرده و یا به تاخیر انداخته باشد. این موضوع خواندن `this.state` درست پس از صدا زدن `setState()` را به یک تله تبدیل کرده‌است. به جای اینکار، از `componentDidUpdate` یا یک `setState` callback (`setState(updater, callback)`) استفاده کنید، که اجرا شدن هر دو پس از اینکه بروزرسانی اعمال شده است، تضمین شده است. اگر نیاز به ست کردن state بر اساس state قبلی دارید، در مورد آرگومان `updater` در زیر بخوانید.
+`setState()` همیشه در لحظه کامپوننت را بروز نمی‌کند. ممکن است تغییر را بسته‌بندی کرده و یا به تاخیر انداخته باشد. این موضوع خواندن `this.state` درست پس از صدا زدن `setState()` را به یک تله تبدیل کرده‌است. به جای اینکار، از `componentDidUpdate` یا یک `setState` callback (`setState(updater, callback)`) استفاده کنید، که اجرا شدن هر دو پس از اینکه به‌روز رسانی اعمال شده است، تضمین شده است. اگر نیاز به ست کردن state بر اساس state قبلی دارید، در مورد آرگومان `updater` در زیر بخوانید.
 
 `setState()` همیشه منجر به یک رندر دوباره می‌شود مگر اینکه `shouldComponentUpdate()` مقدار `false` را بازگرداند. اگر در حال استفاده از آبجکت‌های قابل تغییر هستید و منطق رندرشدن شرطی نمی‌تواند در `shouldComponentUpdate()` پیاده‌سازی شود، صدا زدن `setState()` تنها زمانی که state جدید با state قبلی متفاوت است از رندر دوباره غیرضروری جلوگیری می‌کند.
 
-اولین آگومان یک تابع `updater` با امضا است:
+اولین آگومان یک تابع `updater` با این تعریف است:
 
 ```javascript
 (state, props) => stateChange
@@ -526,9 +526,9 @@ this.setState((state, props) => {
 });
 ```
 
-هر دو مقدار `state` و `props` دریافت شده در تابع updater ضمانت بروز بودن را دارند. خروجی updater به طور سطحی با `state` ترکیب می‌شود.
+ضمانت می‌شود که هر دو مقدار `state` و `props` دریافت شده در تابع updater به‌روز باشند. خروجی updater به طور سطحی با `state` ترکیب می‌شود.
 
-دومین پارامتر `setState()` یک تابع callback اختیاری است که یکبار زمانی که `setState` به طور کامل اجرا شده و کامپوننت دوباره رندر شده‌است، اجرا می‌شود. معمولا ما استفاده از `componentDidUpdate()` را برای چنین منطق‌هایی پیشنهاد می‌کنیم.
+دومین پارامتر `setState()` یک تابع callback اختیاری است که یک‌بار زمانی که `setState` به طور کامل اجرا شده و کامپوننت دوباره رندر شده‌است، اجرا می‌شود. معمولا ما استفاده از `componentDidUpdate()` را برای چنین منطق‌هایی پیشنهاد می‌کنیم.
 
 شما ممکن است به شکل اختیاری یک آبجکت را به جای تابع به عنوان آرگومان اول `setState()` پاس دهید:
 
@@ -542,7 +542,7 @@ setState(stateChange[, callback])
 this.setState({quantity: 2})
 ```
 
-این شکل `setState()` نیز asynchronous است و چندین فراخوانی در یک چرخه ممکن است باعث دسته‌بندی با یکدیگر شود. برای مثال، اگر اقدام به افزایش مقدار یک آیتم در یک چرحه یکسان بیش از یکبار کنید، نتیجه برابر خواهد بود با:
+این شکل `setState()` نیز هم‌زمان است و چندین فراخوانی در یک چرخه ممکن است باعث دسته‌بندی با یک‌دیگر شود. برای مثال، اگر اقدام به افزایش مقدار یک آیتم در یک چرخه یکسان بیش از یک‌بار کنید، نتیجه برابر خواهد بود با:
 
 ```javaScript
 Object.assign(
@@ -565,7 +565,7 @@ this.setState((state) => {
 
 * [راهنمای State و چرخه‌ی حیات](/docs/state-and-lifecycle.html)
 * [در اعماق: کی و چرا صدا زدن‌های `setState()` دسته‌بندی می‌شوند؟ ](https://stackoverflow.com/a/48610973/458193)
-* [در اعماق: چرا `this.state` فورا بروزرسانی نمی‌شود؟ ](https://github.com/facebook/react/issues/11527#issuecomment-360199710)
+* [در اعماق: چرا `this.state` فورا به‌روز رسانی نمی‌شود؟ ](https://github.com/facebook/react/issues/11527#issuecomment-360199710)
 
 * * *
 
@@ -577,7 +577,7 @@ component.forceUpdate(callback)
 
 به طور پیش‌فرض، زمانی که state یا props کامپوننتتان تغییر می‌کند، کامپوننت شما دوباره رندر خواهد شد. اگر متد `render()` شما وابسته به دیگر داده‌ها است، شما می‌توانید به وسیله `forceUpdate()` به ری‌اکت بگویید که کامپوننت نیاز به رندر دوباره دارد.
 
-صدازدن `forceUpdate()` باعث می‌شود `render()` کامپوننت، بدون توجه به نتیجه `shouldComponentUpdate()` صدا زده شود. اینکار باعث اجرای متدهای چرخه‌ی حیات عادی کامپوننت‌های فرزند، شامل متد `shouldComponentUpdate()` هر یک از فرزندان می‌‌شود. ری‌اکت همچنان فقط زمانی DOM را بروز می‌کند که نشانه گذاری تغییر کند.
+صدازدن `forceUpdate()` باعث می‌شود `render()` کامپوننت، بدون توجه به نتیجه `shouldComponentUpdate()` صدا زده شود. اینکار باعث اجرای متدهای چرخه‌ی حیات عادی کامپوننت‌های فرزند، شامل متد `shouldComponentUpdate()` هر یک از فرزندان می‌‌شود. ری‌اکت همچنان فقط زمانی DOM را بروز می‌کند که markup تغییر کند.
 
 در حالت عادی باید تلاش کنید تا از تمامی استفاده‌های `forceUpdate()` خودداری نمایید و در `render()` فقط از `this.props` و `this.state` داده‌ها را بخوانید.
 

From cf876e371cbd1907e0d6e50cab4d9f9b169aa9cf Mon Sep 17 00:00:00 2001
From: Hossein Ahmadi <43136173+hosseinAMD@users.noreply.github.com>
Date: Mon, 6 Jul 2020 10:59:07 +0430
Subject: [PATCH 13/15] Update content/docs/reference-react-component.md

---
 content/docs/reference-react-component.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/docs/reference-react-component.md b/content/docs/reference-react-component.md
index 8401b33d7..3b335e458 100644
--- a/content/docs/reference-react-component.md
+++ b/content/docs/reference-react-component.md
@@ -278,7 +278,7 @@ static getDerivedStateFromProps(props, state)
 
 این متد برای [موارد استفاده نادر](/blog/2018/06/07/you-probably-dont-need-derived-state.html#when-to-use-derived-state) که state وابسته به تغییرات props در طول زمان است وجود دارد. برای مثال، ممکن است برای پیاده‌سازی یک کامپوننت `<Transition>` که فرزند قبلی و بعدی خود را برای تصمیم‌گیری اینکه برای کدام‌یک انیمیشن ورود و برای کدام‌یک انیمیشن خروج را اعمال کند مقایسه می‌کند، کاربردی باشد.
 
-اشتقاق state باعث بلندی کد می‌شود و فکر کردن در مورد کامپوننت شما را سخت می‌کند.
+اشتقاق (deriving) state باعث بلندی کد می‌شود و فکر کردن در مورد کامپوننت شما را سخت می‌کند.
 [مطمئن شوید با جایگزین‌های ساده‌تر آشنا هستید:](/blog/2018/06/07/you-probably-dont-need-derived-state.html)
 
 * اگر نیاز به **انجام یک تاثیر بیرونی** (برای مثال fetch کردن داده یا اعمال انیمیشن) در پاسخ یک تغییر در props دارید، از متد چرخه‌ی حیات [`componentDidUpdate`](#componentdidupdate) به عنوان جایگزین استفاده کنید.

From 090b9c5cd05e0a7e367a832a4ac47f442a64e739 Mon Sep 17 00:00:00 2001
From: Hossein Ahmadi <43136173+hosseinAMD@users.noreply.github.com>
Date: Mon, 6 Jul 2020 11:01:04 +0430
Subject: [PATCH 14/15] Update content/docs/reference-react-component.md

---
 content/docs/reference-react-component.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/docs/reference-react-component.md b/content/docs/reference-react-component.md
index 3b335e458..8e7c1a0a8 100644
--- a/content/docs/reference-react-component.md
+++ b/content/docs/reference-react-component.md
@@ -281,7 +281,7 @@ static getDerivedStateFromProps(props, state)
 اشتقاق (deriving) state باعث بلندی کد می‌شود و فکر کردن در مورد کامپوننت شما را سخت می‌کند.
 [مطمئن شوید با جایگزین‌های ساده‌تر آشنا هستید:](/blog/2018/06/07/you-probably-dont-need-derived-state.html)
 
-* اگر نیاز به **انجام یک تاثیر بیرونی** (برای مثال fetch کردن داده یا اعمال انیمیشن) در پاسخ یک تغییر در props دارید، از متد چرخه‌ی حیات [`componentDidUpdate`](#componentdidupdate) به عنوان جایگزین استفاده کنید.
+* اگر نیاز به **انجام یک تاثیر جانبی (side effect)** (برای مثال fetch کردن داده یا اعمال انیمیشن) در پاسخ یک تغییر در props دارید، از متد چرخه‌ی حیات [`componentDidUpdate`](#componentdidupdate) به عنوان جایگزین استفاده کنید.
 
 * اگر می‌خواهید **بعضی داده‌ها را فقط زمان تغییرات یک props محاسبه کنید**، [از یک memoization به عنوان جایگزین استفاده کنید](/blog/2018/06/07/you-probably-dont-need-derived-state.html#what-about-memoization).
 

From f4b820c879d12adb91121a8071a5cfdd741f9c21 Mon Sep 17 00:00:00 2001
From: Hossein Ahmadi <43136173+hosseinAMD@users.noreply.github.com>
Date: Mon, 6 Jul 2020 11:03:11 +0430
Subject: [PATCH 15/15] Update content/docs/reference-react-component.md

---
 content/docs/reference-react-component.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/docs/reference-react-component.md b/content/docs/reference-react-component.md
index 8e7c1a0a8..34ce3be54 100644
--- a/content/docs/reference-react-component.md
+++ b/content/docs/reference-react-component.md
@@ -315,7 +315,7 @@ getSnapshotBeforeUpdate(prevProps, prevState)
 
 ### مرزهای خطا (error boundaries) {#error-boundaries}
 
-[Error boundaries](/docs/error-boundaries.html) کامپوننت‌های ری‌اکت هستند که خطاهای جاوااسکریپت را هر جایی در درخت کامپوننت‌های فرزندشان می‌گیرند، آن ارورها را در کنسول در قالب لاگ نشان می‌دهند و یک UI به جای درخت کامپوننتی که کرش کرده است نمایش می‌دهد. Error boundaries خطاها را هنگام رندر شدن، در متدهای چرخه‌ی حیات و در سازنده‌های تمام درخت زیر آن‌ها می‌گیرند.
+[مرزهای خطا](/docs/error-boundaries.html) کامپوننت‌های ری‌اکت هستند که خطاهای جاوااسکریپت را هر جایی در درخت کامپوننت‌های فرزندشان می‌گیرند، آن خطا‌ها را در کنسول در قالب لاگ نشان می‌دهند و یک UI به جای درخت کامپوننتی که با خطا مواجه شده‌است، نمایش می‌دهد. مرزهای خطا هنگام رندر شدن، در متدهای چرخه‌ی حیات و در سازنده‌های تمام درخت کامپوننت‌های زیر خود، خطا ها را می‌گیرند.
 
 یک کامپوننت از جنس کلاس در صورتی که هر یک از متدهای چرخه‌ی حیات `static getDerivedStateFromError()`، `componentDidCatch()` یا هردوی آن‌ها را پیاده‌سازی کند، یک مرز خطا می‌شود. به‌روز رسانی state از این متدهای چرخه‌ی حیات به شما اجازه می‌دهد تا خطاهای کنترل نشده‌ی جاوااسکریپتی در درخت زیر آن را بگیرید و یک رابط کاربری مناسب نمایش دهید.