⏱️ صفحمون TTFB بالای 2 ثانیه داشت اما Streaming SSR رو حل کرد
❗️ مشکل اینجا بود که صفحه منتظر میموند تا همه دیتاها از سه تا endpoint جدا برگردن، بعد HTML رو میفرستاد. کاربر تا اون موقع فقط یه صفحه سفید میدید.
این رو بهش میگن waterfall مشکلدار :
درخواست کاربر
کاربر ۲.۸ ثانیه صبر میکنه تا اولین pixel ببینه.
🟢 راهحل : هر کامپوننت داده خودش رو مستقل fetch کنه (عکس ضمیمه شده)
الان timeline اینشکلیه :
درخواست کاربر
کاربر بعد از ۳۰۰ms یه صفحه معنادار میبینه، نه ۲.۸ ثانیه صفحه سفید، تفاوت رو دیدین ؟
⚠️ یه نکته مهم :
loading.tsx توی Next.js fallback کل route رو مدیریت میکنه، ولی Suspense بهتون کنترل دقیقتر میده — میتونید بخشهای مختلف یه صفحه رو جداگانه هندل کنین
منبع رسمی :
Fetching Data#Streaming
Granular streaming with Suspense
Streaming
❗️ مشکل اینجا بود که صفحه منتظر میموند تا همه دیتاها از سه تا endpoint جدا برگردن، بعد HTML رو میفرستاد. کاربر تا اون موقع فقط یه صفحه سفید میدید.
این رو بهش میگن waterfall مشکلدار :
درخواست کاربر
↓ fetchUser() → 300ms
↓ fetchPosts() → 500ms
↓ fetchComments() → 2000ms 😬
↓ HTML آماده میشه و میره سمت کاربر
کاربر ۲.۸ ثانیه صبر میکنه تا اولین pixel ببینه.
🟢 راهحل : هر کامپوننت داده خودش رو مستقل fetch کنه (عکس ضمیمه شده)
الان timeline اینشکلیه :
درخواست کاربر
↓ همه fetchها موازی شروع میشن
↓ UserCard → 300ms ✅ فوری نمایش
↓ Posts → 500ms ✅ skeleton، بعد محتوا
↓ Comments → 2000ms ✅ skeleton، بعد محتوا
کاربر بعد از ۳۰۰ms یه صفحه معنادار میبینه، نه ۲.۸ ثانیه صفحه سفید، تفاوت رو دیدین ؟
⚠️ یه نکته مهم :
loading.tsx توی Next.js fallback کل route رو مدیریت میکنه، ولی Suspense بهتون کنترل دقیقتر میده — میتونید بخشهای مختلف یه صفحه رو جداگانه هندل کنین
منبع رسمی :
Fetching Data#Streaming
Granular streaming with Suspense
Streaming
❤2
Foad Labs
🔴 چالش شب — Next.js 🟠 چالش اصلاح میشه
من معذرت میخام دوستان کانتکست چالش اشتباه گذاشته شده
اصلاح شدش رو براتون میزارم امشب و تا فردا مثل همیشه نظراتتون رو بگین و شرکت کنین توی چالش ❤️
اصلاح شدش رو براتون میزارم امشب و تا فردا مثل همیشه نظراتتون رو بگین و شرکت کنین توی چالش ❤️
❤1
🗣 یک باور غلط بین برنامهنویسها: وردپرس کلا داغونه و نمیشه بهینهش کرد!
امروز توی گروه این جمله رو شنیدم که کدهای وردپرس از ریشه غیربهینهست و برنامهنویسای غیر وردپرسی اصلا حاضر نیستن روش کار کنن!
خواستم چند تا نکته رو دوستانه باهاتون در میون بذارم :
✅ اول از همه : وردپرس قرار نیست یک فریمورک مینیمال مثل Laravel باشه. وردپرس یک پلتفرمه که باید نیازهای ۴۳٪ از کل وبسایتهای دنیا رو با هزاران افزونه مختلف برآورده کنه. این یعنی سربار (Overhead) بخشی از ذاتشه، نه ضعف کدنویسی!
✅ دوم : بهینهسازی وردپرس اصلا به معنی دستکاری کدهای core اون نیست هنر یک وردپرسکار حرفهای اینه که بدونه چطور با کشینگ (Redis)، بهینهسازی دیتابیس و معماری درست، سایتی رو بالا بیاره که از هر سایت کاستومی سریعتر باشه.
✅ سوم : بله، ممکنه خیلی از برنامهنویسها حوصله سروکله زدن با Hookها و ساختار قدیمی وردپرس رو نداشته باشن و این حقشونه. اما اینکه بگیم کدهاش از ریشه داغونه انصاف فنی نیست. هسته وردپرس مدام در حال آپدیت، تطبیق با PHP 8+ و استفاده از React در ادیتوره.
🎯 خلاصه کلام : ابزارها رو نباید با هم مقایسه کرد. شما با پیچ گوشتی نمیتونی میخ بکوبی
وردپرس برای سرعت توسعه، اکوسیستم عظیم و مدیریت محتوا بینظیره. اگر جایی کندیه، معمولا مشکل از نحوه پیادهسازی ماست، نه خود ابزار.
شما چطور؟ تا حالا شده به خاطر ساختار وردپرس کلافه بشین یا برعکس، از سرعت توسعهاش شگفتزده بشین برامون بنویسید.
امروز توی گروه این جمله رو شنیدم که کدهای وردپرس از ریشه غیربهینهست و برنامهنویسای غیر وردپرسی اصلا حاضر نیستن روش کار کنن!
خواستم چند تا نکته رو دوستانه باهاتون در میون بذارم :
✅ اول از همه : وردپرس قرار نیست یک فریمورک مینیمال مثل Laravel باشه. وردپرس یک پلتفرمه که باید نیازهای ۴۳٪ از کل وبسایتهای دنیا رو با هزاران افزونه مختلف برآورده کنه. این یعنی سربار (Overhead) بخشی از ذاتشه، نه ضعف کدنویسی!
✅ دوم : بهینهسازی وردپرس اصلا به معنی دستکاری کدهای core اون نیست هنر یک وردپرسکار حرفهای اینه که بدونه چطور با کشینگ (Redis)، بهینهسازی دیتابیس و معماری درست، سایتی رو بالا بیاره که از هر سایت کاستومی سریعتر باشه.
✅ سوم : بله، ممکنه خیلی از برنامهنویسها حوصله سروکله زدن با Hookها و ساختار قدیمی وردپرس رو نداشته باشن و این حقشونه. اما اینکه بگیم کدهاش از ریشه داغونه انصاف فنی نیست. هسته وردپرس مدام در حال آپدیت، تطبیق با PHP 8+ و استفاده از React در ادیتوره.
🎯 خلاصه کلام : ابزارها رو نباید با هم مقایسه کرد. شما با پیچ گوشتی نمیتونی میخ بکوبی
وردپرس برای سرعت توسعه، اکوسیستم عظیم و مدیریت محتوا بینظیره. اگر جایی کندیه، معمولا مشکل از نحوه پیادهسازی ماست، نه خود ابزار.
شما چطور؟ تا حالا شده به خاطر ساختار وردپرس کلافه بشین یا برعکس، از سرعت توسعهاش شگفتزده بشین برامون بنویسید.
👍1
Foad Labs
🔴 چالش شب — Next.js 🟠 چالش اصلاح میشه
🔴 چالش امروز — Next.js
کد توی تصویر ضمیمه شده رو ببینین
❓سوال : توی این کد چند تا UserCard رندر میشه و کدوماشون Server Component هستن؟
⚠️ قبل از جواب دادن، این سه گزینه رو در نظر بگیرین
الف) هر دو Server Component هستن
ب) اولی Server، دومی Client میشه چون داخل یه Client Component ایمپورت شده
ج) هر دو Client Component میشن
جوابتون همراه با چرا و همینطور راهحلتون رو بگین
کد توی تصویر ضمیمه شده رو ببینین
❓سوال : توی این کد چند تا UserCard رندر میشه و کدوماشون Server Component هستن؟
⚠️ قبل از جواب دادن، این سه گزینه رو در نظر بگیرین
الف) هر دو Server Component هستن
ب) اولی Server، دومی Client میشه چون داخل یه Client Component ایمپورت شده
ج) هر دو Client Component میشن
جوابتون همراه با چرا و همینطور راهحلتون رو بگین
📝 Commit message
خوب چطوریه؟
اگه توی git log خودتون این رو میبینین
fix bug
update
asdf
final version
FINAL version 2
بدونین که پخت و پز کردین ولی نه به سبک خفنش 😁😐
💥 Conventional Commits
یه استاندارد سادست که خوندن تاریخچه رو راحت میکنه :
👍🏻 تایپ های رایجی که میتونین استفاده کنین =>
feat → feature جدید
fix → رفع باگ
refactor → بازنویسی بدون تغییر رفتار
perf → بهینهسازی
chore → کارهای جانبی (deps, config)
👇🏻 یه قانون ساده برای نوشتن description :
جمله رو با فعل امری شروع کنین — نه "added login" بلکه "add login". انگار دارید به کد دستور میدید چیکار کنه.
منبع رسمی :
Conventional Commits
خوب چطوریه؟
اگه توی git log خودتون این رو میبینین
fix bug
update
asdf
final version
FINAL version 2
بدونین که پخت و پز کردین ولی نه به سبک خفنش 😁😐
💥 Conventional Commits
یه استاندارد سادست که خوندن تاریخچه رو راحت میکنه :
# ساختار
<type>(<scope>): <description>
# مثالهای واقعی
feat(auth): add Google OAuth login
fix(cart): prevent duplicate items on fast click
refactor(api): extract fetch logic to custom hook
perf(images): enable lazy loading for product gallery
docs(readme): update local setup instructions
chore(deps): upgrade React to v19
👍🏻 تایپ های رایجی که میتونین استفاده کنین =>
feat → feature جدید
fix → رفع باگ
refactor → بازنویسی بدون تغییر رفتار
perf → بهینهسازی
chore → کارهای جانبی (deps, config)
👇🏻 یه قانون ساده برای نوشتن description :
جمله رو با فعل امری شروع کنین — نه "added login" بلکه "add login". انگار دارید به کد دستور میدید چیکار کنه.
منبع رسمی :
Conventional Commits
🔀 یه چیزی که توی اکثر تیمها غلط انجام میشه :
همه روی برنچ main کار میکنن
یه نفر یه چیزی push میکنه، نفر بعدی conflict میگیره، یه ساعت وقت تلف میشه برای چیزی که اصلا نباید اتفاق میفتاد
یه workflow ساده که این مشکل رو حل میکنه :
چرا rebase بهجای merge؟
history
تمیز یعنی git log خوندنی، git bisect کارآمد، و debug سریعتر.
منبع رسمی :
git
همه روی برنچ main کار میکنن
یه نفر یه چیزی push میکنه، نفر بعدی conflict میگیره، یه ساعت وقت تلف میشه برای چیزی که اصلا نباید اتفاق میفتاد
یه workflow ساده که این مشکل رو حل میکنه :
# ۱. برای هر feature یه branch جدا
git checkout -b feature/user-authentication
# ۲. commitهای کوچیک و معنادار
git commit -m "feat: add login form validation"
git commit -m "feat: integrate auth API"
git commit -m "fix: handle expired token error"
# ۳. قبل از PR، rebase کنید نه merge
git fetch origin
git rebase origin/main
چرا rebase بهجای merge؟
# ❌ merge — تاریخچه پاک میشه
git merge main
# نتیجه: یه merge commit اضافه + تاریخچه غیرخطی
# ✅ rebase — تاریخچه تمیز میمونه
git rebase origin/main
# نتیجه: انگار از همین لحظه branch زدید
history
تمیز یعنی git log خوندنی، git bisect کارآمد، و debug سریعتر.
منبع رسمی :
git
❤1
🌿 Branch naming
یه چیز کوچیک که کار تیم رو راحت میکنه
وقتی توی یه تیم کار میکنین و ۱۰ تا branch دارید، اگه اسمگذاری استاندارد نباشه :
هیچکس نمیدونه این برنچها هرکدوم دقیقا برای چی هستن
یه convention ساده :
یه قدم جلوتر — شماره تیکت رو هم اضافه کنین :
حالا هر کسی branch رو میبینه، میدونه کجا باید بره برای context بیشتر.
یه چیز کوچیک که کار تیم رو راحت میکنه
وقتی توی یه تیم کار میکنین و ۱۰ تا branch دارید، اگه اسمگذاری استاندارد نباشه :
git branch
# خروجی:
foad-changes
new-feature
fix
test2
modal-thing-foad
هیچکس نمیدونه این برنچها هرکدوم دقیقا برای چی هستن
یه convention ساده :
# feature جدید
feature/user-profile-page
feature/add-payment-gateway
# رفع باگ
fix/cart-total-calculation
fix/mobile-nav-overflow
# بهینهسازی
perf/optimize-image-loading
# hotfix روی production
hotfix/critical-auth-bypass
یه قدم جلوتر — شماره تیکت رو هم اضافه کنین :
feature/AUTH-142-google-oauth
fix/CART-89-duplicate-items
حالا هر کسی branch رو میبینه، میدونه کجا باید بره برای context بیشتر.
❤1
یه چیزی که توی اکثر پروژهها میبینم error handling اصلا وجود نداره — یا اگه هست، اینشکلیه :
کاربر یه صفحه سفید میبینه، هیچکس نمیدونه چی شد، و debug کردن کابوس میشه
اول باید error type ها رو از هم جدا کنین =>
⭕️ ( عکس ضمیمه شده اول )
حالا توی fetch wrapper اینا رو handle میکنیم
⭕️ ( عکس ضمیمه شده دوم )
و توی کامپوننت، هر نوع خطا رو جداگانه handle میکنیم =>
⭕️ ( عکس ضمیمه شده سوم )
کاربر همیشه میدونه چی شده — نه صفحه سفید، نه پیام عمومی بیمعنی.
منبع رسمی :
Using_Fetch
try {
const data = await fetchUser(id);
setUser(data);
} catch (e) {
console.log(e); // 👈 و تموم
}کاربر یه صفحه سفید میبینه، هیچکس نمیدونه چی شد، و debug کردن کابوس میشه
اول باید error type ها رو از هم جدا کنین =>
⭕️ ( عکس ضمیمه شده اول )
حالا توی fetch wrapper اینا رو handle میکنیم
⭕️ ( عکس ضمیمه شده دوم )
و توی کامپوننت، هر نوع خطا رو جداگانه handle میکنیم =>
⭕️ ( عکس ضمیمه شده سوم )
کاربر همیشه میدونه چی شده — نه صفحه سفید، نه پیام عمومی بیمعنی.
منبع رسمی :
Using_Fetch
🛡 Error Boundary
آخرین خط دفاعی
حتی اگه همه جا error handle کنین یه جایی یه خطای پیشبینینشده میاد و کل صفحه crash میکنه
Error Boundary دقیقا برای همینه — یه کامپوننت که خطاهای runtime رو میگیره و بهجای crash، یه UI جایگزین نشون میده
⭕️ ( عکس ضمیمه شده )
⚠️ یه نکته مهم : Error Boundary فقط خطاهای render-time رو میگیره — خطاهای داخل event handler و async function رو نمیگیره. اونا رو باید دستی handle کنین
منبع رسمی :
Error Boundary
آخرین خط دفاعی
حتی اگه همه جا error handle کنین یه جایی یه خطای پیشبینینشده میاد و کل صفحه crash میکنه
Error Boundary دقیقا برای همینه — یه کامپوننت که خطاهای runtime رو میگیره و بهجای crash، یه UI جایگزین نشون میده
⭕️ ( عکس ضمیمه شده )
⚠️ یه نکته مهم : Error Boundary فقط خطاهای render-time رو میگیره — خطاهای داخل event handler و async function رو نمیگیره. اونا رو باید دستی handle کنین
منبع رسمی :
Error Boundary
Forwarded from Code Mates (Emmad🌵)
تیم یاشار چالشی به اسم Terraria برای استعدادیابی کلاس Takopi Hunters طراحی کردن و شرکت برای عموم آزاده و چالش 31 مرحله داره با حل 30 مرحله اول ، پلیر وارد قرعه کشی حضور تو کلاس تاکوپی میشه و در صورتی که هرکسی بتونه مرحله Bonus (یعنی مرحله 31) رو حل کنه شانسش تو قرعه کشی سه برابر میشه. افرادی که موفق به تکمیل چالش بشن ، در پایان اطلاعات اون ها جهت ثبت نام تو Talent List رو دریافت میکنن.
چالش الان بالاست و میتونید شانستون رو امتحان کنید
https://terraria.pwnbox-lab.com/
https://x.com/voorivex/status/2078193618939007034?s=20
چالش الان بالاست و میتونید شانستون رو امتحان کنید
https://terraria.pwnbox-lab.com/
https://x.com/voorivex/status/2078193618939007034?s=20
X (formerly Twitter)
یاشو (@voorivex) on X
پیکار استعدادیابی Terraria رفت بالا، اگه تو امنیت «صفر مطلقین» کافیه پیکار رو باز کنین، یه AI (پولی یا رایگان) بندازین کنار دستتون و کلی چیز یاد بگیرین. محوریت پیکار کاملا آموزشیه و سعی کردیم مفاهیم امنیت رو به سادهترین شکل ممکن طراحی کنیم:
https://t.co/wxNLApFkmY
https://t.co/wxNLApFkmY
👌1