Hooks API -revised #53
Conversation
Co-Authored-By: zahrajoulaei <zahrajoulaei@gmail.com>
Co-Authored-By: zahrajoulaei <zahrajoulaei@gmail.com>
Co-Authored-By: zahrajoulaei <zahrajoulaei@gmail.com>
Co-Authored-By: zahrajoulaei <zahrajoulaei@gmail.com>
Co-Authored-By: zahrajoulaei <zahrajoulaei@gmail.com>
Co-Authored-By: zahrajoulaei <zahrajoulaei@gmail.com>
Co-Authored-By: zahrajoulaei <zahrajoulaei@gmail.com>
Co-Authored-By: zahrajoulaei <zahrajoulaei@gmail.com>
Co-Authored-By: zahrajoulaei <zahrajoulaei@gmail.com>
sync with master
|
Deploy preview for fa-reactjs ready! Built with commit 04e68b3 |
There was a problem hiding this comment.
@seven-deuce عزیز، ممنون از ترجمه شما
سعی ما بر این است که در ترجمه متون به اصل متن وفادار باشیم و چیزی از آن کم و به آن اضافه نکنیم. در موارد پیشنهاد شده بیشتر مشاهده شد که کلمه‌ای ترجمه نشده است، فرم جمله عوض شده یا چیزی به آن اضافه شده است که اگر هم کمک به توضیح مطلب کرده باشد، باز هم پذیرفته نیست. اگر فکر می‌کنیم در حد یک تا دو کلمه نیاز است تا متن روان خوانده شود، آن را در کروشه [به این صورت] می‌آوریم.
فکر میکنم با بررسی موارد پیشنهاد شده متوجه منظور من خواهید شد و می‌توانید همین نکات را در ادامه متن (که هنوز بررسی نشده‌است) هم پیاده کنید. این طوری کار من هم ساده‌تر می‌شود :)
| #### Functional updates {#functional-updates} | ||
| #### به‌روز رسانی از طریق تابع {#functional-updates} | ||
|
|
||
| اگر state جدید با استفاده از `setState` قبلی محاسبه می‌شود، در آن صورت می‌توانید یک تابع را به عنوان آرگومان در setState وارد کنید. این تابع، متغیر پیشین برای state را دریافت خواهد کرد و متغیر به روز شده را خروجی خواهد داد. در مثال زیر، شما کامپوننتی را می‌بینید که کارش شمارش است و هر دو شکل تابع `setState` در آن استفاده شده است. |
There was a problem hiding this comment.
اگر state جدید با استفاده از state قبلی محاسبه می‌شود، شما می‌توانید یک تابع به setState پاس دهید. این تابع مقدار پیشین را دریافت، و مقدار به‌روز رسانی شده را باز می‌گرداند. در اینجا مثال یک کامپوننت شمارنده آورده شده‌است که هر دو شکل setState را استفاده می‌کند:
There was a problem hiding this comment.
فکر نمی کنم "پاس دادن تابع" عبارت رایجی باشه. من که تا حالا نشنیده بودم. فکر می کنم اینجا رو توضیحی بریم جلو ضرر نمی کنیم.
"مقدار" رو هم نمی تونیم استفاده کنیم، چون در این مثال هرچند مقدار استفاده شده، در حالت عمومی می تونه چیزی باشه غیر قابل شمارش. پس کلمه ی متغیر می تونه معادل بهتری باشه.
پیشنهاد من اینه که به این صورت بازنویسیش کنم:
اگر state جدید با استفاده از setState قبلی محاسبه می‌شود، در آن صورت می‌توانید یک تابع را به عنوان آرگومان در setState وارد کنید. این تابع، متغیر پیشین برای state را دریافت خواهد کرد و متغیر به روز شده را باز خواهد گرداند. در اینجا مثال یک کامپوننت شمارنده آورده شده‌است که هر دو شکل setState را استفاده می‌کند:
There was a problem hiding this comment.
اتفاقا در صحبت‌های فنی زیاد استفاده می‌شود عبارت‌هایی مثل "پاس دادن متغییر" یا "پاس دادن مقدار". حالا چون در جاوااسکریپت هم می‌شود یک تابع رو در متغییر ذخیره کرد اون هم قابل پاس دادن هست. پلی ترحمه شما هم ایرادی نداره و کاملا گویا هست.
There was a problem hiding this comment.
دقیقا متوجه نمی‌شم چرا از نظر شما استفاده از مقدار درست نیست. اما برای توضیح بیشتر می‌تونم بگم: مقدار و متغییر دو مفهوم مرتبط هستند اما به دو چیز متفاوت اشاره می‌کنند. یک متغییر می‌تواند دارای مقدار، جنس مشخص و اسم باشد. اما مقدار فقط یک مقدار هست مثل "1" یا true که به متغییری نسبت داده می‌شود.
در متن اصلی عبارت "the previous value" و "an updated value" آمده است که دقیقا به یک مقدار مشخص اشاره می‌کند و در کل بحث این پاراگراف درباره مقداری است که تغییر می‌کند. اگر از متغییر استفاده کنیم شاید مفهوم را برساند اما صحیح نیست.
There was a problem hiding this comment.
"مقدار" یعنی چیزی که قابل شمارش و اندازه گیری باشد. اما در استیت، ما همیشه مقدار قابل شمارش نداریم. مثال:
const [state, setState] = useState({count: 2, color: “red”})
در مثال بالا، می توانیم بگوییم مقدار
Count
چقدر است؟؟ اما نمی توانیم مقدار رنگ را بپرسیم.
با این همه، در تابع آپدیت کننده، من می توانم بر مبنای رنگ قبلی، رنگ جدید مشخصی را تعریف کنم. در آنجا نمی توانیم بگوییم که مقدار رنگ را عوض کرده ایم.
در کل زبان فارسی، فقط 2 واژه هست که در اینجا می توانیم استفاده کنیم: 1. متغیر 2. ارزش
یک واژه ی دیگر هم هست "ورده" که متداول نیست.
شاید در سایر زمینه های برنامه نویسی، بتوانیم بگوییم مقداردهی، اما در فحوای استیت، این درست نمی تواند باشد. باید طبیعت خاص استیت را در ری اکت در نظر بگیریم.
در ضمن، واژه ی متغییر درست نیست. متغیر درست است.
There was a problem hiding this comment.
در مثال color هم میشه گفت مقدار آن "red" (یعنی یه string) هست و اتفاقا بنظر هم درست میاد. راستش برای من خیلی بدیهی و جا افتاده هست و متوجه اشتباهی نمی‌شم!
متوجه طبیعت خاص استیت در ری‌اکت هم نشدم! ما مقدار رنگ رو بر مبنای مقدار قبلی تغییر نمی‌دهیم. میشه یه مقدار جدید به اون متغییر اختصاص داد. برای مثال:
this.setState({ color: 'red' });
this.setState({ color: 'green' });
در خط دوم مقدار جدیدی به متغییر color اختصاص دادیم.
نظر شما چیه در مورد بحث متغییر و مقداری که ما در اینجا داشتیم؟
@zahrajoulaei @sJJdGG
There was a problem hiding this comment.
این هم یک مثال:
const [ state, setState ] = useState( { count: 2, color: “red” } )
setState( prevState => {
switch ( prevState.color ) {
case "red"
return { ...prevState, ...{ color: "yellow" } };
break
default
return { ...prevState, ...{ color: "white" } };
}
} )
سوال : چه مقدار رنگ می خواهید؟
الف) آبی
ب) سبز متالیک
ج) بنفش
د) 2 سطل و نصفی!
:))
|
از بررسی که انجام دادید سپاسگزارم و تغییرات را خواهم داد. اما به عنوان یک برادر کوچکتر، پیشنهاداتی دارم که امیدوارم لحاظ کنید یا حداقل با دوستان دیگر به اشتراک گذاشته شود و به یک جمع بندی برسیم. رشته ی اصلی من، کارشناسی مترجمی زبان انگلیسی بوده. در دانشگاه ما مجبور بودیم مطالب متنوعی را ترجمه کنیم... از متون آشپزی و خیاطی گرفته تا مهندسی، سیاسی، اقتصادی و غیره مهمترین چیزی که در آن دوران به ما یاد دادند، این بود که ما 2 سبک ترجمه داریم: ترجمه ی تحت اللفظی ، و ترجمه ی معنایی هر کدام هم جای خودش را دارد. مثلا قراردادهای بین المللی تحت اللفظی باید ترجمه شوند، در حالیکه در متون ادبی نوع معنایی پسندیده تر است. من خیلی دوست دارم بدانم که مخاطب داکیومنتیشن فارسی ری اکت چه کسانی هستند؟ اگر کسانی باشند که تحصیلکرده و با تجربه باشند، همان متن انگلیسی را قادر خواهند بود که بخوانند. اما اگر انگلیسی نمی دانند، ما باید نهایت تلاش خودمان را بکنیم تا فهم آن در فارسی راحت تر شود. در غیر این صورت، گوگل ترنسلیت هم قادر خواهد بود تا ترجمه ی تحت اللفظی شکسته بسته ای را در اختیار آن دسته از مخاطبان قرار دهد. ساختار زبان انگلیسی تفاوت هایی با فارسی دارد که ترجمه ی تحت اللفظی را غامض می کند.مثلا، اکثر افعال ما در فارسی شکل مرکب دارند. مثل: درست کردن، آماده ساختن و... اما در انگلیسی افعال مرکب کمتر هستند و در نتیجه می توان به راحتی جملات مرکب ساخت. اما در فارسی، افعال مرکب ما در درون ساختار مرکب جملات، بسیار غامض می شود یعنی می شود مرکب به توان دو !! این مثال را ملاحظه کنید:
شما اینطور ترجمه کرده اید: > **یک متغییر دارای > state > و یک تابع برای به‌روز رسانی آن باز می‌گرداند.** در فارسی، باید بعد از مفعول، "را" بیاوریم. اما در متن بالا اضافه کردن آن سخت است، چون اولا 2 مفعول داریم، و بعد مفعول ما مرکب از چند کلمه است. یک ترفند مهمی که مترجم ها استفاده می کنند، در آوردن جملات کوتاه از درون جمله ی بلند است. جملات هرچقدر کوتاه باشند، فهم متن ساده تر می شود. من متن بالا را اینطور ترجمه کرده بودم: > **این هوک، دو چیز را از خود باز می‌گرداند: یک متغیر برای > state > و یک تابع برای به‌روز رسانی همان متغیر.** آیا فهم متن ساده تر نشد؟ آیا من چیزی از خودم به متن افزودم؟ آیا ماهیتش عوض شد؟ تنها کاری که من کردم، عوض کردن ساختار مرکب به ساختار خطی بود. مشابه همان کاری که در ورژن جدید جاوااسکریپت با دیکانستراکت انجام می دهیم و به همین خاطر بسیار محبوب است. ما نمی توانیم انتظار داشته باشیم که مولفان داکیومنتیشن ری اکت مثل ما از جملات کوتاه و غیر مرکب استفاده کنند، چون نیازی به این کار در انگلیسی نیست. جملات مرکب در انگلیسی همچنان راحت فهمیده می شوند. و حدس من این است که اگر از خود مولفان اصلی داکیومنتیشن بپرسیم تا نظر دهند، آنها از ساده تر شدن انتقال مفاهیم در نسخه ی فارسی حمایت خواهند کرد. چون سوال اصلی این است: آیا ترجمه ی ما حاوی اطلاعات اشتباه و گمراه کننده است؟ آیا چیزی از خود به آن افزودیم که مد نظر مولفان اصلی نبوده؟ اگر پاسخ به این سوال منفی است، پس هیچ ضرری در روان تر کردن متن فارسی نیست. خیلی دوست دارم در این مورد کمی بیشتر فکر کنیم و بقیه دوستان هم نظر دهند. قصد من هم تحمیل نظرم به کسی نیست. فقط خواستم تجربه ی خودم را به عنوان کسی که هم آکادمیک در این مورد درس خوانده و هم در نشریات (مجله ی اطلاعات علمی متعلق به موسسه ی روزنامه ی اطلاعات) کار ترجمه کرده با شما سهیم شوم تا به غنای این پروژه کمکی کرده باشم. |
|
ممنون از نکاتی که گفتین. خیلی درست و منطقیه حرفتون.و درنهایت هدف اینه که متن روان و قابل فهمی درست بشه. من هم حتما نکاتی که گفتید رو در نظر میگیرم و سعی میکنم جملات ساده تر و قابل فهم تری رو ایجاد کنم. |
|
@seven-deuce عزیز، خیلی خیلی ممنون از توضیح واضحی که نوشتید. قطعا هدف نهایی این اسناد همینه که یه مخاطب، با هر تخصص و سطح تحصیلات، از این متن بهره ببرد. پس ساده و روان بودن آن شرط اول است. راستی از این بابت هم خوشحالم که شما با تخصص ترجمه انگلیسی کنار ما هستید چون کار من فقط برنامه‌نویسی هست و می‌تونم از مشورت شما استفاده کنم. همیشه این دغدغه رو دارم که ترجمه من یک ترجمه معنایی است یا باعث دخل و تصرف در اصل متن شده‌ام؟ به همین خاطر سعی میکنم تا جای ممکن به متن انگلیسی نزدیک بمونم. برای مثال وقتی ترجمه شما رو می خوانم: این هوک، دو چیز را از خود باز می‌گرداند: یک متغیر برای state و یک تابع برای به‌روز رسانی همان متغیر. برای مثال فکر میکنم که جمله انگلیسی شاید این بوده: This hook returns two things: a variable for the state and a function that updates the variable. در حالیکه با جمله اصلی متفاوت است: Returns a stateful value, and a function to update it. بنظر شما این مشکلی ایجاد نمی‌کند؟ اگر نه، تا چه حدی من به عنوان یه مترجم می‌توانم این کار رو انجام بدهم؟ یا چه نشانه‌ای وجود دارد که بفهمم متن ترجمه شده بیشتر از حد مجاز تغییر کرده‌است؟ |
|
ممنون سروش جان، سوال خیلی خیلی خوبی رو مطرح کردی. اما در مورد ترجمه ی من برای اون عبارت، ترجمه ی مجددش به انگلیسی این میشه: > این هوک، دو چیز را از خود باز می‌گرداند: یک متغیر برای state و یک تابع برای به‌روز رسانی همان متغیر.
یکی از خصوصیات زبان انگلیسی که ما در فارسی نداریم، قدرت آن در ایجاز، و ترکیب پذیری فوق العاده ی آن است. مثلا در همین متن اصلی: Returns a **stateful** value, and a function to update it. ما در دیکشنری لغت Stateful نداریم. این کلمه ای است که مولف خلاقانه ساخته است و برای همه هم قابل فهم است. ما در فارسی چاره ای نداریم جز اینکه بیشتر توضیح دهیم. می توانیم این توضیحات را در قلاب یا پارانتز بیاوریم، اما وقتی تعدادش خیلی زیاد شود، زیبا نخواهد بود. پس نباید از کمک کردن به روشن شدن منظور متن، در فارسی، بترسیم. فارسی زبان مادری شماست و حق دارید در ضمن وفاداری به محتوای متن اصلی، به خواننده کمک کنید تا محتوا را ساده تر درک کند. تا همین اینجای کار قبول داریم که کلمه ی "استیت" رو نمی تونیم به فارسی ترجمه کنیم. پس اون رو عینا انتقال می دهیم. برای ترجمه ی بقیه اش از توضیح استفاده می کنیم: > یک متغیر برای state همینطور می تونستیم بگیم: > یک متغیر با state اما این دچار کژتابی می کنه چون ممکنه به نظر بیاد که ما داریم از 2 چیز حرف میزنیم، متغیر و استیت اگر به شیوه ی شما بگیم متغیر **دارای** استیت، باز هم کژتابی رخ میده. چون وقتی ما به طور مثال می گوییم، این کتاب **دارای** عکس است، به طور ضمنی این منظور را هم انتقال می دهیم که ممکن است حاوی چیزهایی **بجز** عکس هم باشد. اما در مورد این هوک، ما می دانیم که هرگز نباید از آن برای متغیری که فاقد استیت است استفاده کنیم. اگر چنین چیزی نیاز داشته باشیم یا از متغیر عادی استفاده می کنیم و یا پراپس اجازه دهید که مثال پیچیده تری را بررسی کنیم. موقع ترجمه ی این بخش من چندین بار مجبور به بازنویسی متن شدم:
اول از همه ترجمه ی **تحت اللفظی:** > useReducer > معمولا به > useState > ارجحیت دارد وقتی که استیتی با منطق پیچیده دارید که در خود متغیر های زیرین متعدد دارد و یا زمانی که استیت بعدی وابسته به استیت پیشین است. همچنین > useReducer > اجازه می دهد تا کامپوننت هایی که موجب بروزرسانی های عمیق می شوند را از نظر اجرا، بهینه کنید چون می توانید > dispatch > را به جای کال بک ها به پایین بفرستید. ترجمه ی بالا درسته و اشکالی توش نیست. اما دو-بعدی و مرکب اندر مرکب هست! یعنی ذهن خواننده ی مبتدی باید متغیر های زیادی رو در ذهنش نگه داره و مجسم کنه تا بتونه درکش بکنه. حالا من میام و این ساختار دو-بعدی رو می شکنم و به صورت خطی دیکانستراکتش می کنم: > اما چه زمانی بهتر است به جای > useState > از > useReducer > استفاده کنید؟ زمانی که > state > شما ساختار منطقی پیچیده ای دارد و شامل زیر مجموعه‌هایی با عضو‌های متعدد است، یا زمانی که > state > بعدی شما وابسته به > state > پیشین شما است. بعلاوه اگر کامپوننت‌هایی دارید که به‌روز رسانی در لایه‌های عمیق‌تری انجام می‌دهند، > useReducer > به شما این امکان را می‌دهد تا این فرایند را بهینه کنید چون قادر خواهید بود که به جای کال بک‌ها > (callbacks)، > از > dispatch > استفاده کنید. در مثال بالا من با استفاده از سوال-جواب، ساختار علت-معلولی ایجاد کردم که باعث میشه ذهن مخاطب فقط و فقط رو جواب سوال تمرکز کنه و منحرف نشه. به این روش ساختار مرکب رو هم از بین بردم. یک مثال دیگر هم در این متن بود که من را مجبور به بازنویسی دوباره کرد:
**ترجمه ی تحت اللفظی:** > یک آبجکت context (متغیری که از React.createContext باز گردانده می شود) را می پذیرد و و متغیر context فعلی را برای همان کانتکست باز می گرداند. متغیر کاتکست فعلی توسط prop نزدیکترین فوق کامپوننت فراخوانی کننده در درخت (ساختار) متغیر ها تعیین می شود. **ترجمه ی معنایی:** > این هوک، آبجکت > context > را دریافت می‌کند (همان متغیری که از > React.createContext > بازگردانده می‌شود) و بعد > value مرتبط با > context > فعلی را به ما می‌دهد. اما محتویات داخل > context > فعلی ما از کجا می‌آیند؟ از نزدیکترین > > به ما، فوق همین کامپوننت، که در خودش یک > prop > با عنوان > value > داشته باشد. |
|
کاملا متوجه منظور شما شدم. موافقم و قطعا ترجمه‌های معنایی خواناتر و بهتر از ترجمه‌های تحت‌الفظی شده‌است. پیش از این، من فکر می‌کردم که ساختار جمله باید حتما حفظ شود. سعی می‌کردم برای تک تک کلمات متناظری در ترجمه قرار دهم. حتی روی علایم نگارشی و تعداد آنها به خصوص کاما دقت می‌کردم. اما اگر در موارد ضروری (مثل موارد پیچیده‌ای که شما مثال زدید) بتوان از این موارد، در راستای بهتر شدن خوانایی متن، چشم پوشی کرد، قطعا نتیجه بهتر خواهد شد. اما هنوز با این مسئله کنار نیامده‌ام که در ترجمه سوال و جواب باشه در حالی که متن اصلی جمله ها خبری بوده است!به نوعی شما برداشت خود را نوشته‌اید و واقعا تغییر زیادی هست! ما مجاز به انجام آن هستیم؟ دوست دارم نظر شما رو هم بدونم در این مورد. @sJJdGG @zahrajoulaei |
|
بله به شما حق می دهم که به عوض شدن ساختار اعتراض کنید. واقعا لازم هم نیست که حتما شکل خبری را عوض کنیم. در همین مثال آخر، من می توانم فرم پرسشی را به همان حالت خبری باز گردانم، اما همچنان ترجمه ی معنایی و غیرمرکب انجام دهم: > این هوک، آبجکت context را دریافت می‌کند (همان متغیری که از React.createContext بازگردانده می‌شود) و بعد value مرتبط با context فعلی را به ما می‌دهد. محتویات داخل context فعلی ما از نزدیکترین MyContext.Provider فوق همین کامپوننت می آید، که در خودش یک prop با عنوان value داشته باشد. همچنین دقت دارید که در مثال بالا، من value را ترجمه نکردم، چون نام مشخص پراپ در سازنده ی کانتکست است و به معنای متغیر عمومی نیست. در گذشته، وفاداری به شکل و ساختار متن در ترجمه، خیلی مهم بود. این در طول زمان عوض شد و در حال حاضر، به جز در متن های حقوقی و جزایی، وفاداری به محتوا حفظ می شود اما نه به ساختار. چون ساختارهای زبانی با هم فرق دارند. مثلا در فارسی، فعل آخر جمله می آید، در انگلیسی در اول. همین تفاوت ساده، وفاداری به شکل را بسیار سخت می کند. اساسا داکیومنتیشن هایی که با لحن بیانگرانه نوشته می شوند هم محبوب ترند. شما مثلا داکیومنتیشن مانگو دی بی، یا ویو را ببینید. چرا در مورد آنها کتاب های گام به گام کمتری به نسبت نود جی اس نوشته می شود؟ چون خواندن داکیومنتیشن آنها راحت است. پس دلیلی به خواندن گام به گام نداریم. اما فهمیدن داکیومنتیشن نود جی اس کار هر کسی نیست. در نتیجه می بینیم که داکیومنتیشن های مدرن، مثل همین هایی که مثال زدم و یا خود اکسپرس، به سمت guide نوشتن می روند و از حالت specification دورتر می شوند. ترجمه ی تحت اللفظی، یعنی O(n) ترجمه ی معنایی یعنی: O(1) در گذشته، به دلیل نبودن رقابت زیاد، لازم نبود که صاحب یک تکنولوژی در مورد توضیح دادنش زیاد به خودش زحمت بدهد. اما در دنیای امروز، اگر رقیب محصولش را ساده تر از شما معرفی کند، مخاطب شما سادگی آن را به پیشرفتگی محصول شما ترجیح می دهد. |
|
@seven-deuce عزیز، متوجه منظور شما شدم. ممنون که با حوصله و دقت پاسخ من رو نوشتید. ادامه کار رو به زودی بررسی خواهم کرد، البته بیشتر از دید یک برنامه‌نویس :) راستی ما یک گروه اسلک هم داریم برای صحبت‌های بیشتر و هماهنگی‌ها. اگر تمایل داشتید برای من یک ایمیل ارسال کنید تا براتون دعوت نامه بفرستم. خوشحال می‌شیم بیشتر گپ و گفت داشته باشیم. |
|
کامنت هات رو برای فیکس شدن مشکل راست به چپ نویسی آپدیت کردم. نظرم رو هم در مورد کامنت هات حتمن در اولین فرصت میدم |
|
|
||
| #### Lazy initial state {#lazy-initial-state} | ||
| #### تعریف اولیه state از نوع کُند (Lazy initial state) {#lazy-initial-state} |
There was a problem hiding this comment.
تعریف state اولیه کند (Lazy)
There was a problem hiding this comment.
تعریف state اولیه از نوع کُند (Lazy)
در غیر این صورت معنا روشن نمیشه
|
|
||
| #### Lazy initialization {#lazy-initialization} | ||
| #### تعریف اولیه از نوع کُند (Lazy initialization) {#lazy-initialization} |
There was a problem hiding this comment.
فکر می کنم معادل مناسب initialization در فارسی "مقداردهی اولیه" باشد. برای مثال در اینجا تعریف متغییر مد نظر نیست و مقدار اولیه ای که به آن اختصاص داده می‌شود مورد بحث است. با نظر من موافق هستید؟
There was a problem hiding this comment.
اینجا همون چالش "مقدار" رو داریم.
هر طور فکر می کنم به "تعریف" می رسم. معادل بهتری به ذهنم نمیاد
There was a problem hiding this comment.
از نظر برنامه نویسی و کامپایلر تعریف متغییر (variable definition) و مقداردهی اولیه (initialization) دو گام جدا از هم دیده می‌شود. شما می توانید یک متغییر را تعریف کنید بدون اینکه مقداری برای اون مشخص کنید که مقدار آن undefined می‌شود. در این مقال هم تعریف متغییر یکسان است اما روش مقداردهی اولیه اون متفاوت است.
There was a problem hiding this comment.
@seven-deuce عزیز، ترجمه با کیفیت و دقیقی بود. مشخص بود که زمان زیادی رو برای اون صرف کردید و سپاسگذارم. من هم سعی کردم با پیشنهاداتم کار شما رو بهبود بدم. اگر فکر می‌کنید موردی نیاز به بحث دارد، با من در میان بگذارید.
content/docs/hooks-reference.md
Outdated
|
|
||
| Pass an inline callback and an array of dependencies. `useCallback` will return a memoized version of the callback that only changes if one of the dependencies has changed. This is useful when passing callbacks to optimized child components that rely on reference equality to prevent unnecessary renders (e.g. `shouldComponentUpdate`). | ||
| یک کال بک اینلاین و آرایه ای از وابستگیها را به آن بدهید. `useCallback` نسخه ی مموایز شده ای از کال بک را به شما باز خواهد گرداند. این نسخه فقط زمانی تغییر خواهد کرد که یکی از وابستگی‌هایش تغییر کند. این در چه مواقعی به درد می‌خورد؟ زمانی که می‌خواهیم کال بک‌ها را به کامپوننت‌های سطح پایینی بدهیم که بهینه شده اند. این کامپوننت‌ها با تکیه بر "برابری و تطبیق متغیر با مرجعش" از رندر‌های بی مورد جلوگیری می‌کنند (به طور مثال: `shouldComponentUpdate`). |
There was a problem hiding this comment.
کد یا شبه‌کد نباید به هیچ وجه ترجمه شود، دو مورد به صورتی که در متن اصلی هست نوشته شود:
useCallback(آرایه ی وابستگیها، تابع) --> useCallback(fn, deps)
useMemo(() => آرایه ی وابستگیها، تابع) --> useMemo(() => fn, deps)
There was a problem hiding this comment.
زمانی که می‌خواهیم callbackها را به کامپوننت‌های فرزند بدهیم
برای ترجمه child، معادل فرزند درست و جا افتاده است.
There was a problem hiding this comment.
زمانی که می‌خواهیم callbackها را به کامپوننت‌های فرزند بدهیم
برای ترجمه child، معادل فرزند درست و جا افتاده است.
نظر شما درباره این مورد چیه؟
There was a problem hiding this comment.
بله من هم تغییر رو دادم.
اما انتخاب خودم، ترکیب کامپوننت مادر / کامپوننت های زیرین هست.
مادر مفهوم عامتر و روشنی داره. اما فرزند آن قدر ها مشخص نیست. اما زیرین، جهت نگاه خواننده رو متمرکز می کنه.
این یک بحث پیشرفته در زبان شناسی هست. اینکه چطور واژه هایی رو استفاده کنیم که به طور ناخودآگاه، معنای قوی تری داشته باشن. در واقع بار احساسی، یا تصویری بیشتری داشته باشن.
مثلا ثروت و پول تقریبا هم معنا هستند، اما تاثیرگذاری پول بیشتره. جنایت و آدم کشی مشابه اند، اما آدم کشی تاثیرگذاریش بیشتره
اینجاست که ترجمه، تبدیل به هنر میشه و از دیدگاه اساتید، ترجمه خوب یعنی بازآفرینی اثر
البته در انتخاب این واژه ها، مسلما سلیقه ی ما هم تا حدی تاثیر داره؛ تنها راه پیدا کردن بهترین مورد، اینه که این متن رو با واژه های متفاوت، به کسی که هیچ چیزی در مورد ری اکت نمی دونه، بدیم بخونه و بگه کدوم رو سریعتر می فهمه
|
|
||
| If no array is provided, a new value will be computed on every render. | ||
| اگر آرایه ای به آن نداده باشید، ارزش آن متغیر در هر رندر مجددا محاسبه خواهد شد. |
There was a problem hiding this comment.
اگر آرایه ای به آن نداده باشید، یک مقدار جدید در هر رندر مجددا محاسبه خواهد شد.
There was a problem hiding this comment.
همون چالش مقدار....
| @@ -374,15 +392,18 @@ function TextInputWithFocusButton() { | |||
| } | |||
| ``` | |||
|
|
|||
| Essentially, `useRef` is like a "box" that can hold a mutable value in its `.current` property. | |||
| به عبارت دیگر، `useRef` مانند ظرفی است که قادر است یک متغیر قابل تغییر را داخل پراپرتی `.current` خودش نگه دارد. | |||
There was a problem hiding this comment.
به عبارت دیگر، useRef مانند ظرفی است که قادر است یک مقدار قابل تغییر را داخل پراپرتی .current خودش نگه دارد.
There was a problem hiding this comment.
بحث شیرین مقدار...
|
|
||
| You might be familiar with refs primarily as a way to [access the DOM](/docs/refs-and-the-dom.html). If you pass a ref object to React with `<div ref={myRef} />`, React will set its `.current` property to the corresponding DOM node whenever that node changes. | ||
| با این همه، کاربرد `useRef()` بیشتر از صفت ref آن است. چون وقتی بخواهید [متغیری را که ارزشش ممکن است عوض شود را دم دست نگه دارید](/docs/hooks-faq.html#is-there-something-like-instance-variables)، به راحتی به کارتان خواهد آمد. همانند زمانی که از instance fields در کلاس‌ها استفاده می‌کردید. |
There was a problem hiding this comment.
... چون وقتی بخواهید هر مقدار قابل تغییر را دم دست نگه دارید، به راحتی به کارتان خواهد آمد. همانند زمانی که فیلدهای instance در کلاس‌ها را استفاده می‌کردید.
There was a problem hiding this comment.
آن مقدار بیمقدار...
|
@sorousht |
خواهش میکنم. چندتا نظر جدید هم نوشتم. |
|
دوستان اگر به جمع بندی در مورد این صفحه رسیدید لطفا اعلام کنید |
@seven-deuce سلام، چند روزی من نبودم و ببخشید اگر کار بررسی کمی طول کشید. ممنون از تغییراتی که انجام دادید. |
No description provided.