🚀 ۵ ابزار مدرن فرانتاند که باید بشناسید (پارت دوم)
✨ shadcn/ui (خداحافظی با کامپوننتهای دستنویس):
شاد سیان کلی کامپوننت خوشساخت و زیبا داره که مستقیم میاد تو پروژهات. کار باهاش راحته و دیگه وقتت رو تلف نمیکنی.
📖 Storybook (خونهی امن کامپوننتها):
کامپوننتها رو وسط شلوغی پروژه نساز! بیارشون تو محیط ایزولهی استوریبوک تا راحت تستشون کنی و مثل یه کاتالوگ داشته باشی.
🔄 TanStack Query (خداحافظی با دردسرهای useEffect)
: سروکله زدن با useEffect تمام شد! تناستک همهچیز رو حل میکنه: گرفتن داده، کش کردن و آپدیت. مدیریت داده سرور دیگه یه رویاست.
🐻 Zustand (استیت منجمنت بیدردسر):
خسته شدی از پیچیدگی ابزارهای قدیمی؟ زاستند کوچیک، سریع و سادست و کارهای استیت کلاینت رو بیدردسر انجام میده.
🛡 Zod (دیوار دفاعی دادهها):
نذار دیتای خراب وارد اپلیکیشنت بشه! زود مثل نگهبان سختگیر مطمئن میشه ورودیها همون شکلیه که انتظار داری. امنیت دادهها در زمان اجرا.
مستندات رسمی :
shadcn_ui
storybook
TanStack_query
zustand
zod
#Labs_ModernFrontendTools_Part2
✨ shadcn/ui (خداحافظی با کامپوننتهای دستنویس):
شاد سیان کلی کامپوننت خوشساخت و زیبا داره که مستقیم میاد تو پروژهات. کار باهاش راحته و دیگه وقتت رو تلف نمیکنی.
📖 Storybook (خونهی امن کامپوننتها):
کامپوننتها رو وسط شلوغی پروژه نساز! بیارشون تو محیط ایزولهی استوریبوک تا راحت تستشون کنی و مثل یه کاتالوگ داشته باشی.
🔄 TanStack Query (خداحافظی با دردسرهای useEffect)
: سروکله زدن با useEffect تمام شد! تناستک همهچیز رو حل میکنه: گرفتن داده، کش کردن و آپدیت. مدیریت داده سرور دیگه یه رویاست.
🐻 Zustand (استیت منجمنت بیدردسر):
خسته شدی از پیچیدگی ابزارهای قدیمی؟ زاستند کوچیک، سریع و سادست و کارهای استیت کلاینت رو بیدردسر انجام میده.
🛡 Zod (دیوار دفاعی دادهها):
نذار دیتای خراب وارد اپلیکیشنت بشه! زود مثل نگهبان سختگیر مطمئن میشه ورودیها همون شکلیه که انتظار داری. امنیت دادهها در زمان اجرا.
مستندات رسمی :
shadcn_ui
storybook
TanStack_query
zustand
zod
#Labs_ModernFrontendTools_Part2
❤4🔥2
This media is not supported in your browser
VIEW IN TELEGRAM
قابل توجه وایب کدینگ ها 😁
پ.ن: آفکورس که بچههای Labs وایب کدر نیستن 😌
پ.ن: آفکورس که بچههای Labs وایب کدر نیستن 😌
git commit -m "Good night devs"
👌3👨💻1👀1
🚀 سری ۵ قسمتی معماری Next.js 🟢
پارت ۲ — Scale واقعا یعنی چی؟
وقتی میگیم یه پروژه قراره Scale بشه، خیلیا فکر میکنن ترافیک و سرور میافته. ولی تو فرانتاند، Scale یعنی یه چیز: رشدِ وحشتناکِ پیچیدگیِ کد (Complexity)
سایز پروژه، معماری رو تعیین میکنه :
🔹 پروژههای Small: یه لندینگ ساده. اینجا همون ریختن فایلها تو
🔹 پروژههای Medium: داشبورد، سبد خرید، سیستم Auth. اینجا لاجیک داره با UI گره میخوره. اگه اینجا مرزبندی نکنی، کمکم داری وارد باتلاق میشی.
🔹 پروژههای Enterprise: چند تیم همزمان، دهها فیچر. اینجا اگه معماری و لایهبندی دقیق نداشته باشی، با هر Pull Request که مِرج میشه، یه جای دیگه سایت میترکه!
اشتباه مهلک چیه؟ اینکه با ساختارِ یه سایت شخصی بخوای یه استارتاپ رو بالا بیاری، یا برعکس، یه معماری خفنِ سازمانی رو به زور بچپونی تو یه پروژه کوچیک.
👇 این قانون رو برای همیشه گوشه ذهنت پین کن :
ما تو برنامهنویسی چیزی به اسم «بهترین ساختارِ ثابت» نداریم؛ ما Context (شرایط و نیاز پروژه) داریم.
#Labs_fiveStepToMasterInNextArchitecture
پارت ۲ — Scale واقعا یعنی چی؟
وقتی میگیم یه پروژه قراره Scale بشه، خیلیا فکر میکنن ترافیک و سرور میافته. ولی تو فرانتاند، Scale یعنی یه چیز: رشدِ وحشتناکِ پیچیدگیِ کد (Complexity)
سایز پروژه، معماری رو تعیین میکنه :
🔹 پروژههای Small: یه لندینگ ساده. اینجا همون ریختن فایلها تو
app/ جوابه. الکی فولدرها رو تو در تو نکن (Over-engineering سَمه!). 🔹 پروژههای Medium: داشبورد، سبد خرید، سیستم Auth. اینجا لاجیک داره با UI گره میخوره. اگه اینجا مرزبندی نکنی، کمکم داری وارد باتلاق میشی.
🔹 پروژههای Enterprise: چند تیم همزمان، دهها فیچر. اینجا اگه معماری و لایهبندی دقیق نداشته باشی، با هر Pull Request که مِرج میشه، یه جای دیگه سایت میترکه!
اشتباه مهلک چیه؟ اینکه با ساختارِ یه سایت شخصی بخوای یه استارتاپ رو بالا بیاری، یا برعکس، یه معماری خفنِ سازمانی رو به زور بچپونی تو یه پروژه کوچیک.
👇 این قانون رو برای همیشه گوشه ذهنت پین کن :
ما تو برنامهنویسی چیزی به اسم «بهترین ساختارِ ثابت» نداریم؛ ما Context (شرایط و نیاز پروژه) داریم.
#Labs_fiveStepToMasterInNextArchitecture
❤3
به دلایلی شاید چند روز آینده نتونم مثل قبل فعالیت داشته باشم
توی این مدت خوشحال میشم پست هارو با دوستانتون به اشتراک بزارین ❤️🌹
توی این مدت خوشحال میشم پست هارو با دوستانتون به اشتراک بزارین ❤️🌹
❤3
توی کانال بله جوین بشین اونجا ادامه فعالیتمون رو خواهیم داشت در صورت قطعی❤️
https://ble.ir/foad_journey
https://ble.ir/foad_journey
Foad Labs
🚀 سری ۵ قسمتی معماری Next.js 🟢 پارت ۲ — Scale واقعا یعنی چی؟ وقتی میگیم یه پروژه قراره Scale بشه، خیلیا فکر میکنن ترافیک و سرور میافته. ولی تو فرانتاند، Scale یعنی یه چیز: رشدِ وحشتناکِ پیچیدگیِ کد (Complexity) سایز پروژه، معماری رو تعیین میکنه : …
🚀 سری ۵ قسمتی: معماری Next.js
🟡 پارت ۳ — معماری MVP (ساده اما خطرناک)
تو پارت قبل دیدیم که ساختار پروژه به سایز و نیازش بستگی داره. حالا بیایم سراغ محبوبترین و دمدستیترین مدل: یعنی همون ساختار پیشفرضِ Next.js بدون فولدربندی خاص. ساختاری که روز اول خیلی سریع بالا میاد، ولی به شدت شکنندهست!
چرا سادهترین ساختار، خطرناکترینه؟
سرعت روزهای اول این مدل خیرهکنندهست؛ همهچیز دم دسته و سریع کامپوننت میزنی. اما دقیقاً همینجا داری سنگینترین بدهی فنی (Technical Debt) رو بالا میاری.
💥 چرا پروژه با اولین رشد، منفجر میشه؟
کدها به هم جوش میخورن: لاجیک و UI انقدر تو هم گره میخورن که برای تغییرِ فرمتِ یک ریکوئست ساده، باید کل کامپوننت و کدهای ظاهر رو زیر و رو کنی.
تستناپذیر میشه: وقتی منطق بیزینس وسط تگهای HTML رها شده، نوشتن تست برای بخشهای مختلف پروژه رسماً غیرممکنه.
سرعتت منفی میشه: به جای توسعه فیچرهای جدید، کل وقت تیم صرف پیدا کردن باگهای عجیب و غریبی میشه که از تداخل کدها به وجود اومدن.
این ساختار مثل یه آلونک چوبیه؛ سریع سرپا میشه ولی اصلاً تحمل ساختنِ طبقهی دوم رو نداره و با اولین طوفان فرو میریزه.
👇 این واقعیت رو قبول کن:
"کدِ شلخته نوشتن به بهونه سرعت، مثل وام گرفتن با نزولِ سنگینه؛ اولش کارِت راه میفته، ولی جلوتر جریمهاش چرخ پروژهات رو پنچر میکنه!"
#Labs_fiveStepToMasterInNextArchitecture
🟡 پارت ۳ — معماری MVP (ساده اما خطرناک)
تو پارت قبل دیدیم که ساختار پروژه به سایز و نیازش بستگی داره. حالا بیایم سراغ محبوبترین و دمدستیترین مدل: یعنی همون ساختار پیشفرضِ Next.js بدون فولدربندی خاص. ساختاری که روز اول خیلی سریع بالا میاد، ولی به شدت شکنندهست!
چرا سادهترین ساختار، خطرناکترینه؟
سرعت روزهای اول این مدل خیرهکنندهست؛ همهچیز دم دسته و سریع کامپوننت میزنی. اما دقیقاً همینجا داری سنگینترین بدهی فنی (Technical Debt) رو بالا میاری.
💥 چرا پروژه با اولین رشد، منفجر میشه؟
کدها به هم جوش میخورن: لاجیک و UI انقدر تو هم گره میخورن که برای تغییرِ فرمتِ یک ریکوئست ساده، باید کل کامپوننت و کدهای ظاهر رو زیر و رو کنی.
تستناپذیر میشه: وقتی منطق بیزینس وسط تگهای HTML رها شده، نوشتن تست برای بخشهای مختلف پروژه رسماً غیرممکنه.
سرعتت منفی میشه: به جای توسعه فیچرهای جدید، کل وقت تیم صرف پیدا کردن باگهای عجیب و غریبی میشه که از تداخل کدها به وجود اومدن.
این ساختار مثل یه آلونک چوبیه؛ سریع سرپا میشه ولی اصلاً تحمل ساختنِ طبقهی دوم رو نداره و با اولین طوفان فرو میریزه.
👇 این واقعیت رو قبول کن:
"کدِ شلخته نوشتن به بهونه سرعت، مثل وام گرفتن با نزولِ سنگینه؛ اولش کارِت راه میفته، ولی جلوتر جریمهاش چرخ پروژهات رو پنچر میکنه!"
#Labs_fiveStepToMasterInNextArchitecture
از الان میتونین نظراتتون رو داخل کامنت های هر پست به اشتراک بزارین تا بتونیم باهم محتوا رو روز به روز بهتر کنیم ❤️
از فردا فعالیت به نسبت قبل بیشتر میشه
اگر محتوایی بود که دوست داشتین درموردش صحبت کنیم و پست بزاریم حتما توی این پیام بگین 🤝
اگر محتوایی بود که دوست داشتین درموردش صحبت کنیم و پست بزاریم حتما توی این پیام بگین 🤝
status: 🔴 Sleeping
❤2
صبح بخیر 👋
امروز هم قراره
یه چیز جدید یاد بگیرم،
یه چیز جدید بسازم
و یه چیز جدید با شما به اشتراک بذارم.
بزن بریم 🚀
امروز هم قراره
یه چیز جدید یاد بگیرم،
یه چیز جدید بسازم
و یه چیز جدید با شما به اشتراک بذارم.
بزن بریم 🚀
🔥1
اگر امروز میخواستم برنامهنویسی رو از صفر شروع کنم..
برخلاف چیزی که اکثر افراد فکر میکنن، اولین قدم یاد گرفتن JavaScript یا Python نبود.
اول یاد میگرفتم چطور یاد بگیرم ( وقتی یادش بگیری معجزه میکنه )
چون بزرگترین اشتباه تازهکارها اینه که میان با خودشون میگن خب امروز برم React رو یکم یاد بگیرم ، فردا هم که میریم لاراول و این چرخه بی انتها همینطوری ادامه پیدا میکنه ❌
و بعد از چند ماه آموزش دیدن یهو به خودت میای میبینی هیچ تخصصی نداری
اگر خودم قرار بود دوباره از صفر شروع کنم :
1️⃣ یک مسیر رو انتخاب میکردم.
2️⃣ هر روز حتی کم، ولی مداوم جلو میرفتم.
3️⃣ از هفته اول پروژه میساختم.
4️⃣ کمتر آموزش میدیدم، بیشتر تمرین میکردم.
برنامهنویسی مسابقه سرعت نیست؛ مسابقه ادامه دادنه.
📌 شما اگر امروز از صفر شروع میکردین، چه مسیری رو انتخاب میکردین؟
برخلاف چیزی که اکثر افراد فکر میکنن، اولین قدم یاد گرفتن JavaScript یا Python نبود.
اول یاد میگرفتم چطور یاد بگیرم ( وقتی یادش بگیری معجزه میکنه )
چون بزرگترین اشتباه تازهکارها اینه که میان با خودشون میگن خب امروز برم React رو یکم یاد بگیرم ، فردا هم که میریم لاراول و این چرخه بی انتها همینطوری ادامه پیدا میکنه ❌
و بعد از چند ماه آموزش دیدن یهو به خودت میای میبینی هیچ تخصصی نداری
اگر خودم قرار بود دوباره از صفر شروع کنم :
1️⃣ یک مسیر رو انتخاب میکردم.
2️⃣ هر روز حتی کم، ولی مداوم جلو میرفتم.
3️⃣ از هفته اول پروژه میساختم.
4️⃣ کمتر آموزش میدیدم، بیشتر تمرین میکردم.
برنامهنویسی مسابقه سرعت نیست؛ مسابقه ادامه دادنه.
📌 شما اگر امروز از صفر شروع میکردین، چه مسیری رو انتخاب میکردین؟
👍2
Foad Labs
🚀 سری ۵ قسمتی: معماری Next.js 🟡 پارت ۳ — معماری MVP (ساده اما خطرناک) تو پارت قبل دیدیم که ساختار پروژه به سایز و نیازش بستگی داره. حالا بیایم سراغ محبوبترین و دمدستیترین مدل: یعنی همون ساختار پیشفرضِ Next.js بدون فولدربندی خاص. ساختاری که روز اول خیلی…
🚀 سری ۵ قسمتی: Next.js Architecture Mastery
🟠 پارت ۴ — اولین تفکیک (UI vs Logic)
تا اینجا دیدیم معماری بد چطور پروژه رو فلج میکنه. حالا وقتشه اولین و مهمترین قدم رو برای نجات پروژه برداریم :
جدا کردن ظاهر (UI) از منطق (Logic).
Components vs Services
بزرگترین اشتباه اینه که ما میایم توی کامپوننت خودمون (مثلا فرم ثبتنام) کاری میکنیم که کامپوننت مستقیما بدونه دیتا چطوری فچ میشه یا به کدوم API ریکوئست میزنه.
کامپوننت باید "کودن" (Dumb) باشه! یعنی فقط وظیفه داره پراپس یا دیتا رو بگیره و ظاهر رو نشون بده. منطق کار (مثل کال کردن API) باید بره تو یه لایه ی دیگه، مثلا فولدری به اسم
استارت ذهنیت لایه بندی
با این کار، به جای یه فایل شلوغ که همهچیز توشه، دوتا فایل تمیز داری :
که فقط کارش گرفتن دیتای کاربر از API هست.
که فقط دیتایی که از سرویس گرفته رو خوشگل نشون میده.
چرا این کار واجبه؟
قابلیت استفاده مجدد : اگه یه جای دیگه پروژه هم دیتای کاربر رو خواستی، فقط سرویس رو صدا میزنی، نه اینکه دوباره کد فچ بنویسی.
نگهداری راحتتر : اگه آدرس API عوض شد، فقط یه فایل (سرویس) رو ادیت میکنی، نه ۱۰ تا کامپوننت رو!
👇 برای امروز اینو یادت باشه هربار که میخای یه کامپوننت بسازی :
کامپوننتهای تو نبایدباهوش باشن
اونا فقط باید خوشگل دیتارو نشون بدن!
#Labs_fiveStepToMasterInNextArchitecture
🟠 پارت ۴ — اولین تفکیک (UI vs Logic)
تا اینجا دیدیم معماری بد چطور پروژه رو فلج میکنه. حالا وقتشه اولین و مهمترین قدم رو برای نجات پروژه برداریم :
جدا کردن ظاهر (UI) از منطق (Logic).
Components vs Services
بزرگترین اشتباه اینه که ما میایم توی کامپوننت خودمون (مثلا فرم ثبتنام) کاری میکنیم که کامپوننت مستقیما بدونه دیتا چطوری فچ میشه یا به کدوم API ریکوئست میزنه.
کامپوننت باید "کودن" (Dumb) باشه! یعنی فقط وظیفه داره پراپس یا دیتا رو بگیره و ظاهر رو نشون بده. منطق کار (مثل کال کردن API) باید بره تو یه لایه ی دیگه، مثلا فولدری به اسم
services/ یا lib/.استارت ذهنیت لایه بندی
با این کار، به جای یه فایل شلوغ که همهچیز توشه، دوتا فایل تمیز داری :
UserService.ts:که فقط کارش گرفتن دیتای کاربر از API هست.
UserProfile.tsx: که فقط دیتایی که از سرویس گرفته رو خوشگل نشون میده.
چرا این کار واجبه؟
قابلیت استفاده مجدد : اگه یه جای دیگه پروژه هم دیتای کاربر رو خواستی، فقط سرویس رو صدا میزنی، نه اینکه دوباره کد فچ بنویسی.
نگهداری راحتتر : اگه آدرس API عوض شد، فقط یه فایل (سرویس) رو ادیت میکنی، نه ۱۰ تا کامپوننت رو!
👇 برای امروز اینو یادت باشه هربار که میخای یه کامپوننت بسازی :
کامپوننتهای تو نباید
اونا فقط باید خوشگل دیتارو نشون بدن!
#Labs_fiveStepToMasterInNextArchitecture
❤1👌1