Tech Stuff

مدیریت 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

#react

@techstuff100

نکته حرفه‌ای React: چطور یک کامپوننت سنگین با children رو memoize کنیم؟

مموایز کردن کامپوننت‌های سنگین که children دارن، یه چالش جالبه که خیلی‌ها توش اشتباه می‌کنن. اکثرا فکر می‌کنن اگه هم برای children و هم کامپوننت سنگین از memo استفاده کنن کافیه. (کد ۱)

راه‌حل درست اینه که children رو با useMemo مموایز کنیم. چون children در نهایت یک آبجکته و با هر بار رندر، یک آبجکت جدید ساخته میشه. (کد ۲)

#react

@techstuff100

آشنایی با Database Sharding: وقتی دیتابیس بزرگ میشه چیکار کنیم؟

وقتی اپلیکیشن‌مون رشد می‌کنه و تعداد کاربرها و حجم دیتا زیاد میشه، یه نقطه‌ای میرسه که دیتابیس دیگه نمی‌کشه و response time میره بالا. این دقیقا همون جاییه که Database Sharding به کمکمون میاد.

تو Sharding میایم دیتابیس رو به تیکه‌های کوچکتر (shard) تقسیم می‌کنیم و روی چند تا سرور پخششون می‌کنیم. این کار رو می‌تونیم به روش‌های مختلفی مثل Range-based، Hash-based یا حتی Geo-based انجام بدیم. این کار پیچیدگی‌های خودش رو داره؛ مثلا باید حواسمون باشه که دیتا به صورت متوازن بین سرورها توزیع بشه تا hotspot نداشته باشیم.

لینک مقاله:
https://aws.amazon.com/what-is/database-sharding/

#system_design

@techstuff100

تفاوت any و unknown توی TypeScript

توی TypeScript، وقتی نمی‌دونیم یه مقدار دقیقا چه نوعی داره، معمولا از any استفاده می‌کنیم. در کنارش یه گزینه دیگه هم داریم: unknown.

می‌تونیم اینطوری مقایسه‌شون کنیم: any یعنی «بی‌خیال تایپ شو و هر کاری دوست داری بکن» آزادی کامل میده، ولی ریسک کرش بالا میره. unknown یعنی «من نمی‌دونم تایپش چیه، ولی قبل از استفاده باید مطمئن بشی» یه جورایی جلوی اشتباهات رو می‌گیره و کد امن‌تر میشه.

مثال رو ببینید.

#typescript

@techstuff100

هوک useImperativeHandle در React

توی این پست، درباره یک چالش رایج توی ری‌اکت صحبت کردم: چطور از توابع و استیت‌های یک کامپوننت فرزند در کامپوننت والد استفاده کنیم، بدون اینکه کل ساختار کامپوننت رو به هم بریزیم.
برای حل این مسئله از هوک useImperativeHandle استفاده می‌کنم و به همراه مثال توضیحش میدم.

#react

@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

#xss

@techstuff100

مدیریت تغییرات در node_modules با Patch Package

گاهی وقتا پیش میاد که مجبور باشیم به دلیل باگی توی یه پکیج npm، یه تغییر دستی توی node_modules بدیم. توی همچین موقعیتی، patch-package بکارمون میاد که تغییراتمون ماندگار بشه. توی این پست، با یه مثال عملی، استفاده ازش رو توضیح دادم.

#npm

@techstuff100