کدهالیک | codehalic
4.05K subscribers
450 photos
41 videos
67 files
517 links
دوره های آموزشیمون رو از داخل سایت ببینید

https://codehalic.ir
Download Telegram
کدهالیک | codehalic
برای گرفتن دیزاین استاندارد و تمیز از هوش مصنوعی ، اول ساختار رو براش تعریف کن. چطوری؟ با فایل‌های MD وبسایت Refero Styles با کلی ساختار آماده دقیقا برای همین کار ساخته شده. بزرگترین کتابخانه فایل های design.md برای ایجنت های هوش مصنوعی! https://styles.refero.design/…
یک سایت خیلی جذاب و کاربردی پیدا کردم

این سایت کلی DESIGN.md آماده داره که کلی تمپلیت، سیستم طراحی، رنگ، تایپوگرافی و استایل آماده جمع کرده. می‌تونید از بینشون بگردید، ایده بگیرید و برای پروژه‌های خودتون استفاده کنید.

Alireza ✍️

https://www.aura.build/design-systems

@codehalics | کدهالیک
8
مهاجرت پر هزینه از rest به grpc

نویسنده تو این مقاله داستان مهاجرت تیمشون از REST به gRPC رو تعریف میکنه و میگه با اینکه سرعت و عملکردشون واقعا بهتر شد، اما یک سال تمام درگیر دردسرهایی شدن که تو REST اصلا وجود نداشت. مشکل اصلی این بود که gRPC داده‌ها رو به شکل باینری می‌فرسته و خوندن یا دیباگ کردنش برای برنامه‌نویس‌ها و ابزارهای مختلف سخته، در حالی که REST متن ساده است و به راحتی بررسی میشه. در نهایت به این نتیجه رسیدن که عددهای مربوط به بنچمارک سرعت همه چیز نیستن و راحتی کار، خوانایی و پشتیبانی جهانی REST تو کارهای روزمره خیلی بیشتر از سرعت بالای gRPC ارزش داره، مگر اینکه واقعا تو پروژه‌تون با مشکل جدی پرفورمنس روبرو باشین.

https://python.plainenglish.io/we-switched-from-rest-to-grpc-for-the-performance-got-it-and-then-spent-a-year-fighting-a6366edc9ca6

@codehalics | کدهالیک
👍8
کدهالیک | codehalic
مهاجرت پر هزینه از rest به grpc نویسنده تو این مقاله داستان مهاجرت تیمشون از REST به gRPC رو تعریف میکنه و میگه با اینکه سرعت و عملکردشون واقعا بهتر شد، اما یک سال تمام درگیر دردسرهایی شدن که تو REST اصلا وجود نداشت. مشکل اصلی این بود که gRPC داده‌ها رو…
یه مشکلی که من باهاش داشتم همیشه grpcurl بود چون شما عملا از curl عادی نمیتونی استفاده کنی باید این پکیج رو بری مثلا روی پاد هات نصب کنی که خودش دردسره !
تست و دیباگ با grpcurl واقعا می‌تونه روی اعصاب باشه و اصلا اون سادگی curl معمولی یا ابزارهایی مثل Postman رو نداره.

بزرگترین دردسرش وقتیه که قابلیت Reflection روی سرور gRPC غیرفعال باشه. تو محیط پروداکشن معمولا این قابلیت رو به خاطر امنیت می‌بندن و این یعنی grpcurl کلا کور میشه و نمی‌فهمه چه متدهایی وجود داره. برای اینکه بتونی یه ریکوئست ساده بزنی مجبوری تمام فایل‌های proto رو دستی به ابزار معرفی کنی. وقتی داری روی یه معماری مایکروسرویس کار می‌کنی که فایل‌های proto پر از وابستگی و importهای مختلف هستن، پیدا کردن و آدرس دادن دقیق این مسیرها برای یه تست ساده به شدت کلافه‌کننده میشه.

علاوه بر اینا، چون gRPC روی HTTP/2 کار می‌کنه و به شدت به گواهینامه‌های TLS وابسته‌ست، وقتی داری لوکال تست می‌کنی دائم با خطای SSL روبرو میشی و باید با اضافه کردن فلگ‌های مختلف سعی کنی ابزار رو مجبور کنی که به سرور لوکال بدون سرتیفیکیت معتبر وصل بشه. همه این اصطکاک‌های کوچیک باعث میشه کاری که تو معماری REST تو چند ثانیه انجام میشد، اینجا کلی وقت و انرژی ازت بگیره.

یه باگ دیگم ما داشتیم توی nginx این بود که ریکوست رو سمتش میفرستادیم بعد ریکوسته میرفت ولی تو حین مسیر nginx قطعش میکرد ! بعد ریکوسته رفته بود رسپانسم نداشتی :))))))))

هزینه نگهداریش برای تیم ما که تیم نسبتا کوچیکیه واقعا بالاست ! شاید برای تیم های خیلی بزرگتر خیلی منطقی بنظر برسه مثلا بلوبانک الان همه ریکوست های فرانتشم GRPC عه و خیلی خوب دارن اینکارو انجام میدن !

@codehalics | کدهالیک
👍5
تو شبکه‌های اجتماعی همه میگن با اومدن هوش مصنوعی دیگه نیازی به یادگیری برنامه‌نویسی نیست و دوره‌ی مصاحبه‌های فنی تموم شده اما آمارها نشون میدن که تعداد این مصاحبه‌ها تقریبا دو برابر شده و اتفاقا سخت‌تر هم شدن. شرکت‌های بزرگ و حتی خود سازنده‌های هوش مصنوعی الان بیشتر از قبل روی مفاهیم پایه‌ای و درک عمیق شما از حل مسئله تمرکز دارن چون مصاحبه هیچ وقت فقط درباره تایپ کردن کد نبوده بلکه درباره قدرت تصمیم‌گیری و فهمیدن معماری سیستم‌هاست. در واقع هوش مصنوعی فقط لایه پایین کار یعنی کدنویسی روتین رو انجام میده و حالا سطح توقع شرکت‌ها بالاتر رفته و از شما میخوان کدهای واقعی رو دیباگ کنید یا سوتی‌های کدهای تولید شده توسط هوش مصنوعی رو بگیرید. در نهایت مقاله میگه نه حرف اونایی که میگن فقط پرامپت نوشتن کافیه درسته و نه اونایی که کلا استفاده از هوش مصنوعی رو پس میزنن بلکه برنده تو این بازار کسیه که اصول مهندسی نرم افزار رو خیلی خوب و عمیق بلده و همزمان میتونه از ابزارهای هوش مصنوعی هوشمندانه کمک بگیره.

https://start.dev/blog/did-ai-kill-coding-interviews

@codehalics | کدهالیک
9
سایت آئورا (Aura) یه مجموعه از گرادینت‌های نرم و جذابه که با ترکیب لایه‌ایِ رنگ‌ها، حسی دقیقاً مثل تابش نورِ واقعی رو تداعی می‌کنه. این پس‌زمینه‌های فضاساز و شیک خیلی راحت پشت هر رابط کاربری قرار می‌گیرن تا بدون شلوغ کردن صفحه، یه جلوهٔ مدرن و زنده بهش بدن.

https://auragradients.vercel.app/

@codehalics | کدهالیک
6
Forwarded from کار باشه !
سلام دوستان
شرکت ما در حال استخدام یک نیروی کارآموز حضوری در تهران برای پوزیشن فرانت اند دولوپره
اگر با فریم ورک های
React/Next JS
کار کردید
رزومه هاتون رو برای این ایمیل بفرستید
amirzahedi0@gmail.com

#frontend


💬 @job_bashe | گروه کار باشه با دسته بندی شغلی
📢 @karbashe_ir | کانال کار باشه
‏یه مقایسه جالب بین کلاد کد و کدکس خوندم.
‏اومده سابسکریپشن های ۲۰ دلاری شون رو مقایسه کرده.
‏لیمیت هفتگی کدکس تقریبا اندازه لیمیت ۵ ساعته کلاده.

‏اگه به جای ساب بخوای از api هاشون استفاده کنی روی کدکس ۴۲ و روی کلاد ۱۲۰ برابر گرون‌تر در میاد!


https://www.reddit.com/r/ClaudeAI/s/IOnCeQdFQb

TripleM✍️

@codehalics | کدهالیک
🤯21
سیلو یه جایگزین کاملا مشابه برای MinIO هست که بعد از تغییر لایسنس اون، توسط کامیونیتی فورک و ایجاد شده. این پروژه که قبلا با اسم pgsty/minio شناخته میشد الان یه گزینه عالی برای ذخیره‌سازی S3 به حساب میاد و امکانات مهمی مثل پنل ادمین و داکیومنت‌ها رو دوباره برگردونده. اولین نسخه از این پروژه تو تاریخ ۶ آگوست ۲۰۲۶ منتشر شد و همونطور که تو هکرنیوز هم مطرح شده، کاملا آماده است تا به عنوان یه جانشین قوی، جای خالی MinIO رو برای کاربرا پر کنه.

پ.ن : نسخه جدید minio کلا لایسنسی شده و باید پول بابتش پرداخت کنین !

https://www.ssp.sh/brain/silo/

@codehalics | کدهالیک
8
This media is not supported in your browser
VIEW IN TELEGRAM
فیگما قابلیت جدیدی معرفی کرد که ساخت و استفاده از اسکیل‌ها را مستقیماً داخل محیط فیگما ممکن می‌کند. از این پس کاربران می‌توانند با استفاده از Figma Agent یک اسکیل جدید بسازند، آن را در بخش Community منتشر کنند و اسکیل‌های منتشر شده توسط دیگران را ذخیره کرده و با دستور «/» اجرا نمایند. این تغییر بخش قابل توجهی از فرآیندهای طراحی و اتوماسیون را به درون خود فیگما منتقل می‌کند.

@codehalics | کدهالیک
1👏1
تا حالا پیش اومده یه اپلیکیشن رو باز کنید و فقط به آیکون در حال چرخش لودینگ خیره بشید؟ این مشکل اعصاب خردکن معمولا به خاطر گیر کردن تو تله Request Waterfall به وجود میاد. یعنی یه درخواست برای گرفتن اطلاعات باید حتما صبر کنه تا درخواست قبلی تموم بشه و همین باعث کندی شدید میشه.

اما راه حل چیه؟ تو این مقاله یاد میگیریم چطور با ترکیب سه تا قابلیت عالی تو Next.js، یعنی React Suspense و Promise.all و Promise.allSettled، دیتاها رو به صورت موازی دریافت کنیم تا سرعت برنامه چند برابر بشه.

به طور خلاصه:

از Suspense استفاده میکنیم تا وقتی دیتا داره لود میشه، یه رابط کاربری موقت (مثل اسکلتون) نشون بدیم و صفحه سفید نمونه.

از Promise.all برای وقتایی استفاده میکنیم که همه دیتاها ضروری هستن و باید با هم لود بشن.

و از Promise.allSettled برای زمانی که میخوایم برنامه مقاوم باشه. یعنی حتی اگه یکی از API ها هم قطع بشه، کل برنامه از کار نمیفته و بقیه دیتاها به کاربر نشون داده میشن.

یه تیکه کد از این روش موازی رو اینجا ببینید:

const getSpellsPromise = fetch('https://api.example.com/spells').then(res => res.json());
const getBooksPromise = fetch('https://api.example.com/books').then(res => res.json());

// دریافت موازی اطلاعات بدون معطلی برای همدیگه
const [spellsResult, booksResult] = await Promise.allSettled([
getSpellsPromise,
getBooksPromise,
]);

با پیاده سازی این معماری، اپلیکیشن شما نه تنها خیلی سریع تر اجرا میشه، بلکه در برابر خطاهای سرور هم فوق العاده مقاوم تر عمل میکنه.

اگه میخواید با جزئیات دقیق تر این روش ها آشنا بشید و کدهای کاملش رو ببینید، پیشنهاد میکنم حتما ادامه این آموزش جذاب رو تو مدیوم بخونید:

https://medium.com/@fufudsby/mastering-parallel-data-fetching-in-next-js-5d5c30be26b3

@codehalics | کدهالیک
6🔥1
مقایسه بین SSE , وب سوکت و Long polling !

برای فرستادن دیتای ریل تایم از سرور به کلاینت کلا سه تا راه اصلی داریم: وب سوکت، اس اس ای (SSE) و لانگ پولینگ. حالا اومدیم ۱۰۰۰ تا ایونت رو تست زدیم ببینیم تو عمل کدوم بهتر جواب میده و هزینه واقعی هر کدوم تو لایه نتورک چقدره. برای اینکه دقیق متوجه بشیم، این ۱۰۰۰ تا ایونت ۱۱۷ بایتی رو تو شرایط کاملا یکسان با هر سه تا روش فرستادیم. نتیجه خیلی جالب بود.
در ادامه این سری پست ها به بررسی نتایج این آزمایش میپردازیم !

مقاله اصلی :
https://theinfinity.dev/articles/websocket-vs-sse-vs-polling


@codehalics | کدهالیک
3
کدهالیک | codehalic
مقایسه بین SSE , وب سوکت و Long polling ! برای فرستادن دیتای ریل تایم از سرور به کلاینت کلا سه تا راه اصلی داریم: وب سوکت، اس اس ای (SSE) و لانگ پولینگ. حالا اومدیم ۱۰۰۰ تا ایونت رو تست زدیم ببینیم تو عمل کدوم بهتر جواب میده و هزینه واقعی هر کدوم تو لایه…
مقایسه هزینه واقعی تو لایه نتورک

رو بستر وب سوکت این هزار تا ایونت کلا ۱۱۹ کیلوبایت ترافیک مصرف کرد. با اس اس ای این عدد شد ۱۳۱ کیلوبایت. اما لانگ پولینگ روی اچ تی تی پی وان (HTTP/1.1) یه فاجعه واقعی بود و ۸۸۴ کیلوبایت ترافیک ساخت. دلیل این اختلاف عجیب و غریب هم هدرهای ریکوئست‌های اچ تی تی پی هست. تو لانگ پولینگ حجم زیادی از هدرها و کوکی‌های سشن برای تک تک این هزار تا ایونت مدام ارسال میشن که فقط ۵۶۹ کیلوبایتش مربوط به همین هدرها بود.

@codehalics | کدهالیک
2
کدهالیک | codehalic
مقایسه بین SSE , وب سوکت و Long polling ! برای فرستادن دیتای ریل تایم از سرور به کلاینت کلا سه تا راه اصلی داریم: وب سوکت، اس اس ای (SSE) و لانگ پولینگ. حالا اومدیم ۱۰۰۰ تا ایونت رو تست زدیم ببینیم تو عمل کدوم بهتر جواب میده و هزینه واقعی هر کدوم تو لایه…
تاثیر پروتکل‌های جدید و تست سرعت

حالا دو تا سوال مهم پیش میاد. اول اینکه اگه بریم سمت اچ تی تی پی تو (HTTP/2) مشکل لانگ پولینگ حل میشه؟ دوم اینکه آیا وب سوکت تو واقعیت سریعتر پیام‌ها رو میرسونه؟

در مورد سوال اول باید بگم که اچ تی تی پی 2 با فشرده کردن هدرها حجم مصرفی لانگ پولینگ رو از ۸۸۴ به ۱۸۲ کیلوبایت میرسونه و اونو از یه انتخاب افتضاح به یه گزینه معمولی تبدیل میکنه. در مورد سرعت هم وقتی تو یه نتورک با دیلی ۵۰ میلی ثانیه تست کردیم، هر سه تا تکنولوژی پیام‌ها رو تو حدود ۲۶.۵ میلی ثانیه تحویل دادن و اختلافشون حتی به نیم میلی ثانیه هم نرسید. باگ لانگ پولینگ فقط اونجایی خودش رو نشون میده که سرعت تولید ایونت‌ها از زمان رفت و برگشت شبکه بیشتر باشه و پیام‌ها تو صف بمونن. از نظر مصرف مموری سرور هم هر سه تا روش تقریبا تو یه سطح هستن و باز نگه داشتن کانکشن‌ها فرق چندانی تو مصرف منابع سرور نداره.

@codehalics | کدهالیک
3
کدهالیک | codehalic
مقایسه بین SSE , وب سوکت و Long polling ! برای فرستادن دیتای ریل تایم از سرور به کلاینت کلا سه تا راه اصلی داریم: وب سوکت، اس اس ای (SSE) و لانگ پولینگ. حالا اومدیم ۱۰۰۰ تا ایونت رو تست زدیم ببینیم تو عمل کدوم بهتر جواب میده و هزینه واقعی هر کدوم تو لایه…
بالاخره کدوم رو انتخاب کنیم؟

خب با این تستایی که روی این ۱۰۰۰ تا ایونت زدیم، معماری نهایی رو چطور بچینیم؟ خیلی از تیم‌ها دیفالت میرن سراغ وب سوکت در حالی که همیشه بهترین گزینه نیست.

برای استریم دیتای یه طرفه از سرور به کلاینت، اس اس ای قطعا بهترین انتخابه.( مثل Chatgpt و هوش مصنوعی ها که باهاشون چت میکنین ) درسته که ۱۰ درصد بیشتر از وب سوکت ترافیک مصرف میکنه، اما در عوض قابلیت ریکانکت شدن خودکار رو تو خود مرورگر داره. یعنی دیگه نیازی نیست تو سمت کلاینت کلی کد پیچیده برای هندل کردن قطعی نتورک بنویسید. پس به عنوان یه قانون کلی، معماری سیستمتون رو بر پایه اس اس ای بچینید. فقط زمانی برید سراغ وب سوکت که سیستمتون نیاز داره دیتای ریل تایم با ریت بالا از کلاینت به سرور بفرسته یا اینکه دیتاتون باینری باشه. استفاده از وب سوکت برای یه فید یه طرفه فقط الکی سیستم رو پیچیده میکنه.


@codehalics | کدهالیک
3👍1
درایو C برای ویندوز دشمن خونیه، همیشه سعی میکنه پرش کنه حتی اگر شما چیزی نصب نکنی!
و نمیتونی خالیش کنی چون نمیدونی چی پرش کرده
ولی WinDirStat میتونه!
یه ابزار ساده که بهت نشون میده دقیقا چی پر کرده درایوت رو

Zeth

https://windirstat.net/download.html

@codehalics | کدهالیک
👍101
کدنویسی در سال ۲۰۲۶ :)))

@codehalics | کدهالیک
😁37
خیلی وقتا برای هماهنگ کردن تب‌های مرورگر (مثلا وقتی کاربر تو یه تب لاگ‌اوت میکنه یا سبد خریدش رو آپدیت میکنه) میایم سراغ هک localStorage. یعنی یه دیتا مینویسیم و فورا پاک میکنیم تا ایونت storage صدا زده بشه. این روش پر از دردسره، کدهای اضافه زیادی می‌طلبه و کلا از پایه برای این کار ساخته نشده.

راه‌حل نیتیو و اصولی چیه؟ استفاده از BroadcastChannel این API دقیقا برای ارتباط مستقیم بین تب‌ها ساخته شده. نه نیازی به JSON.stringify داره، نه لازم هست ایونت‌های اضافه رو فیلتر کنید و دیتای ساختاریافته رو خیلی راحت منتقل میکنه. فقط یه کانال با اسم مشخص باز میکنید و پیامتون رو می‌فرستید:

توی تب فرستنده:
const channel = new BroadcastChannel('app-sync');
channel.postMessage({ type: 'LOGOUT' });


توی تب‌های گیرنده:
const channel = new BroadcastChannel('app-sync');
channel.onmessage = (event) => {
console.log(event.data); // { type: 'LOGOUT' }
};


به همین راحتی و تمیزی! فقط یادتون باشه وقتی کارتون تموم شد channel.close() رو صدا بزنید تا ریسورس‌ها آزاد بشن.

@codehalics | کدهالیک
8🔥2
امروز یه مقاله خیلی خوب خوندم که نویسنده مقاله میگه وسط این بلبشوی هوش مصنوعی و توقعات فضایی مدیرها، بازخوانی کتاب ۲۷ ساله «اکستریم پروگرمینگ» کنت بک بدجور جواب میده. خیلیا فکر می‌کنن XP فقط یعنی پیر پروگرمنگ (کد زدن دونفره) و TDD، اما این کتاب ۲۶ تا روش عملی و ۵ تا ارزش کلیدی داره که دقیقاً درمان درد امروز ماست. الان که همه با ابزارهای AI پی‌آرهای غول‌آسا باز می‌کنن و کیفیت کد داره فدای سرعت میشه، اصول XP مثل سادگی، جلوگیری از معماری‌های پیچیده و بی‌خود، بازخورد سریع و احترام به وقت همدیگه یادمون میاره چطور کار کنیم. دلیل پیشنهاد این کتاب همینه که یاد بگیریم چطور وسط این سرعت دیوانه‌وار، کنترل کیفیت پروژه رو دستمون بگیریم و به عنوان یه مهندس زیر فشار ابزارها له نشیم.

لینک کتاب برای مطالعه :
https://refhub.ir/fa/refrence_detail/extreme-programming-explained-embrace-change/

لینک مقاله :
https://managerdotdev.beehiiv.com/p/extreme-programming-1999-2026

@codehalics | کدهالیک
👍31
کدهالیک | codehalic
XP
این لغت یعنی XP مخفف Extreme Programming هست. یه متدولوژی خیلی معروف تو توسعه نرم‌افزاره که همون کنت بک (نویسنده کتابی که تو مقاله بود) اواخر دهه نود معرفیش کرد.

ایده اصلیش خیلی سادس: میگه بیاین پرکتیس‌های خوب مهندسی نرم‌افزار رو بگیریم و تا بالاترین حد ممکن (همون اکستریم) اجراشون کنیم. مثلا اگه معتقدیم کد ریویو کار خوبیه، پس بیایم کلا دو نفری پای یه سیستم کد بزنیم که میشه همون پیر پروگرمینگ (Pair Programming). یا اگه تست کردن جوابه، پس اول تست رو بنویسیم و بعد کدش رو بزنیم (TDD).

هدف کلی XP اینه که با تکیه روی ارزش‌هایی مثل ارتباط مداوم تو تیم، سادگی تو معماری، و گرفتن فیدبک سریع، هم کیفیت خروجی بره بالا و هم تیم نرم‌افزاری بتونه خیلی راحت‌تر و با استرس کمتر با تغییرات کنار بیاد.

@codehalics | کدهالیک
3👍2
انگولار ۲۲ با کلی تغییرات اساسی منتشر شده که مهم‌ترینش استیبل شدن Signal Forms به عنوان یه جایگزین یکپارچه و قوی برای فرم‌های قبلیه. تو این آپدیت، استراتژی تشخیص تغییرات کامپوننت‌های جدید به صورت دیفالت روی OnPush تنظیم شده و علاوه بر اجباری شدن مهاجرت به تایپ‌اسکریپت ۶، ابزارهای جدیدی هم برای تزریق وابستگی اضافه شده. یه بخش خیلی هیجان‌انگیز این نسخه، پشتیبانی آزمایشی از WebMCP هست که به ایجنت‌های هوش مصنوعی اجازه میده به جای خوندن ظاهر صفحه، مستقیم از طریق یه پروتکل با اپلیکیشنی که در حال اجراست تعامل داشته باشن.

https://angular.dev/events/v22

@codehalics | کدهالیک
3👍1
یه نکته فرانتی خفن برای کسایی که خیلی از useMemo و React.memo استفاده میکنن

استفاده بی‌رویه از useMemo و React.memo بدون پروفایلینگ فقط هزینه‌ی نگهداری کد رو بالا می‌بره، چون ری‌رندر تو ری‌اکت صرفاً اجرا شدن مجدد تابع کامپوننت و ساخت ابجکت‌های جدید JSX هست و تا زمانی که فرآیند Commit و تغییرات فیزیکی DOM اتفاق نیفته، پردازش سنگینی محسوب نمیشه.

چرخه ری‌رندر کلاً سه تا تریگر داره: تغییر استیت داخلی، تغییر مقادیر context، یا دریافت ابجکت المنت جدید از والد؛ بنابراین تغییر Props به‌خودی‌خود تریگر نیست مگر اینکه کامپوننت با React.memo رپ شده باشه تا مقایسه سطحی یا Shallow Compare رو پراپس انجام بده.

برای حل مشکلات کارایی، بهینه‌سازی اول از اصلاح ساختار شروع میشه: پایین بردن محل قرارگیری استیت تا نزدیک‌ترین مصرف‌کننده و استفاده از الگوی ترکیب با children prop که باعث میشه ری‌اکت به دلیل یکسان بودن رفرنس ابجکت، کلاً فاز محاسبه زیردرخت رو Bypass کنه.

در نهایت اگه بعد از سنجش با ابزارهایی مثل Profiler یا React Scan محاسبه سنگینی دیدید، اونوقت تثبیت رفرنس با useMemo یا جداسازی با useDeferredValue معنا پیدا می‌کنه، چرا که حتی React Compiler هم فقط فرآیند ممیوایز کردن رفرنس‌های JSX رو خودکار می‌کنه و توانایی جابه‌جایی استیت یا اصلاح ساختار درخت کامپوننت رو نداره.

https://thetshaped.dev/p/react-rendering-demystified-your-usememo-probably-isnt-doing-anything

@codehalics | کدهالیک
👍5