سلام دوستان. میخوایم قسمت سوم از مجموعه پستهای سوالات مصاحبه فرانتاند رو بررسی کنیم. از فرم بالا استفاده کنین تا در جریان قسمتهای جدید قرار بگیرین. توی این قسمت میخوایم با ۱۰ سوال زیر آشنا بشیم:
ابتدا یک تعریف از Tree-shaking داشته باشیم. Tree-shaking به عملیات حذف کردن کدهای اضافی و بلااستفاده توسط باندلر هنگام باندل کردن گفته میشه.
توی هر برنامهای همیشه یک سری کدها (مثل توابع) وجود داره که هیچوقت استفاده نمیشن و بنابراین حضور اونها توی باندل نهایی نتیجهای جز افزایش سایز باندل نداره. بنابراین با حذف کردن اونها میتونیم سایز باندل رو کاهش بدیم تا سرعت و عملکرد برنامه بهتره بشه. اما چه کدهایی کاندیدای حذف شدن هستن؟ باندلر چهجوری تشخیص میده که چه کدی رو باید حذف کنه و چه کدی رو نه؟
قوانینی وجود داره که اگه اونها رو رعایت نکنیم، باعث میشه باندلر نتونه Tree-shaking انجام بده:
۱. Import کردن همهٔ ماژول
وقتی برای استفاده از قسمتی از یک ماژول، همهٔ اون رو Import میکنیم، باندلر نمیتونه قسمتهای بلااستفادهٔ اون رو حذف کنه:
import * as utils form 'module';
utils.add(2, 5);
توی کد خط ۱ ما داریم همهٔ ماژول رو Import میکنیم. اینجا باندلر نمیتونه تشخیص بده که ما به کدوم عضو احتیاج داریم. بنابراین همهٔ اعضای اون ماژول توی باندل نهایی حضور دارن؛ حتی اگه فقط یک عضو از اون آبجکت رو فراخونی کنیم. پس بهتره فقط اعضایی رو Import کنیم که بهشون احتیاج داریم:
import { add } form 'module';
add(2, 5);
۲. Import کردن ماژول به صورت Dynamic
وقتی از Dynamic Import برای Import کردن ماژولها استفاده میکنیم، باندلر نمیتونه تشخیص بده که کدوم عضو ماژول قراره استفاده بشه. بنابراین همهٔ اعضای این ماژول توی باندل نهایی حضور دارن. پس اگه Tree-shaking برامون مهمتر هست، باید از روش Static Import (روش بالا) استفاده کنیم.
۳. استفاده از ماژول-سیستمهایی غیر از ES Modules
وقتی باندلر با ماژولهایی مواجه میشه که به روشی غیر از ES Modules مثل Common JS یا AMD استفاده شدن، این امکان وجود داره که نتونه بدرستی Tree shaking انجام بده. چنین ماژولهایی برخلاف ماژولهای ES، ساختار و رفتار Dynamic (مثل مورد بالا) دارن و بنابراین کار رو برای باندلر برای پیدا کردن کد بلااستفاده سخت میکنن.
۴. ماژولی که Side Effect داره
اگه توی یک ماژول اعضایی داریم که Side Effect دارن، باندلر نمیتونه تصمیم بگیره کدوم عضو کاندیدای حذف از باندل هست. برای مثال توی این ماژول یک Side Effect داریم:
export const greet = (name) => {
return "Hello";
};
console.log("This is a side effect");
هر چند بعضی از باندلرها با تکنیکهایی میتونن ساید افکت رو تشخیص بدن و Tree Shaking انجام بدن، داشتن ماژولی که ساید افکت داره نقضکنندهٔ برنامهنویسی ماژولار هست.
کاربرد این اتریبیوت بیشتر برای مبحث Accessibility و افرادی که از استفاده میکنن هست. توی هر صفحهای ممکنه المنتهایی داشته باشیم که وقتی توسط یک ابزار کمکی مثل پردازش میشن، هیچ اطلاعاتی رو به کاربر منتقل نمیکنن. بنابراین کاربر ممکنه نتونه به درستی هدف اون المنت رو متوجه بشه. مثلاً آیکنی که به این صورت لینک شده:
Screen Reader وقتی با این المنت مواجه میشه، نمیتونه اطلاعات مناسبی دربارهٔ وظیفهٔ این المنت به کاربر منتقل کنه که در نتیجه Accessibility و کاربردپذیری اون صفحه پایین میاد. کاربرد aria-label اینجا مشخص میشه. با استفاده از این اتریبیوت میتونیم کاربرد چنین المنتهایی رو برای ابزارهای کمکی مشخص کنیم:
<a href="/next" <<aria-label>>="Go to the next page">
<svg class="icon"> ... </svg>
</a>
توی کد بالا با توضیحاتی که برای مقدار aria-label نوشتیم، ابزارهای کمکی میتونن منظور و هدف این المنت رو به کاربرها منتقل کنن. این اتریبیوت کاربرد مشابهی با تگ label که فقط برای Input های فرم استفاده میشه داره.
معمولاً توی صفحههای وب برای هر عکس ورژن و سایزهای متفاوتی وجود داره و ما گاهی اوقات میخوایم هنگام طراحی صفحههای Responsive بر اساس سایزهای مختلف صفحه سایز متفاوتی از عکس رو نمایش بدیم. تگ <picture> این امکان رو میده که بر اساس شرایط مختلف، عکس متفاوتی نمایش بدیم تا از هدر رفت منابع و پهنایباند جلوگیری بشه:
توی این تگ برای هر ورژن از تصویر یک تگ source قرار میدیم و مشخص میکنیم که این تصویر توی چه شرایطی باید نمایش داده بشه. انتهای اون هم یک تگ img هم میذاریم که زمانی نمایش داده میشه که هیچکدوم از شرایط برقرار نباشه. مرورگر به صورت خودکار تصمیم میگیره که کدوم از تصاویر باید دانلود و نمایش داده بشه.
اگه مشغول توسعهٔ نرمافزاری هستیم و این توسعه به یک نقطهٔ خاص و قابل توجهی رسیده، با استفاده از دستور git tag میتونیم برای آخرین کامیت یک اسم و برچسب بامعنا در نظر بگیریم؛ با این هدف که این کامیت نقطهٔ مهمی برای ما هست. با این کار میتونیم به شکل راحتتری مراحل مهم برنامهمون رو شناسایی و پیدا کنیم. بدون این ویژگی باید توی انبوهی از Hash ها دنبال کامیت مد نظر باشیم. بنابراین، git tag یک اسم بامعنا برای یک Hash کامیت بیمعنا مثل abcdef12 هست.
دستور git pull در واقع ترکیبی از دو دستور git fetch و git merge هست. یعنی وقتی git pull رو اجرا میکنیم، در واقع داریم اون دو دستور رو اجرا میکنیم. دستور git fetch برای گرفتن آخرین تغییرات (کامیتها، برنچها و تگها) از سرور استفاده میشه. وقتی این دستور رو میزنیم، اطلاعات دریافت میشن اما Merge صورت نمیگیره و بنابراین کدهایی که داریم روی اونها کار میکنیم تحت تاثیر قرار نمیگیرن. پس برای مرج شدن باید بعد از Fetch به صورت دستی از git merge استفاده کنیم. استفاده از دستور git fetch برای زمانی مناسب هست که میخوایم قبل از مرج شدن تغییرات رو بررسی کنیم.
توی وب از زمانی که مرورگر شروع میکنه به دریافت اطلاعات وبسایت و تا زمانی که صفحه به طور کامل آمادهٔ تعامل بشه، رویدادهای مختلفی رخ میده. این دو رویداد با اینکه شبیه به هم هستن، کاربردهای منحصر به فرد خودشون رو دارن:
رویداد DOMContentLoaded
این رویداد زمانی رخ میده که مرورگر به طور کامل HTML رو دریافت کرده و ساختار اون و آبجکت DOM رو به طور ساخته باشه. توی این مرحله میتونیم با DOM تعامل داشته باشیم و اون رو دستکاری کنیم. باید دقت کنیم که رخ دادن این رویداد وابسته به این نیست که ریسورسهایی مثل تصاویر، اسکریپتها و استایلهای خارجی حتماً لود شده باشن. بنابراین این رویداد تضمین نمیکنه که صفحه به طور کامل آمادهٔ تعامل باشه. نحوهٔ استفاده از این رویداد به این صورت هست:
document.addEventListener('DOMContentLoaded', (event) => {
// DOM is ready and accessible
// Manipulate DOM elements
});
رویداد load
این رویداد زمانی رخ میده که DOM بهطور کامل ساخته شده باشه و اطلاعات صفحه از جمله ریسورسهای خارجی همگی لود و پردازش شده باشن و کاربر آمادهٔ تعامل با صفحه باشه. نحوهٔ استفاده از رویداد load به این صورت هست:
window.addEventListener('load', (event) => {
// Page and its resources are ready
});
مطمئن بشیم که محتوای دکمهها و لینکها یکتا و با معنا هستن. برای مثال لینکی که متن اون «جزییات بیشتر درباره محصول XYZ» هست، مفهوم و معنای بهتری در مقایسه با متن «جزییات بیشتر» داره و کمتر باعث سردرگمی میشه
از اتریبـیـوت lang روی تگ <html> صفحه استفاده کنیم تا برای مرورگر و ابزارهای کمکی زبان مد نظر رو مشخص کنیم
از اتریبـیـوت title روی المنتها به منظور پیادهسازی Tooltip استفاده نکنیم. به دلیل اینکه این اتریبـیـوت برای کاربران موبایلی، کاربران وابسته به Screen reader و یا هنگام استفاده از کیبورد کارایی خاصی ندارن
این فایل یک جای اختصاصی برای نوشتن Type Declaration هست. همونطور که میدونیم، میشه Type Declaration ها رو بهصورت Inline توی فایلهای تایپاسکریپت (.ts) هم نوشت. اما اگه تعداد Type Declaration ها زیاد بشه بهتره اونها رو منتقل کنیم به یک فایل مجزا. چنین کاری توی تایپاسکریپت با ساختن فایل .d.ts انجام میگیره. توی این فایل فقط میتونیم Type Declaration بنویسیم و کدهای دیگهای از تایپاسکریپت معتبر نیستن.
همونطور که میدونیم REST یک معماری مبتنی بر HTTP و شامل قوانینی هست برای ساختن وبسرویسها. و یک برنامهٔ RESTful به برنامهای گفته میشه که از این قوانین تبعیت میکنه. یکی از قوانین برنامهٔ رِستفول اینه که هر درخواستی که از کلاینت به سمت سرور زده میشه، باید توی خودش همهٔ اطلاعاتی که سرور برای دادنِ پاسخ مناسب لازم داره رو داشته باشه. به عبارت دیگه، هر درخواست باید کاملاً مستقل از درخواستهای دیگه عمل کنه و سرور برای فهمیدن یک درخواست نباید وابسته به درخواستهای دیگه باشه.
وابستگی درخواستها زمانی به وجود میاد که سرور اطلاعاتی از یک درخواست رو ذخیره کرده تا برای درخواستهای بعدی از اون استفاده کنه و اینجاست که قانون Stateless بودن نقض میشه. برای مثال توی یک برنامهای که میخواد از قوانین رست تبعیت کنه میخوایم نظر ارسال کنیم. اینجا هر درخواست توی خودش علاوه بر متن نظر، باید اطلاعات مربوط به شناسایی و احراز هویت کاربر (مثلاً توکن JWT) رو همیشه به همراه داشته باشه. توی این برنامه قانون رست زمانی نقض میشه که سرور اطلاعات مربوط به احراز هویت رو (مثلاً به وسیلهٔ قابلیت Session ها) توی خودش ذخیره کنه تا برای درخواستهای بعدی دیگه نیازی به ارسال اطلاعات احراز هویت نباشه.
State چیه؟ 🤔
منظور از State اطلاعاتی هست که توی برنامه در جریانه. مثل اطلاعات کاربری، تم، زبان و ... .
خب دوستان این قسمت هم به پایان رسید. کانال تلگرام دیتی رو دنبال کنین تا در جریان قسمتهای بعدی قرار بگیرین. روزتون خوش 😉🌹
