توی نسخه جدید React یه کامپایلر اومده که قراره خیلی از دردسرهای memoization رو حل کنه. اما واقعا چقدر خوب کار میکنه و روی پروژههای واقعی کارآمده؟
طبق تستهای انجام شده از این کامپایلر روی یک پروژه واقعی با ۱۵ هزار خط کد:
۱. روی initial load سایت تقریبا هیچ تاثیر منفی نداشت! یعنی با اینکه همه چیز رو مموایز میکنه، سنگینتر نشده.
۲. روی interactions performance خیلی خوب جواب داده.
۳. ❌ نمیتونیم به صورت کامل، مموایز کردن دستی رو بذاریم کنار، چون:
- طبق داکیومنت React، کتابخونههای خارجی باید قبل از استفاده با کامپایلر، کامپایل شده باشن و فعلا خیلی از کتابخونههای محبوب هنوز کامپایل نشدن.
- کدهای قدیمی ممکنه درست کار نکنن.
- گاهی کد ما نیاز به بهینهسازی دستی داره (برای حالتها و نیازهای خاص)
نتیجهگیری: اگه performance اپ براتون در اولویت اول نیست، فعال کردن کامپایلر میتونه نتایج قابل قبولی بده. ولی اگه میخواید بهترین عملکرد ممکن رو داشته باشید، هنوز هم باید memoization دستی رو بلد باشید.
مقاله:
https://www.developerway.com/posts/how-react-compiler-performs-on-real-code
@techstuff100
طبق تستهای انجام شده از این کامپایلر روی یک پروژه واقعی با ۱۵ هزار خط کد:
۱. روی initial load سایت تقریبا هیچ تاثیر منفی نداشت! یعنی با اینکه همه چیز رو مموایز میکنه، سنگینتر نشده.
۲. روی interactions performance خیلی خوب جواب داده.
۳. ❌ نمیتونیم به صورت کامل، مموایز کردن دستی رو بذاریم کنار، چون:
- طبق داکیومنت React، کتابخونههای خارجی باید قبل از استفاده با کامپایلر، کامپایل شده باشن و فعلا خیلی از کتابخونههای محبوب هنوز کامپایل نشدن.
- کدهای قدیمی ممکنه درست کار نکنن.
- گاهی کد ما نیاز به بهینهسازی دستی داره (برای حالتها و نیازهای خاص)
نتیجهگیری: اگه performance اپ براتون در اولویت اول نیست، فعال کردن کامپایلر میتونه نتایج قابل قبولی بده. ولی اگه میخواید بهترین عملکرد ممکن رو داشته باشید، هنوز هم باید memoization دستی رو بلد باشید.
مقاله:
https://www.developerway.com/posts/how-react-compiler-performs-on-real-code
@techstuff100
🔥3👍2❤1
مدیریت تغییرات در node_modules با Patch Package
گاهی وقتا پیش میاد که مجبور باشیم به دلیل باگی توی یه پکیج npm، یه تغییر دستی توی node_modules بدیم. توی همچین موقعیتی، patch-package بکارمون میاد که تغییراتمون ماندگار بشه. توی این پست، با یه مثال عملی، استفاده ازش رو توضیح دادم.
@techstuff100
گاهی وقتا پیش میاد که مجبور باشیم به دلیل باگی توی یه پکیج npm، یه تغییر دستی توی node_modules بدیم. توی همچین موقعیتی، patch-package بکارمون میاد که تغییراتمون ماندگار بشه. توی این پست، با یه مثال عملی، استفاده ازش رو توضیح دادم.
@techstuff100
👍5🔥2
چطور توکنها رو توی مرورگر امن نگه داریم؟
برای ذخیره access tokenها توی مرورگر، روشهای مختلفی مثل localStorage، sessionStorage و کوکیها و ... رو داریم. اما واقعیت اینه که هر کدوم از اینها نقاط ضعف و قوت خودشون رو دارن و اگه درست پیادهسازی نشن، احتمال حملات XSS و CSRF بالا میره. جالبه بدونید هیچ روش واقعا امنی برای ذخیره توکنها توی مرورگر وجود نداره و همشون به نوعی آسیبپذیرن.
یکی از بهترین روشها استفاده از کوکیهاست؛ البته با ست کردن اتربیوتهایی مثل HttpOnly و SameSite=Strict. همچنین میشه از الگوی Token Handler استفاده کرد که با رمزنگاری توکنها و مدیریتشون از طریق بکاند، ریسک حملات رو به حداقل رسوند.
لینک مقاله:
https://readmedium.com/en/https:/curity.medium.com/best-practices-for-storing-access-tokens-in-the-browser-6b3d515d9814
@techstuff100
برای ذخیره access tokenها توی مرورگر، روشهای مختلفی مثل localStorage، sessionStorage و کوکیها و ... رو داریم. اما واقعیت اینه که هر کدوم از اینها نقاط ضعف و قوت خودشون رو دارن و اگه درست پیادهسازی نشن، احتمال حملات XSS و CSRF بالا میره. جالبه بدونید هیچ روش واقعا امنی برای ذخیره توکنها توی مرورگر وجود نداره و همشون به نوعی آسیبپذیرن.
یکی از بهترین روشها استفاده از کوکیهاست؛ البته با ست کردن اتربیوتهایی مثل HttpOnly و SameSite=Strict. همچنین میشه از الگوی Token Handler استفاده کرد که با رمزنگاری توکنها و مدیریتشون از طریق بکاند، ریسک حملات رو به حداقل رسوند.
لینک مقاله:
https://readmedium.com/en/https:/curity.medium.com/best-practices-for-storing-access-tokens-in-the-browser-6b3d515d9814
@techstuff100
👍6🔥3
هوک useImperativeHandle در React
توی این پست، درباره یک چالش رایج توی ریاکت صحبت کردم: چطور از توابع و استیتهای یک کامپوننت فرزند در کامپوننت والد استفاده کنیم، بدون اینکه کل ساختار کامپوننت رو به هم بریزیم.
برای حل این مسئله از هوک useImperativeHandle استفاده میکنم و به همراه مثال توضیحش میدم.
@techstuff100
توی این پست، درباره یک چالش رایج توی ریاکت صحبت کردم: چطور از توابع و استیتهای یک کامپوننت فرزند در کامپوننت والد استفاده کنیم، بدون اینکه کل ساختار کامپوننت رو به هم بریزیم.
برای حل این مسئله از هوک useImperativeHandle استفاده میکنم و به همراه مثال توضیحش میدم.
@techstuff100
👍5🔥1🎉1
تفاوت any و unknown توی TypeScript
توی TypeScript، وقتی نمیدونیم یه مقدار دقیقا چه نوعی داره، معمولا از any استفاده میکنیم. در کنارش یه گزینه دیگه هم داریم: unknown.
میتونیم اینطوری مقایسهشون کنیم: any یعنی «بیخیال تایپ شو و هر کاری دوست داری بکن» آزادی کامل میده، ولی ریسک کرش بالا میره. unknown یعنی «من نمیدونم تایپش چیه، ولی قبل از استفاده باید مطمئن بشی» یه جورایی جلوی اشتباهات رو میگیره و کد امنتر میشه.
مثال رو ببینید.
@techstuff100
توی TypeScript، وقتی نمیدونیم یه مقدار دقیقا چه نوعی داره، معمولا از any استفاده میکنیم. در کنارش یه گزینه دیگه هم داریم: unknown.
میتونیم اینطوری مقایسهشون کنیم: any یعنی «بیخیال تایپ شو و هر کاری دوست داری بکن» آزادی کامل میده، ولی ریسک کرش بالا میره. unknown یعنی «من نمیدونم تایپش چیه، ولی قبل از استفاده باید مطمئن بشی» یه جورایی جلوی اشتباهات رو میگیره و کد امنتر میشه.
مثال رو ببینید.
@techstuff100
🔥7👍1👏1
آشنایی با Database Sharding: وقتی دیتابیس بزرگ میشه چیکار کنیم؟
وقتی اپلیکیشنمون رشد میکنه و تعداد کاربرها و حجم دیتا زیاد میشه، یه نقطهای میرسه که دیتابیس دیگه نمیکشه و response time میره بالا. این دقیقا همون جاییه که Database Sharding به کمکمون میاد.
تو Sharding میایم دیتابیس رو به تیکههای کوچکتر (shard) تقسیم میکنیم و روی چند تا سرور پخششون میکنیم. این کار رو میتونیم به روشهای مختلفی مثل Range-based، Hash-based یا حتی Geo-based انجام بدیم. این کار پیچیدگیهای خودش رو داره؛ مثلا باید حواسمون باشه که دیتا به صورت متوازن بین سرورها توزیع بشه تا hotspot نداشته باشیم.
لینک مقاله:
https://aws.amazon.com/what-is/database-sharding/
@techstuff100
وقتی اپلیکیشنمون رشد میکنه و تعداد کاربرها و حجم دیتا زیاد میشه، یه نقطهای میرسه که دیتابیس دیگه نمیکشه و response time میره بالا. این دقیقا همون جاییه که Database Sharding به کمکمون میاد.
تو Sharding میایم دیتابیس رو به تیکههای کوچکتر (shard) تقسیم میکنیم و روی چند تا سرور پخششون میکنیم. این کار رو میتونیم به روشهای مختلفی مثل Range-based، Hash-based یا حتی Geo-based انجام بدیم. این کار پیچیدگیهای خودش رو داره؛ مثلا باید حواسمون باشه که دیتا به صورت متوازن بین سرورها توزیع بشه تا hotspot نداشته باشیم.
لینک مقاله:
https://aws.amazon.com/what-is/database-sharding/
@techstuff100
🔥6👍1
نکته حرفهای React: چطور یک کامپوننت سنگین با children رو memoize کنیم؟
مموایز کردن کامپوننتهای سنگین که children دارن، یه چالش جالبه که خیلیها توش اشتباه میکنن. اکثرا فکر میکنن اگه هم برای children و هم کامپوننت سنگین از memo استفاده کنن کافیه. (کد ۱)
راهحل درست اینه که children رو با useMemo مموایز کنیم. چون children در نهایت یک آبجکته و با هر بار رندر، یک آبجکت جدید ساخته میشه. (کد ۲)
@techstuff100
مموایز کردن کامپوننتهای سنگین که children دارن، یه چالش جالبه که خیلیها توش اشتباه میکنن. اکثرا فکر میکنن اگه هم برای children و هم کامپوننت سنگین از memo استفاده کنن کافیه. (کد ۱)
راهحل درست اینه که children رو با useMemo مموایز کنیم. چون children در نهایت یک آبجکته و با هر بار رندر، یک آبجکت جدید ساخته میشه. (کد ۲)
@techstuff100
🔥7👍4
مدیریت state در React: از useState تا useReducer
مدیریت stateها توی کامپوننتهای React گاهی خیلی پیچیده میشه. مخصوصا وقتی از useStateهای متعدد برای state های مرتبط استفاده میکنیم. نتیجهش میشه یه کامپوننت شلوغ که نگهداریش سخته. وقتی stateها به هم وابستهن، آپدیت کردنشون با useStateهای جداگانه میتونه دردسرساز بشه. هر تغییر کوچیک نیاز به کلی کد داره و پیدا کردن باگها هم سختتر میشه؛ چون trace کردن تغییرات state خیلی پیچیدهست.
توی همچین وضعیتی، useReducer خیلی بکارمون میاد. به جای اینکه stateهای مرتبط رو با useStateهای جدا مدیریت کنیم، میتونیم همهشون رو توی یه آبجکت بذاریم و با یه reducer مدیریتشون کنیم. حتی میتونیم یه قدم جلوتر بریم و یه custom hook بسازیم که جزئیات پیادهسازی reducer رو مخفی کنه و یه interface تمیز به کامپوننتهامون بده. این جوری کدمون هم تمیزتر میشه، هم نگهداریش راحتتر.
لینک مقاله:
https://thetshaped.dev/p/how-to-use-reducer-in-react-for-better-and-simpler-state-management
@techstuff100
مدیریت stateها توی کامپوننتهای React گاهی خیلی پیچیده میشه. مخصوصا وقتی از useStateهای متعدد برای state های مرتبط استفاده میکنیم. نتیجهش میشه یه کامپوننت شلوغ که نگهداریش سخته. وقتی stateها به هم وابستهن، آپدیت کردنشون با useStateهای جداگانه میتونه دردسرساز بشه. هر تغییر کوچیک نیاز به کلی کد داره و پیدا کردن باگها هم سختتر میشه؛ چون trace کردن تغییرات state خیلی پیچیدهست.
توی همچین وضعیتی، useReducer خیلی بکارمون میاد. به جای اینکه stateهای مرتبط رو با useStateهای جدا مدیریت کنیم، میتونیم همهشون رو توی یه آبجکت بذاریم و با یه reducer مدیریتشون کنیم. حتی میتونیم یه قدم جلوتر بریم و یه custom hook بسازیم که جزئیات پیادهسازی reducer رو مخفی کنه و یه interface تمیز به کامپوننتهامون بده. این جوری کدمون هم تمیزتر میشه، هم نگهداریش راحتتر.
لینک مقاله:
https://thetshaped.dev/p/how-to-use-reducer-in-react-for-better-and-simpler-state-management
@techstuff100
👍3🤔1