<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"><channel><title>نوشته های مهدی فلاحتی</title><link>https://virgool.ir/feed/@falahati.mahdi</link><description></description><language>fa</language><pubDate>2026-11-11 09:56:33</pubDate><image><url>https://files.virgool.ir/upload/users/1536024/avatar/863B0B.jpg</url><title>مهدی فلاحتی</title><link>https://virgool.ir/@falahati.mahdi</link></image><item><title>چرا باید از ESLint استفاده کنیم و چندتا rule مهم</title><link>https://virgool.ir/@falahati.mahdi/چرا-باید-از-eslint-استفاده-کنیم-و-چندتا-rule-مهم-fb6eg7osqiaz</link><description>استفاده از ESLint توی پروژه‌های جاوااسکریپتی، مخصوصاً پروژه‌های تیمی، عملاً به یه استاندارد تبدیل شده.از اونجایی که میدونید جاوااسکریپت خیلی ساختار خاصی نداره و کلا با همه چی اوکی هست 😅هدف این بوده که اگه یه تیکه کد توی یه صفحه وب مشکل داشت، کل صفحه سفید نشه یا کرش نکنه و کاربر بتونه همچنان با سایت کار کنه. برای همین مثلاً اگه عدد رو با رشته جمع کنید، به جای اینکه مثل زبان‌های C# یا Java همون اول خطا بده، سعی می‌کنه خودش یه جوری تبدیلش کنه (Type Coercion) و ادامه بده. اما همین مورد باعث شد جاوااسکریپت، توی پروژه‌های بزرگ تبدیل به منبع اصلی باگ‌های عجیب و غریب بشه 😁»مثلا فرض کنید خواستید یه عدد رو با یه رشته جمع کنید؛ اگه قرار بود جاوااسکریپت همونخط اول خطا بده، کل سایت بالا نمیومد 😁TypeScript جلوی بخش زیادی از خطاهای مربوط به نوع داده رو می‌گیره، اما ESLint همچنان برای enforce کردن الگوهای درست و جلوگیری از اشتباهات منطقی نیازه.تو این پست قصد ندارم در مورد نصب و این موارد صحبت کنم چون به صورت پیش فرض معمولا موقع نصب react و یا next ، پکیج های مرتبط به lint هم نصب میشه.۱- no-implicit-coercion و prefer-templateاین دو Rule جزو مهم‌ترین مواردی هستن که جلوی خیلی از باگ‌های ریز و درشت، مخصوصاً در کار با رشته‌ها و تبدیل نوع‌ها رو می‌گیرن.no-implicit-coercion اجازه نمی‌ده که با عملیات عجیب‌وغریب، نوع داده‌ها رو به‌صورت غیرمستقیم عوض کنیم.prefer-template هم ما رو مجبور می‌کنه به‌جای استفاده از + برای ساخت رشته، از Template Literal استفاده کنیم.// ❌ استفاده از + برای ترکیب رشته‌ها&#xA;const firstName = &#34;mahdi&#34;;&#xA;const lastName = &#34;falahati&#34;;&#xA;const fullName = firstName + &#34; &#34; + lastName;  // هر دو رشته هستند&#xA;const greeting = &#34;سلام &#34; + firstName;         // هر دو رشته هستند&#xA;&#xA;// ✅ روش بهتر:&#xA;const fullName = `${firstName} ${lastName}`;&#xA;const greeting = `سلام ${firstName}`;&#xA;&#xA;// ❌تبدیل به رشته&#xA;const age = 25;&#xA;const ageString = age + &#34;&#34;;        // ❌ تبدیل عدد به رشته&#xA;const ageString = &#34;&#34; + age;        // ❌ تبدیل عدد به رشته&#xA;&#xA;// ✅ تبدیل صریح&#xA;const ageString = String(age);     // ✅ واضح و خوانا&#xA;const ageString = age.toString();  // ✅ یا این روش&#xA;&#xA;// ❌ ترکیب عدد و رشته&#xA;const userId = 123;&#xA;const message = &#34;User ID: &#34; + userId + &#34;&#34;;  // &#34;&#34; اضافی و بی‌معنی&#xA;&#xA;// ✅  &#xA;const userId = 123;&#xA;const message2 = `User ID: ${userId}`;      // روش بهتر&#xA;&#39;no-implicit-coercion&#39;: [&#39;error&#39;, {&#xA;  boolean: true,    // Disallow !!value&#xA;  number: true,     // Disallow +value or value * 1&#xA;  string: true,     // Disallow value + &#34;&#34;&#xA;  disallowTemplateShorthand: false // Allow ${value} for string coercion&#xA;}],&#xA;&#xA;&#34;prefer-template&#34;: &#34;error&#34;۲- Code Formatting Rules (بهتر است به Prettier سپرده شود)یکی از مهم‌ترین چالش‌ها در کار تیمی، یکدست بودن فرمت کدهاست.اگر هر توسعه‌دهنده به کد فرمت خودش بنویسه، نتیجه میشه Diffهای شلوغ، Code Review سخت و کاهش خوانایی کد.&#34;rules&#34;: {   &#xA;  &#34;object-curly-spacing&#34;: [&#34;error&#34;, &#34;always&#34;],  &#xA;  &#34;key-spacing&#34;: [&#34;error&#34;, { &#34;afterColon&#34;: true }], &#xA;  &#34;keyword-spacing&#34;: [&#34;error&#34;, { &#34;before&#34;: true, &#34;after&#34;: true }]&#xA; }یک سری rule هایی هست برای code formatting ولی بهتره این مورد بسپاریم به prettier.معمولاً با کمک eslint-config-prettier تمام قوانین فرمت‌بندی ESLint غیرفعال می‌شوند تا از تداخل بین این دو ابزار جلوگیری شود.برای مثال، قوانینی مانند فاصله بین کلید و مقدار آبجکت‌ها یا فاصله قبل و بعد از کلمات کلیدی (if، else، try و …) به‌صورت کامل توسط Prettier مدیریت می‌شوند و نیازی به تعریف آن‌ها در ESLint نیست.در مورد محدودیت طول خطوط (max-len) نیز معمولاً پیشنهاد می‌شود به‌جای استفاده از ESLint، از تنظیم printWidth در Prettier استفاده شود. با این کار، شکستن خطوط به‌شکل هوشمند و یکنواخت انجام می‌شود و از ایجاد اختلاف بین ابزارها و ادیتورهای مختلف جلوگیری خواهد شد.&#34;rules&#34;: {&#xA;  &#34;max-len&#34;: [&#34;error&#34;, { &#xA;    &#34;code&#34;: 100,&#xA;    &#34;ignoreUrls&#34;: true,&#xA;    &#34;ignoreStrings&#34;: true,&#xA;    &#34;ignoreTemplateLiterals&#34;: true,&#xA;    &#34;ignoreRegExpLiterals&#34;: true&#xA;  }] &#xA;}با استفاده از این rule میتونیم تعداد کاراکترهای مجاز در هر خط محدود کنیم ولی همون طور که گفته شد بهتره این موارد بسپاریم به Prettierنتیجه نهایی برای این بخش : ترکیب صحیح Prettier برای فرمت کد و ESLint برای بررسی کیفیت و منطق کد باعث می‌شه:کدهای تیم یکدست باشندDiff فایل‌ها در Git تمیزتر و خواناتر شوندCode Review ساده تر باشهاختلافی بین خروجی VS Code، WebStorm و... وجود نداشته باشه۳- Logic &amp; Best Practices Rulesدر بخش قبلی در مورد چند rule برای یکدست شدن کدها صحبت کردیم، در این قسمت چندتا rule مهم برای تمیزتر شدن کدها و همچنین باگ کمتری پیش بیاد.اولین مورد eqeqeq هست.// ❌ باگ‌های عجیب ناشی از استفاده از ==&#xA;if (0 == false) {&#xA;  console.log(&#34;چرا اجرا شدی؟!&#34;);&#xA;}&#xA;if (&#34;1&#34; == 1) {&#xA;   // اینم اجرا میشه چون رشته &#34;1&#34; تبدیل به عدد میشه 😐&#xA;}&#xA;&#xA;// ✅ روش درست با ===&#xA;if (0 === false) {&#xA;  // اجرا نمیشه، چون عدد 0 با بولین false یکی نیست&#xA;}&#xA;== معمولاً به‌خاطر تغییر خودکار نوع‌ها نتیجه‌های عجیب می‌ده، برای همین حتما باید از === استفاده بشه.TypeScript هم تا حد زیادی جلوی این اشتباه‌ها رو می‌گیره، ولی اساسا جلوی اینکه == استفاده کنیم نمیگیره یه مثال که تایپ اسکریپت جلوش نمیگیره.const value = &#39;test&#39; as unknown as number;&#xA;&#xA;if (value == 5) {}اینجا TS فکر می‌کنه value یه عدد هست، ولی در زمان اجرا همچنان یه رشته‌ست و == می‌تونه رفتار غیرمنتظره ایجاد کنه.هرچند احتمال داشتن چنین cast‌ هایی کم به‌نظر می‌رسه، ولی خب… در جاوااسکریپت هیچ‌چیزی بعید نیست 😅مورد بعدی no console هستبه نظرم rule مهمی هست خیلی وقت ها احتمالش وجود داره که یک console log گذاشته باشیم و فراموش شده باشه پاکش کنیم چه‌بسا که یک سری اطلاعات مهم هم داخلش باشه 🥲&#34;no-console&#34;: [&#34;error&#34;, { &#34;allow&#34;: [&#34;warn&#34;, &#34;error&#34;] }]البته بعضی موارد پیش میاد که نیاز هست یک console warn یا error استفاده کنیم با این روش میتونیم اجازه استفاده بدیم.و مورد آخر no-unused-varsخیلی وقت‌ها پیش میاد یک متغیر یا یک تابع تعریف کنیم اما فراموش کنیم ازش استفاده کنیم، یا موقع Refactor کردن دیگه لازمش نداریم و همون‌طور توی کد بمونه.برای همینESLintبا این Rule جلوش رو می‌گیره:&#34;no-unused-vars&#34;: [&#34;error&#34;, {&#xA;  &#34;vars&#34;: &#34;all&#34;,&#xA;  &#34;args&#34;: &#34;none&#34;,&#xA;  &#34;ignoreRestSiblings&#34;: true&#xA;}]&#xA;به این شکل:هر متغیر، تابع یا importی که استفاده نشه → خطا ❌روی آرگومان‌های تابع سخت‌گیر نیست (برای جلوگیری از خطاهای الکی)در destructuring هم باعث مزاحمت نمی‌شه✔️ مثال برای args: &#34;none&#34;// مثال رایج در map&#xA;items.map((item, index) =&gt; {&#xA;  return item.name;  //index is not used, but with args: &#34;none&#34; it&#39;s not a problem&#xA;});✔️ مثال برای ignoreRestSiblings: trueوقتی از Rest استفاده می‌کنیم تا بقیه پراپرتی‌ها رو جدا کنیم، اما اون متغیرهای اولیه (Siblingها) رو لازم نداریم و بلااستفاده می‌مونن.» (چون در واقع ما از Rest استفاده می‌کنیم، ولی از اون متغیرهایی که جدا کردیم مثل password استفاده نمی‌کنیم).بدون این تنظیم خطا می‌داد، با این تنظیم خطا نمیده.const user = {&#xA;  name: &#34;mahdi&#34;,&#xA;  age: 25,&#xA;  password: &#34;12345&#34;&#xA;};&#xA;&#xA;const { password, ...safeUser } = user;&#xA;console.log(safeUser); این کار کمک می‌کنه کد تمیزتر، قابل‌خواندن‌تر و بدون بخش‌های مرده باشه.در نهایت، بد نیست بدونیم استفاده از ESLint همیشه هم بدون دردسر نیست.گاهی یه خط ساده می‌نویسی و پنج‌تا خطا تحویل می‌گیری، یا سر یه Rule خاص کلاً کُپ می‌کنی که چرا الان گیر داده 😅بعضی وقت‌ها هم مثل عکس پایین، کار به جایی می‌رسه که به این فکر میفتی که ولش کن اصلا نخواستیم کلا غیرفعالش میکنیم میره 😁&#34;wtf is wrong with eslint?!&#34; 😂اما واقعیت اینه که همین سخت‌گیری‌هاست که باعث میشه کد تمیزتر، و قابل‌نگه‌داری‌تری داشته باشیم.امیدوارم این متن براتون مفید بوده باشه ❤️اگر نظری داشتید یا تجربه‌ای با ESLint دارید و یا چیزی اشتباه گفتم ممنون میشم بهم تو نظرات بگید 🙏</description><category>مهدی فلاحتی</category><author>مهدی فلاحتی</author><pubDate>Fri, 12 Dec 2025 11:01:35 +0330</pubDate></item><item><title>هفت دلیل برای مهاجرت از Vuetify به Quasar</title><link>https://virgool.ir/@falahati.mahdi/quasar-vs-vuetify-g78lq5ls6zxa</link><description>هر دو فریم‌ورک Vuetify و Quasar بر پایه vuejs نوشته شده‌اند و از اصول طراحی گوگل متریال دیزاین پیروی می‌کنند.اگر به تعداد ستاره‌‌های این دو فریم‌ورک نگاه کنیم متوجه محبوبیت بیشتر vuetify می‌شویم.در ادامه مواردی رو بررسی می کنیم که نشان می‌دهد علارغم این که Quasar محبوبیت کمتری دارد ولی می‌تواند انتخاب هوشمندانه‌‌تری باشد.۱.بررسی Menu, tooltip syntaxدر این موارد هر دو slot و Activators رو دارن و تنها تفاوت در سینتکس هست .سینتک Quasar ساده تر و نیاز به کد کمتر است. tooltipQuasar tooltipVuetify tooltipMenusQuasar menuVuetify menu tooltip , icon , menu داستان وقتی پیچیده میشه که قصد استفاده از مثلا tooltip و icon و menu در یک دکمه رو داشته باشید.Button with icon and badge and menu Quasar frameworkButton with icon and badge and menu Vuetify framework&#xA;۲.نوتیفیکیشن و دیالوگ فقط با جاوا اسکریپت!!شاید بعضی مواقع نیازی به نوشتن کامپوننت دیالوگ و نوتیفیکیشن نداشته باشید و فقط لزوما بعد یه اکشنی نیاز به نمایش داشته باشید.در Quasar این امکان وجود دارد که بدون کامپوننت و فقط با جاوا اسکریپت این مورد رو هندل کنید.البته در Vuetify هم این امکان وجود دارد ولی باید پلاگین vuetify-dialog رو نصب کنیدQuasar dialog coderesult۳.همه پلتفرم‌‌ها در یک کدبیسبا استفاده از Quasar میتوانید تمام موارد تحت وب (SPA,SSR,PWA) و برای موبایل‌ اندروید و ios (Capacitor/Cordova) و همچنین دسکتاپ (Electron) با یک کدبیس داشته باشید.حتی می‌توانید با استفاده از Quasar اکستنشن های مرورگر درست کنید البته نه با یک کدبیس!. quasarmodeaddpwaquasarmodeaddelectronquasarmodeaddssrquasarmodeaddcapacitor تمام تنظیمات از قبل در فایل quasar.conf.js قرار داده شده است. به همین دلیل است که می‌توانید با یک کدبیس برای همه پلتفرم‌ها استفاده کنید. تنها نیاز است در command line دستورات را وارد کنید. quasardev-mpwaquasardev-melectronquasardev-mssr ۴.دستورات command line و اکستنشن هادر قسمت قبل مشاهده کردید که quasar دارای یک سری کامند لاین‌ها هست. مثلا شما می‌تونید یه کامپوننت جدید یا یه صفحه جدید درست کنید.Quasar command line۵.بهینه بودنیکی از مهم‌ترین دلایل استفاده از Quasar می‌توان بهینه بودن آن باشد. اگر دو فریم ورک رو با هم در زمان استارت پروژه در حالت dev مقایسه کنیم تفاوت کاملا مشاهده می‌شود.۶. تعداد بیشتر کامپوننت‌های آمادهدر Quasar کامپوننت‌‌های بیشتر نسبت به vuetify وجود دارد.برای مثال WYSIWYG editors , chat messages مواردی هست که می‌توان به آن اشاره کرد.۷.ابزارها و پلاگین‌های متنوعmetaبا استفاده از این پلاگین می‌توانید meta و title page رو مانند nuxt برای هر صفحه تنظیم کنید.Quasar Meta&#xA;Local/session storageاگر از localstorage جاوا اسکریپت استفاده کرده باشید با این پلاگین کاملا آشنا خواهید بود. با استفاده از این پلاگین یه مقدار کارتون راحت‌تر میشه.Quasar LocalStorage Date utilsدر Quasar می‌تونید کار با تاریخ و زمان بدون نیاز به moment.js انجام بدین و نیازی به اضافه کردن کتابخانه دیگری نداشته باشید.در آخر تصمیم با شماست که از کدام فریم ورک استفاده کنید ولی قطعا Quasar ارزش یک بار تست کردن رو داره.منبع</description><category>مهدی فلاحتی</category><author>مهدی فلاحتی</author><pubDate>Sat, 12 Mar 2022 12:08:48 +0330</pubDate></item></channel></rss>