ادی ام. عاشق جاوااسکریپت و فعال ریاکت. علاقه به R&D دارم و اینجا از چیزایی که برام جالبن میگم. اگه هروقت هرکمکی از دستم برمیومد بهم بگید 3>
کارهای تکراری, ممنوع! (قسمت دوم)
تو قسمت اول کارهای تکراری ممنوع, راجب vim صحبت کردیم و قابلیتی به اسم macro که به ما اجازه میده خیلی از کارهای تکراریی که ممکنه هرروز انجام بدیم رو ساده سازی کنیم.
اما اگه کارها کمی پیچیده تر بشن چی؟
مثال زیر رو درنظر بگیرید:
اپلیکیشن ریاکت نیتیوی داریم که در بعضی از کامپوننت هاش کدی شبیه مثال زیر داریم:
تو مثال بالا میبینیم که یه آبجکت جاوااسکریپتی ایمپورت شده و اسمش رو base_images گذاشتیم. چند خط پایین تر فیلد heart این آبجکت بعنوان uri فیلد src به کامپوننت Image داده شده.
میخوایم خروجی زیر رو داشته باشیم:
خب برای اینکه از عکس بالا به این خروجی برسیم باید قدمهای زیر رو طی کنیم:
۱- ایمپورت رو کلا حذف کنیم.
۲- آبجکت جاوااسکریپتیی که یکی از فیلد های آبجکت ایمپورت شده بعنوان فیلد uri توش استفاده شده رو پیدا کنیم.
۳- آبجکت رو حذف کنیم.
۴- عبارت require رو بنویسیم
۵- آدرس ایمپورتی که حذف کردیم رو داخل require بنویسیم
۶- عبارت /encodedAssets رو از داخل آدرس حذف کنیم
۷- عبارت بعد از آخرین / رو از توی آدرس حذف کنیم
۸- اسم فیلدی از آبجکت ایمپورت شده که قبلا بعنوان uri استفاده کرده بودیم رو پیدا کنیم (تو این مثال heart)
۹- اسمی که تو مورد ۸ پیدا کردیم رو به آخر آدرس بچسبونیم و بعد از اون یه .png بذاریم
لیست طولانیی شد. فقط این موضوع رو اضافه کنید که این مراحل نه یکبار, بلکه به ازای تک تک فایل های پروژه که داخلشون چیزی از encodedAssets ایمپورت شده باید انجام بشن :)
اولین تلاش من برای حل کردن مسئله بالا روش دستی بود; که خیلی سریع وقتی فهمیدم حدود ۸۰ تا فایل رو باید ادیت کنم با شکست مواجه شد.
روش دوم replace کردن عه. اینکه ما یه regex ای بنویسیم که عبارت های بالا رو پیدا کنه و replace اشون کنه. که خب ممکن بود کار کنه ولی یه بزرگی گفته "هروقت برای حل مشکلی از regex استفاده کردید, ازون ببعد دوتا مشکل خواهید داشت". مخصوصا که regex نسبتا پیچیده ای نیازه که بتونه آبجکت جاوا اسکریپتی که ایمپورت توش استفاده شده رو پیدا کنه. و replace های عجیبی هم احتمالا باید انجام بدیم. درکل نه تخصصش رو داشتم نه حال سر و کله زدن با regex رو :)
رویکرد بعدی هم منطقا macro های vim ان که خب واضحا اینجا کمکی بهمون نمیکنن. ما چیزی میخوایم که ساختار جاوااسکریپت مارو بفهمه و بتونه متوجه بشه آبجکت چیه, آدرس ایمپورت چیه, فیلد ینی چی و چیزهایی از این قبیل. پس حتی این راه حل هم شکست خورده محسوب میشه.
پس میرسیم به آخرین خط دفاعیمون. codemod های عزیز دل. ابزار های تغییر کدی که صرفا replace نمیکنن, قبلش کدت رو میخونن, میفهمن و AST اش رو میسازن.
درحال حاضر پرکاربرد ترین ابزار برای اینکار کتابخونه jscodeshift هست که خودش از چند بخش تشکیل شده:
بخش اول; یه transpiler واقعی جاوااسکریپته که کد جاوااسکریپت ما رو میخونه و AST اون رو میسازه
بخش دوم; یسری ابزارن برای traverse کردن این AST ساخته شده و پیدا کردن و تغییر دادن قسمت هایی که لازمه تغییر کنن
بخش سوم; ابزاری برای تبدیل دوباره AST به کد javascript ضمن حفظ code-style ما (مثلا اگه تو کد ارجینال از دوتا space استفاده کرده باشم و طول خط هام بیشتر از ۸۰ کاراکتر نباشه, این موارد توی کد خروجی هم لحاظ میشن)
تو این ویدیو سعی کردم با استفاده از codemod رو مثالی که زدم کار کنم و ببینیم که بالاخره چجوری موفق شدم این بار هم از انجام دادن کارهای تکراری فرار کنم.
پس... کارهای تکراری, ممنوع!!!
لینک آپارات: لینک
دیگر مقالات من:
مطلبی دیگر از این انتشارات
سایت React چندزبانه با استفاده از کتابخانه i18next
مطلبی دیگر از این انتشارات
دنیای جدید reactJS
مطلبی دیگر از این انتشارات
داخل هوکها چه خبره؟ (قسمت اول)