نوشته های حسین نظری

مقایسه‌های همراه با تبدیل نوع در جاوااسکریپت (Coercive Comparisons)

حسین نظری — Sun, 03 May 2026 16:50:26 +0330

تبدیل نوع (coercion) به این معناست که یک مقدار از یک نوع، به نمایش متناظر خود در نوعی دیگر تبدیل شود (تا جایی که امکان‌پذیر باشد). همان‌طور که در فصل ۴ بررسی خواهیم کرد، coercion یکی از ستون‌های اصلی زبان JS است، نه یک ویژگی اختیاری که بتوان به‌راحتی از آن اجتناب کرد.اما جایی که coercion با عملگرهای مقایسه (مثل برابری) ترکیب می‌شود، معمولاً باعث سردرگمی و نارضایتی می‌شود.کمتر ویژگی‌ای در JS به اندازه عملگر == (که معمولاً «برابری سست» یا loose equality نامیده می‌شود) در جامعه JS مورد انتقاد قرار گرفته است. بیشتر مطالب و بحث‌های عمومی درباره JS این عملگر را بدطراحی‌شده و خطرناک/مستعد باگ می‌دانند. حتی خالق زبان، Brendan Eich، نیز از طراحی آن به‌عنوان یک اشتباه بزرگ یاد کرده است.تا جایی که می‌توانم تشخیص دهم، بیشتر این نارضایتی‌ها از تعداد نسبتاً کمی از موارد خاص گیج‌کننده ناشی می‌شود، اما مشکل عمیق‌تر، یک سوءبرداشت بسیار رایج است: این‌که == بدون در نظر گرفتن نوع (type) مقادیر، مقایسه انجام می‌دهد.عملگر == مقایسه برابری را تقریباً مشابه === انجام می‌دهد. در واقع، هر دو عملگر نوع مقادیر را در نظر می‌گیرند. و اگر دو مقدار از یک نوع باشند، == و === دقیقاً یک کار را انجام می‌دهند و هیچ تفاوتی ندارند.اگر نوع مقادیر متفاوت باشد، تفاوت == با === این است که == اجازه می‌دهد قبل از مقایسه، تبدیل نوع انجام شود. به عبارت دیگر، هر دو عملگر می‌خواهند مقادیری با نوع یکسان را مقایسه کنند، اما == ابتدا اجازه تبدیل نوع می‌دهد و پس از یکسان شدن نوع‌ها، همانند === عمل می‌کند. بنابراین، به‌جای «برابری سست»، بهتر است == را "برابری همراه با تبدیل نوع (coercive equality) "بنامیم.42 == "42"; // true 1 == true; // trueدر هر دو مقایسه، نوع مقادیر متفاوت است، بنابراین == باعث می‌شود مقادیر غیرعددی ("42" و true) به عدد تبدیل شوند (به‌ترتیب 42 و 1) و سپس مقایسه انجام شود.فقط با آگاهی از این ویژگی ==—این‌که تمایل دارد مقایسه‌ها را به‌صورت عددی انجام دهد—می‌توانید از بیشتر موارد مشکل‌ساز اجتناب کنید، مثلاً دوری از مواردی مثل "" == 0 یا 0 == false.ممکن است فکر کنید: «خب، من همیشه از === استفاده می‌کنم تا از این مشکلات دور بمانم!» اما واقعیت این است که این کار به آن سادگی که فکر می‌کنید نیست.به احتمال زیاد از عملگرهای مقایسه‌ای مانند < و > (و حتی <= و >=) استفاده خواهید کرد.این عملگرها نیز مانند == عمل می‌کنند: اگر نوع مقادیر یکسان باشد، رفتار «سخت‌گیرانه» دارند، اما اگر نوع‌ها متفاوت باشند، ابتدا coercion انجام می‌دهند (معمولاً به عدد) و سپس مقایسه می‌کنند.مثال:var arr = [ "1", "10", "100", "1000" ]; for (let i = 0; i < arr.length && arr[i] < 500; i++) { // will run 3 times }مقایسه i < arr.length از coercion در امان است، چون هر دو مقدار همیشه عدد هستند. اما arr[i] < 500 شامل coercion می‌شود، چون مقادیر arr[i] همگی رشته هستند. بنابراین این مقایسه‌ها به این شکل تبدیل می‌شوند: 1 < 500، 10 < 500، 100 < 500 و 1000 < 500. از آنجا که مورد چهارم false است، حلقه بعد از سه بار اجرا متوقف می‌شود.این عملگرهای مقایسه‌ای معمولاً از مقایسه عددی استفاده می‌کنند، مگر زمانی که هر دو مقدار رشته باشند؛ در این صورت، از مقایسه الفبایی (مانند ترتیب لغت‌نامه‌ای) استفاده می‌کنند:var x = "10"; var y = "9"; x < y; // true, مراقب باشید!هیچ راهی وجود ندارد که این عملگرها را مجبور کنید از coercion اجتناب کنند، مگر این‌که همیشه مقادیر هم‌نوع را با هم مقایسه کنید. این هدف خوبی است، اما در عمل احتمال زیادی دارد با مواردی مواجه شوید که نوع‌ها متفاوت باشند.رویکرد عاقلانه‌تر این نیست که از مقایسه‌های همراه با تبدیل نوع اجتناب کنید، بلکه باید آن‌ها را بپذیرید و جزئیاتشان را یاد بگیرید.مقایسه‌های همراه با coercion در بخش‌های دیگری از JS نیز ظاهر می‌شوند، مانند دستورات شرطی (if و غیره)

تفاوت Options API و Composition API

حسین نظری — Thu, 04 Dec 2025 12:09:22 +0330

Composition API VS Options APIانتخاب بین Composition API و Options API در Vue.js — کدام مناسب‌تر است؟Vue.js در دوره‌های مختلف خود دو سبک اصلی برای نوشتن کامپوننت‌ها پیشنهاد کرده: Options API (سبک قدیمی‌تر) و Composition API (سبک نوتر و مدرن‌تر). هر کدام نقاط قوت و ضعف خود را دارند — انتخاب بین آن‌ها بستگی دارد به نیاز پروژه، مقیاس آن، و سبک کاری تیم توسعه. در ادامه با زبانی ساده این دو را مقایسه می‌کنم تا خودت راحت‌تر تصمیم بگیری.Options API کلاسیک، ساده و ساختارمندبیشتر کسانی که با Vue از ابتدا کار کرده‌اند، با Options API آشنا هستند. این سبک، منطق کامپوننت را بر اساس «نوع» کد — مثلاً data، methods، computed، watch و … — تقسیم می‌کند. چنین ساختاری مزایایی دارد:سادگی و یادگیری آسان: برای پروژه‌های کوچک یا زمانی که تازه با Vue آشنا می‌شوی، Options API ساده و سرراست است — کافی است بدانی داده‌ها کجا هستند، متدها کجا، محاسبه‌شده‌ها کجا و …قابلیت درک سریع ساختار: وقتی وارد یک کامپوننت می‌شوی، می‌دانی داده‌ها، متدها، computed و watcherها هر کدام در کجای فایل هستند — همین امر خصوصاً برای تازه‌کارها کمک بزرگی است.مناسب برای پروژه‌های ساده یا نمونه‌های اولیه: اگر کامپوننت ساده‌ای می‌سازی، نیازی به پیچیدگی نیست؛ Options API دقیقاً همان چیزی است که لازم داری.اما این سادگی با یک هزینه همراه است، به‌خصوص هر چقدر کامپوننت یا پروژه بزرگ‌تر شود:تکه تکه شدن منطقLogic Fragmentation): وقتی منطق‌های مختلف (state، متد، محاسبه، واکنش به تغییرات و…) مربوط به یک Feature خاص باشند، Options API آن‌ها را بر اساس نوع جدا می‌کند، نه بر اساس ویژگی. نتیجه: برای دنبال کردن منطق یک قابلیت (feature) باید بین بخش‌های مختلف اسکرول کنی.مشکلات در اشتراک‌گذاری منطق (Code reuse): اگر بخواهی منطق مشترکی در چند کامپوننت به کار ببری، معمولاً به mixinها یا HOC (higher-order components) متوسل می‌شوی. این راه‌حل‌ها گریزگاه دارند — گاهی وابستگی‌ها نامشخص‌اند، گاهی ترکیب mixin ها مشکل می‌شود، و نگهداری کد دشوار می‌شود.در نتیجه: Options API مناسب است وقتی پروژه ساده است، یا وقتی می‌خواهی خیلی سریع شروع کنی — اما وقتی پروژه پیچیده‌تر شود، نقطه ضعف‌هایش آشکار می‌شوند. Composition API — مدرن، انعطاف‌پذیر و مقیاس‌پذیرComposition API در Vue 3 معرفی شد تا راهی جدید برای نوشتن کامپوننت‌ها فراهم کند — راهی که به جای تقسیم کد بر اساس نوع، اجازه می‌دهد منطق مرتبط با یک ویژگی (feature) را با هم گروه بندی کنی. فواید اصلی آن: • سازماندهی منطقی و ماژولار (Modular + Logical Organization)با Composition API می‌توان بخش‌هایی از منطق که به هم مرتبط‌اند — state، computed، متدها، واکنش به تغییرات، lifecycle hooks — را در یک تابع یا ماژول جداگانه (composable) قرار داد. این باعث می‌شود کد خواناتر و مرتب‌تر باشد، و موقع توسعه یا دیباگ کردن راحت‌تر بفهمی چه کاری در کجاست. • قابلیت استفادهٔ مجدد بهتر (Reusability)ماژول‌هایی که منطق مشخصی دارند می‌توانند دوباره در چند کامپوننت یا حتی پروژه‌های مختلف استفاده شوند — بدون اینکه مجبور باشی همه چیز را از نو بنویسی. برخلاف mixinها، composableها شفاف و مستقل‌اند؛ وابستگی‌ها مشخص‌اند و خطر تداخل کمتر است. • پشتیبانی بهتر از TypeScript و روان‌تر شدن در کار با TSاگر با TypeScript کار می‌کنی، Composition API مزیت بزرگ دارد: type inference بهتر، کد تمیزتر و کم‌تر نیاز به تعریف دستی تایپ‌ها. ضمن اینکه Syntax آن تا حد زیادی مشابه JavaScript ساده است و یادگیری آن سخت نمی‌شود. • بهینه‌تر شدن باندل و عملکرد (Performance / Bundle size)با استفاده از ترکیب Composition API و ویژگی‌هایی مثل