Foad Labs

70 سوال مصاحبه ای جاوااسکریپت همراه با توضیح منبع | #JavaScript ✦ @ArchiveDevs

جای همگی دوستان خالی

آقا دریغ نکنین از این چالش

تیم یاشار چالشی به اسم Terraria برای استعدادیابی کلاس Takopi Hunters طراحی کردن و شرکت برای عموم آزاده و چالش 31 مرحله داره با حل 30 مرحله اول ، پلیر وارد قرعه کشی حضور تو کلاس تاکوپی میشه و در صورتی که هرکسی بتونه مرحله Bonus (یعنی مرحله 31) رو حل کنه شانسش تو قرعه کشی سه برابر میشه. افرادی که موفق به تکمیل چالش بشن ، در پایان اطلاعات اون ها جهت ثبت نام تو Talent List رو دریافت میکنن. چالش الان بالاست و میتونید شانستون رو امتحان کنید https://terraria.pwnbox-lab.com/ https://x.com/voorivex/status/2078193618939007034?s=20

🛡 Error Boundary آخرین خط دفاعی حتی اگه همه جا error handle کنین یه جایی یه خطای پیش‌بینی‌نشده میاد و کل صفحه crash میکنه Error Boundary دقیقا برای همینه — یه کامپوننت که خطاهای runtime رو میگیره و به‌جای crash، یه UI جایگزین نشون میده ⭕️ ( عکس ضمیمه شده ) ⚠️ یه نکته مهم : Error Boundary فقط خطاهای render-time رو میگیره — خطاهای داخل event handler و async function رو نمیگیره. اونا رو باید دستی handle کنین منبع رسمی : Error Boundary

یه چیزی که توی اکثر پروژه‌ها میبینم error handling اصلا وجود نداره — یا اگه هست، اینشکلیه : try { const data = await fetchUser(id); setUser(data); } catch (e) { console.log(e); // 👈 و تموم } کاربر یه صفحه سفید میبینه، هیچکس نمیدونه چی شد، و debug کردن کابوس میشه اول باید error type ها رو از هم جدا کنین => ⭕️ ( عکس ضمیمه شده اول ) حالا توی fetch wrapper اینا رو handle میکنیم ⭕️ ( عکس ضمیمه شده دوم ) و توی کامپوننت، هر نوع خطا رو جداگانه handle میکنیم => ⭕️ ( عکس ضمیمه شده سوم ) کاربر همیشه میدونه چی شده — نه صفحه سفید، نه پیام عمومی بی‌معنی. منبع رسمی : Using_Fetch

🌿 Branch naming یه چیز کوچیک که کار تیم رو راحت میکنه وقتی توی یه تیم کار میکنین و ۱۰ تا 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 بیشتر.

🔀 یه چیزی که توی اکثر تیم‌ها غلط انجام میشه : همه روی برنچ 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

📝 Commit message خوب چطوریه؟ اگه توی 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

🔴 چالش شب — Next.js 🟠 چالش اصلاح میشه

🗣 یک باور غلط بین برنامه‌نویس‌ها: وردپرس کلا داغونه و نمیشه بهینه‌ش کرد! امروز توی گروه این جمله رو شنیدم که کدهای وردپرس از ریشه غیربهینه‌ست و برنامه‌نویسای غیر وردپرسی اصلا حاضر نیستن روش کار کنن! خواستم چند تا نکته رو دوستانه باهاتون در میون بذارم : ✅ اول از همه : وردپرس قرار نیست یک فریمورک مینیمال مثل Laravel باشه. وردپرس یک پلتفرمه که باید نیازهای ۴۳٪ از کل وب‌سایت‌های دنیا رو با هزاران افزونه مختلف برآورده کنه. این یعنی سربار (Overhead) بخشی از ذاتشه، نه ضعف کدنویسی! ✅ دوم : بهینه‌سازی وردپرس اصلا به معنی دستکاری کدهای core اون نیست هنر یک وردپرس‌کار حرفه‌ای اینه که بدونه چطور با کشینگ (Redis)، بهینه‌سازی دیتابیس و معماری درست، سایتی رو بالا بیاره که از هر سایت کاستومی سریع‌تر باشه. ✅ سوم : بله، ممکنه خیلی از برنامه‌نویس‌ها حوصله سروکله زدن با Hookها و ساختار قدیمی وردپرس رو نداشته باشن و این حقشونه. اما اینکه بگیم کدهاش از ریشه داغونه انصاف فنی نیست. هسته وردپرس مدام در حال آپدیت، تطبیق با PHP 8+ و استفاده از React در ادیتوره. 🎯 خلاصه کلام : ابزارها رو نباید با هم مقایسه کرد. شما با پیچ‌ گوشتی نمیتونی میخ بکوبی وردپرس برای سرعت توسعه، اکوسیستم عظیم و مدیریت محتوا بی‌نظیره. اگر جایی کندیه، معمولا مشکل از نحوه پیاده‌سازی ماست، نه خود ابزار. شما چطور؟ تا حالا شده به خاطر ساختار وردپرس کلافه بشین یا برعکس، از سرعت توسعه‌اش شگفت‌زده بشین برامون بنویسید.

تارگت 100 مون زده شد

فقط کافیه به چیزایی که بهتون توصیه میکنه ابزار لایت‌هوس و قوانین سخت گیرانه گوگل آشنا باشین به همین راحتی میتونین سایت خودتون و هر پروژه ای که دارین رو بهتر کنین

فقط کافیه به چیزایی که بهتون توصیه میکنه ابزار لایت‌هوس و قوانین سخت گیرانه گوگل آشنا باشین به همین راحتی میتونین سایت خودتون و هر پروژه ای که دارین رو بهتر کنین

🔴 چالش شب — Next.js 🟠 چالش اصلاح میشه

🔴 چالش شب — Next.js 🟠 چالش اصلاح میشه