- شنبه ۸ آذر ۱۴۰۴
آزمایشگاههای ریاکت (بخش چهارم)
سایر ویژگیهای جدید ریاکت
درک افکتها در ریاکت همچنان دشوار است و این رایجترین مشکلی است که توسعهدهندگان مطرح میکنند. سال گذشته ما زمان قابل توجهی را صرف تحقیق در مورد نحوهٔ استفاده از افکتها و چگونگی سادهسازی و آسانترکردن درک آنها کردیم.
چکیده
ریاکت گه با نامهای React.js و ReactJS نیز شناخته میشود یک کتابخانهٔ رایگان و متن باز است که از جاوا اسکریپت استفاده میکند و برای فرانتاند مورد استفاده قرار میگیرد. هدف ریاکت سادهتر و روانترکردن ساخت رابطهای کاربری است که مبتنی بر کامپوننت باشند. این کتابخانه را شرکت متا یا همان فیسبوک سابق ساخته است و توسعهدهندگان مستقل با آن همکاری و در نگهداری و پشتیبانی از آن کمک میکنند.
اکنون دو امکان انتقالهای نمایشی و اکتیویتی برای آزمایش در react@experimental موجود هستند. این امکانات در محیط عملیاتی آزمایش شدهاند و پایدار هستند، اما API نهایی ممکن است براساس بازخوردها تغییر کند. میتوانید با ارتقای بستهٔ ریاکت به جدیدترین نسخهٔ آزمایشی این امکانات را امتحان کنید.
ReactJS یا ریاکت یکی از محبوبترین فریمورکهای کتابخانهٔ جاوا اسکریپت برای ساخت رابطهای کاربری پویا و جذاب است. با توجه به ویژگیهای این فریمورک، فرصتهای شغلی زیادی برای استخدام متخصصان این حوزه وجود دارد. دپارتمان فناوری اطلاعات و ارتباطات مجتمع فنی تهران با برگزاری دوره ری اکت این امکان را فراهم کرده تا شما بتوانید تجربهای خاص و کاربردی برای کاربران ایجاد کنید و عملکرد اپلیکیشنها را بهبود بخشید. افرادی که قصد دارند در دوره آموزشreactjs شرکت کنند باید آموزش طراحی وب سایت را گذرانده باشند. در غیر این صورت درک مباحث دورهٔ ریاکت برای آنها دشوار خواهد بود.
در مطلب آزمایشگاههای ریاکت (بخش نخست) بخشی از بهروزرسانیهای انتقال نمایشی را توضیح دادیم. در بخش دوم آزمایشگاههای ریاکت به سفارشیسازی انیمیشن پرداختیم و از آنجا بحث دربارهٔ انتقالهای نمایشی را ادامه دادیم. در آزمایشگاههای ریاکت (بخش سوم) به امکان جدید دیگر ریاکت یعنی اکتیویتی پرداختیم. در این بخش که بخش آخر و پایانی است سایر امکانات جدید و درحال توسعهٔ ریاکت را بررسی میکنیم.
رندر سمت سرور با اکتیویتی
هنگام استفاده از اکتیویتی در صفحهای که از رندر سمت سرور یا SSR استفاده میکند امکانات بیشتری اضافه کردهایم. اگر بخشی از صفحه با mode="hidden” رندر شود، در پاسخ SSR گنجانده نخواهد شد. در عوض ریاکت یک رندر کلاینت را برای محتوای داخل اکتیویتی اجرا میکند و بقیهٔ صفحه در حالت هیدراته قرار میگیرد تا محتوای قابل مشاهده بر روی صفحه در اولویت قرار گیرد. برای بخشهایی از رابط کاربری که با mode="visible” رندر میشوند، ریاکت هیدراتهکردن محتوای داخل اکتیویتی را از اولویت خارج میکند، به همان شیوهای که محتواهای ساسپنس با اولویت کمتر هیدراته میشوند. اگر کاربر با آن صفحه تعامل داشته باشد، در صورت نیاز هیدراتهشدن را به حد معینی اولویتبندی میکنیم. اینها موارد استفادهٔ پیشرفتهٔ کلاینت هستند اما نشان میدهند که چه مزایای جدیدی به اکتیویتی اضافه شدهاند.
حالات جدید اکتیویتی در آینده
در آینده ممکن است حالتهای بیشترس به اکتیویتی اضافه کنیم. برای نمونه، یکی از موارد استفادهٔ رایج رندرکردن یک مدال است که در آن صفحهٔ «غیرفعال» قبلی در پشت نمای مدال «فعال» قرار میگیرد. حالت hidden برای این مورد قابل استفاده نیست، زیرا قابل مشاهده نیست و در SSR گنجانده نشده است.
ما در عوض در حال بررسی حالت جدیدی هستیم که محتوا را قابل مشاهده کند -و در SSR گنجانده میشود- اما آن را اجرانشده نگه دارد و اولویت بهروزرسانیها را از بین ببرد. این حالت همچنین ممکن است نیاز به pause در بهروزرسانیهای DOM داشته باشد، زیرا مشاهدهٔ بهروزرسانی محتوای پسزمینه در حالی که یک مدال باز است میتواند حواسپرتی ایجاد کند.
حالت دیگری که برای Activity در نظر داریم قابلیت ازبینبردن خودکار وضعیت برای اکتیویتیهای پنهان در صورت استفادهٔ بیش از حد از حافظه است. از آنجایی که کامپوننت از قبل unmounted شده است، ممکن است ترجیح این باشد که وضعیت بخشهای پنهان برنامه که اخیراً کمتر استفاده شدهاند از بین برود تا منابع زیادی مصرف نشود.
اینها حوزههایی هستند که ما هنوز در حال بررسی آنها هستیم و با پیشرفت کار اطلاعات بیشتری را به اشتراک خواهیم گذاشت. برای اطلاعات بیشتر در مورد اینکه اکتیویتی اکنون شامل چه مواردی میشود، به بخش مستندات مراجعه کنید.
امکانات درحال توسعهٔ ریاکت
ما درحال توسعه امکاناتی در ریاکت هستیم که به حل مشکلات رایج زیر کمک میکنند.
همانطور که درحال بررسی راهحلهای ممکن هستیم، برخی از APIهای بالقوهای را که آزمایش میکنیم بر اساس PRهایی که به دست میآوریم به اشتراک میگذاریم. لطفاً در نظر داشته باشید که وقتی ایدههای مختلف را امتحان میکنیم، اغلب راهحلهای مختلف را پس از امتحانکردن آنها تغییر میدهیم یا حذف میکنیم.
وقتی راهحلهایی که روی آنها کار میکنیم خیلی زود به اشتراک گذاشته میشوند، باعث ایجاد ریزش مخاطبان و سردرگمی آنها میشود. برای ایجاد تعادل بین شفافیت در ارائهٔ راهحلها و کاهش سردرگمی، مشکلاتی را که درحال حاضر درحال توسعه راهحل برای آنها هستیم بدون به اشتراک گذاشتن راهحلی خاص که در ذهن داریم، به اشتراک میگذاریم.
با پیشرفت این امکانات آنها را در وبلاگ خود با اسناد همراه آنها اعلام خواهیم کرد تا بتوانید آنها را امتحان کنید.
ردیابیهای عملکرد ریاکت
ما درحال کار بر روی مجموعهای جدید از مسیرهای سفارشی برای پروفایلرهای عملکرد با استفاده از APIهای مرورگر هستیم که امکان اضافهکردن مسیرهای سفارشی را برای ارائهٔ اطلاعات بیشتر در مورد عملکرد برنامه ریاکت شما فراهم میکنند.
این امکان هنوز در حال توسعه است، بنابراین هنوز آمادهٔ انتشار اسناد کامل آن بهعنوان یک امکان آزمایشی نیستیم. میتوانید هنگام استفاده از نسخهٔ آزمایشی ریاکت پیشنمایشی از آن را مشاهده کنید که بهطور خودکار مسیرهای عملکرد را به پروفایلها اضافه میکند.
چند مشکل در این امکان جدید شناختهشده وجود دارد که قصد داریم به آنها رسیدگی کنیم، مانند عملکرد و اینکه مسیر زمانبندی همیشه در درختان ساسپنس «اتصال» ایجاد نمیکند، بنابراین هنوز کاملاً آمادهٔ امتحانکردن نیست. همچنین درحال جمعآوری بازخورد از کاربران اولیه برای بهبود طراحی و قابلیت استفاده از مسیرها هستیم. پس از حل این مشکلات اسناد آزمایشی را منتشر کرده و اعلام خواهیم کرد که آماده امتحانکردن است.
وابستگیهای افکت خودکار در ریاکت
ما برای انتشار هوکها سه انگیزه داشتیم که عبارتاند از
- به اشتراکگذاری کد بین کامپوننتها
هوکها جایگزین الگوهایی مانند render props و کامپوننتهای مرتبه بالاتر شدند تا به شما امکان دهند بدون تغییر سلسله مراتب کامپوننت از منطق stateful دوباره استفاده کنید.
- به عملکرد فکر کنید نه چرخههای عمر
هوکها به شما امکان میدهند یک کامپوننت را براساس قطعات مرتبط (مانند تنظیم اشتراک یا واکشی دادهها) به توابع کوچکتر تقسیم کنید، نه اینکه براساس روشهای چرخه عمر تقسیم را اجباری کنید.
- پشتیبانی از کامپایل پیش از موعد
هوکها برای پشتیبانی از کامپایل پیش از موعد طراحی شدهاند و مشکلات کمتری دارند که باعث عدم بهینهسازی ناشی از متدهای چرخه عمر و محدودیتهای کلاسها میشوند.
از زمان انتشار هوکها آنها در اشتراکگذاری کد بین کامپوننتها موفق بودهاند. هوکها اکنون روش محبوبی برای اشتراکگذاری منطق بین کامپوننتها هستند و موارد استفاده کمتری برای render props و کامپوننتهای مرتبه بالاتر وجود دارد. هوکها همچنین در پشتیبانی از ویژگیهایی مانند Fast Refresh که با کامپوننتهای کلاس امکانپذیر نبودند موفق بودهاند.
کار با افکتها دشوار است
متأسفانه هنوز هم فکرکردن به برخی از هوکها از منظر عملکرد بهجای منظر چرخه عمر دشوار است. به طور خاص درک افکتها هنوز دشوار است و این رایجترین مشکلی است که توسعهدهندگان مطرح میکنند. سال گذشته ما زمان قابل توجهی را صرف تحقیق در مورد نحوهٔ استفاده از افکتها و چگونگی سادهسازی و آسانترکردن درک آنها کردیم.
ما دریافتیم که اغلب سردرگمی در استفاده از یک افکت در زمانی است که نیازی به آن ندارید. راهنمای «ممکن است به یک افکت نیاز نداشته باشید» مطالب زیادی را پوشش میدهد که در آنها افکت راه حل مناسبی نیست. با این حال حتی وقتی یک افکت برای یک مشکل باشد، درک افکتها هنوز هم ممکن است دشوارتر از چرخه عمر کامپوننت کلاس باشد.
ما معتقدیم یکی از دلایل سردرگمی توسعهدهندگان این است که آنها به افکتها از منظر کامپوننت (مانند یک چرخه عمر) مینگرند نه از منظر خود افکت و آنچه افکت انجام میدهد. به مثال زیر از بخش اسناد توجه کنید.
useEffect(() => {
// Your Effect connected to the room specified with roomId...
const connection = createConnection(serverUrl, roomId);
connection.connect();
return () => {
// ...until it disconnected
connection.disconnect();
};
}, [roomId]);
بسیاری از کاربران این کد را به این صورت میخوانند که «هنگام نصب به roomId متصل شو. هر زمان roomId تغییر کرد، به اتاق قدیمی متصل شو و اتصال را دوباره ایجاد کن». با این حال، این تفکر از دیدگاه چرخهٔ عمر کامپوننت معتبر است، به این معنی که برای نوشتن صحیح افکت باید به همهٔ حالتهای چرخهٔ عمر کامپوننت فکر کنید. این کار میتواند دشوار باشد، بنابراین قابل درک است که افکتها هنگام استفاده از آنها از دیدگاه کامپوننت دشوارتر از چرخهٔ عمر کلاس به نظر میرسند.
افکتهای بدون وابستگی
در عوض بهتر است از دیدگاه افکت فکر کنیم. افکت از چرخهٔ عمر کامپوننت چیزی نمیداند و فقط نحوهٔ شروع همگامسازی و نحوهٔ توقف آن را شرح میدهد. وقتی کاربران به افکتها از این منظر فکر میکنند، نوشتن افکتها برای آنها آسانتر میشود و در مورد شروع و توقف به دفعات مورد نیاز انعطافپذیرتر عمل میکنند.
ما مدتی را صرف تحقیق کردیم تا ببینیم چرا افکتها اغلب از دیدگاه کامپوننت در نظر گرفته میشوند و دیدیم یکی از دلایل آن آرایهٔ وابستگی است. از آنجایی که باید آن را بنویسید، درست روبهروی شما قرار میگیرد و به شما یادآوری میکند به چه چیزی «واکنش» نشان میدهید و این امر شما را در مدل ذهنی «وقتی این مقادیر تغییر کردند، این کار را انجام دهید» قرار میدهد.
وقتی هوکها را منتشر کردیم، میدانستیم که میتوانیم استفاده از آنها را با کامپایل قبل از موعد آسانتر کنیم. اکنون با کامپایلر ریاکت میتوانید در بیشتر موارد از نوشتن useCallback و useMemo خودتان اجتناب کنید. کامپایلر برای افکتها میتواند وابستگیها را برای شما وارد کند:
useEffect(() => {
const connection = createConnection(serverUrl, roomId);
connection.connect();
return () => {
connection.disconnect();
};
}); // compiler inserted dependencies.
کامپایلر ریاکت با این کد میتواند وابستگیها را استنباط کرده و آنها را بهطور خودکار وارد کند، بنابراین نیازی به دیدن یا نوشتن آنها ندارید. با ویژگیهایی مانند افزونه IDE و useEffectEvent میتوانید یک CodeLens ارائه دهید تا به شما نشان دهد کامپایلر چه چیزی را در مواقعی که نیاز به عیبیابی یا بهینهسازی با حذف یک وابستگی دارید وارد کرده است. این امر به تقویت مدل ذهنی صحیح برای نوشتن افکتها کمک میکند و میتواند در هر زمانی برای همگامسازی وضعیت کامپوننت یا هوک با چیز دیگری اجرا شود.
امید ما این است که واردکردن خودکار وابستگیها نهتنها نوشتن کد را آسانتر کند، بلکه شما را مجبور کند در مورد کاری که افکت انجام میدهد فکر کنید، نه به چرخهٔ عمر کامپوننت، تا درک افکت نیز آسانتر شود.
افزونه کامپایلر IDE
اوایل این هفته ما نسخهٔ کامپایلر ریاکت را به اشتراک گذاشتیم و در تلاش هستیم تا اولین نسخهٔ پایدار کامپایلر SemVer را در ماههای آینده منتشر کنیم. ما همچنین بررسی روشهایی برای استفاده از کامپایلر ریکت را آغاز کردهایم و اطلاعاتی ارائه دادهایم که درک و عیبیابی کد شما را بهبود بخشد. یکی از ایدههایی که ما شروع به بررسی آن کردهایم یک افزونه آزمایشی جدید IDE در ریاکت است که مبتنی بر LSP باشد و کامپایلر ریاکت از آن پشتیبانی کند، مشابه افزونهای که در سخنرانی کنفرانس ریاکت توسط لورن تن از آن استفاده شد.
ایده ما این است که بتوانیم از تحلیل استاتیک کامپایلر برای ارائهٔ اطلاعات بیشتر، پیشنهادات بهتر و فرصتهای بهینهسازی مستقیماً در IDE استفاده کنیم. به عنوان مثال، میتوانیم کدی را که قوانین ریاکت را نقض میکند تشخیص دهیم، نشان دهیم آیا کامپوننتها و هوکها توسط کامپایلر بهینه شدهاند یا خیر، یا یک CodeLens برای دیدن وابستگیهای افکت که بهطور خودکار وارد شدهاند ارائه دهیم. افزونه IDE هنوز در مرحلهٔ کاوش اولیه است، اما پیشرفت خود را در بهروزرسانیهای آینده به اشتراک خواهیم گذاشت.
مراجع قطعهٔ کد
نوشتن بسیاری از APIهای DOM مانند APIهای مدیریت رویداد، موقعیتیابی و تمرکز هنگام نوشتن با ریاکت دشوار است. این امر اغلب توسعهدهندگان را به سمت استفاده از افکتها سوق میدهد. با استفاده از APIهایی مانند findDOMNode (که در ریاکت ۱۹ حذف شده است) میتوان چندین Ref را مدیریت کرد.
ما در حال بررسی اضافهکردن مرجعهایی به قطعات کد هستیم که به گروهی از عناصر DOM اشاره میکنند، نه فقط به یک عنصر. امید ما این است که این امکان مدیریت چندین فرزند را سادهتر کند و نوشتن کدهای قابل ترکیب ریاکت هنگام فراخوانی APIهای DOM را آسانتر کند. ساخت مرجعهای قطعات کد هنوز در مرحلهٔ تحقیق است. وقتی به تکمیل API نهایی نزدیکتر شدیم، اطلاعات بیشتری را به اشتراک خواهیم گذاشت.
انیمیشنهای حرکتی
ما همچنین در حال تحقیق در مورد راههایی برای بهبود ترنزیشنهای بصری برای پشتیبانی از انیمیشنهای حرکتی مانند کشیدن انگشت برای بازکردن یک منو یا پیمایش در یک مجموعه عکس هستیم. حرکت به چند دلیل چالشهای جدیدی را ایجاد میکند و این دلایل عبارتاند از
- حرکت پیوسته است
وقتی انگشت خود را میکشید، انیمیشن به زمان و نوع قرارگیری انگشت شما پیوند میخورد، نه اینکه فعال شود و تا پایان اجرا شود.
- حرکت کامل نمیشود
وقتی انگشت خود را رها میکنید، انیمیشنهای حرکتی میتوانند تا پایان اجرا شوند یا بسته به اینکه تا چه حد پیش رفتهاند، به حالت اولیهٔ خود بازگردند (مانند زمانی که فقط بخشی از یک منو را باز میکنید).
- حرکات قدیم و جدید را برعکس میکند
در حین انیمیشنسازی میخواهید صفحهای که از آن انیمیشن میسازید «زنده» و تعاملی باقی بماند. این کار مدل View Transition مرورگر را معکوس میکند که در آن حالت «قدیمی» یک تصویر لحظهای و حالت «جدید» DOM زنده است.
ما معتقدیم که رویکردی پیدا کردهایم که اثربخش است و شاید بهزودی یک API جدید برای راهاندازی انتقال حرکات معرفی کنیم. در حال حاضر بر روی ارائه <ViewTransition> تمرکز داریم و پس از آن دوباره به سراغ حرکات خواهیم رفت.
فروشگاههای همزمان در ریاکت
هنگامی که ریاکت ۱۸ را با امکان رندر همزمان منتشر کردیم، useSyncExternalStore را نیز منتشر کردیم تا کتابخانههای فروشگاه خارجی که از محتوا یا حالت ریاکت استفاده نمیکردند بتوانند با اعمال رندر همزمان هنگام بهروزرسانی فروشگاه از رندر پشتیبانی کنند. با این حال، استفاده از useSyncExternalStore هزینه دارد، زیرا باعث میشود از ویژگیهای همزمان مانند ترنزیشنها جلوگیری شود و محتوای موجود خطاهای Suspense را نشان دهد.
اکنون که ریاکت ۱۹ منتشر شده است، ما در حال بررسی مجدد این مشکل هستیم تا مدلی اولیه برای پشتیبانی کامل از فروشگاههای خارجی همزمان با استفاده از API ایجاد کنیم:
const value = use(store);
هدف ما این است که امکان دهیم حالت خارجی در حین رندر بدون اختلال خوانده شود و بهطور یکپارچه با تمام ویژگیهای همزمان ریاکت کار کند. این تحقیق هنوز در مراحل اولیه است. در آینده اطلاعات بیشتر و نحوهٔ نمایش APIهای جدید را به اشتراک خواهیم گذاشت.
برای نوشتن این مطلب از کمک افراد بسیاری بهره بردهایم ازجمله آرورا شارف، دن آبراموف، الی وایت، لورن تان، لونا وی، مت کارول، جک پوپ، جیسون بونتا، جردن براون، جردن الدریج، موفی ژانگ، سباستین لوربر، سباستین مارکبگه و تیم یونگ که این مطلب را بررسی کردند.
جمعبندی
در این سری مطالب در مورد پروژههای فعال در بخش تحقیق و توسعهٔ ریاکت صحبت کردیم. به دو ویژگی جدید ریاکت اشاره کردیم که اکنون آمادهٔ آزمایش هستند. همچنین بهروزرسانی سایر حوزههایی را که مشغول کار در آنها هستیم منتشر کردیم. امروز ما مفتخریم که مستندات مربوط به دو امکان جدید ریاکت را آمادهٔ تست هستند منتشر کنیم و آنها عبارتاند از:
- انتقالهای نمایشی
- اکتیویتی
سایر امکانات جدیدی که در حال توسعهٔ آنها هستیم عبارتاند از
- React Performance Tracks
- Compiler IDE Extension
- Automatic Effect Dependencies
- Fragment Refs
- Concurrent Stores
در مطلب آزمایشگاههای ریاکت (بخش نخست) بخشی از بهروزرسانیهای انتقال نمایشی را توضیح دادیم. در بخش دوم آزمایشگاههای ریاکت به سفارشیسازی انیمیشن پرداختیم و از آنجا بحث دربارهٔ انتقالهای نمایشی را ادامه دادیم. در آزمایشگاههای ریاکت (بخش سوم) به امکان جدید دیگر ریاکت یعنی اکتیویتی پرداختیم. در این بخش که بخش آخر و پایانی است سایر امکانات جدید و درحال توسعهٔ ریاکت را بررسی میکنیم.
ReactJS یا ریاکت یکی از محبوبترین فریمورکهای کتابخانهٔ جاوا اسکریپت برای ساخت رابطهای کاربری پویا و جذاب است. با توجه به ویژگیهای این فریمورک، فرصتهای شغلی زیادی برای استخدام متخصصان این حوزه وجود دارد. دپارتمان فناوری اطلاعات و ارتباطات مجتمع فنی تهران با برگزاری دوره ری اکت این امکان را فراهم کرده تا شما بتوانید تجربهای خاص و کاربردی برای کاربران ایجاد کنید و عملکرد اپلیکیشنها را بهبود بخشید. افرادی که قصد دارند در دوره آموزشreactjs شرکت کنند باید آموزش طراحی وب سایت را گذرانده باشند. در غیر این صورت درک مباحث دورهٔ ریاکت برای آنها دشوار خواهد بود.
در دنیای کسبوکار امروز، تحصیلات دانشگاهی برای حفظ ارزش شما بهعنوان نیروی کار بااستعداد و کارآمد کافی نیستند. برای اینکه مزیت رقابتی شخصی خود را حفظ کنید، باید بر آموزش مستمر و مادامالعمر خود سرمایهگذاری کنید. خانواده بزرگ مجتمع فنی تهران هرساله به هزاران نفر کمک میکند تا در مسیر شغلی خود پیشرفت کنند.
اگر شاغل هستید و وقت ندارید در دورههای آموزشی حضوری شرکت کنید، مجتمع فنی تهران گزینههایی عالی برای آموزش مجازی، آنلاین، آفلاین و ترکیبی ارائه میدهد. با شرکت در دورههای کوتاهمدت مجتمع فنی تهران و دریافت مدارک معتبر و بینالمللی میتوانید با اعتماد به نفس مسیر ترقی را طی کنید و در سازمان خود به مهرهای ارزشمند تبدیل شود.
نویسنده: ریکی هانلون
مترجم: بهناز دهکردی
منبع: React.dev
پرسشهای متداول
امکانات جدید ریاکت در ترنزیشن کداماند؟
- <ViewTransition> کامپوننتی است که به شما امکان میدهد یک انیمیشن را برای ترنزیشن یا انتقال فعال کنید.
- addTransitionType: تابعی است که به شما امکان میدهد علت ترنزیشن را مشخص کنید.
- <Activity> کامپوننتی است که به شما امکان میدهد بخشهایی از رابط کاربری را پنهان یا آشکار کنید.
ریاکت چیست؟
ریاکت گه با نامهای React.js و ReactJS نیز شناخته میشود یک کتابخانهٔ رایگان و متن باز است که از جاوا اسکریپت استفاده میکند و برای فرانتاند مورد استفاده قرار میگیرد. هدف ریاکت سادهتر و رانترکردن ساخت رابطهای کاربری است که مبتنی بر کامپوننت باشند. این کتابخانه را شرکت متا یا همان فیسبوک سابق ساخته است و توسعهدهندگان مستقل با آن همکاری و در نگهداری و پشتیبانی از آن کمک میکنند.
استفاده از هوکها در ریاکت چه کاربردی دارد؟
- به اشتراکگذاری کد بین کامپوننتها
هوکها جایگزین الگوهایی مانند render props و کامپوننتهای مرتبه بالاتر شدند تا به شما امکان دهند بدون تغییر سلسله مراتب کامپوننت از منطق stateful دوباره استفاده کنید.
- به عملکرد فکر کنید نه چرخههای عمر
هوکها به شما امکان میدهند یک کامپوننت را براساس قطعات مرتبط (مانند تنظیم اشتراک یا واکشی دادهها) به توابع کوچکتر تقسیم کنید، نه اینکه براساس روشهای چرخه عمر تقسیم را اجباری کنید.
- پشتیبانی از کامپایل پیش از موعد
هوکها برای پشتیبانی از کامپایل پیش از موعد طراحی شدهاند و مشکلات کمتری دارند که باعث عدم بهینهسازی ناشی از متدهای چرخه عمر و محدودیتهای کلاسها میشوند.







