انگیولار ۲ در مقابل ری‌اکت

به قلم: مهندس سالار کابلی

من یه مدتی هست که شرکتم رو تغییر دادم و شرکت جدید یه شرکت خیلی بزرگه که بخش‌های مختلف داره. این بخشی که من توش کار میکنم بخش Commerce است و کارشون اینه که برای شرکت‌های و سازمان‌های دیگه، سیستم‌های فروش آنلاین (B2B, B2C) در واقع فروشگاه آنلاین، راه‌اندازی کنن.

یکی از مهم‌ترین ابزارهایی که برای راه‌اندازی اینجور سیستم‌ها استفاده می‌کنن Hybris است که یه «فروشگاه‌ساز» پیچیده و گران ساخت آلمان است و مشتری‌های سازمانی این رو ترجیح میدن چون متعلق به شرکت SAP است و خب خیلی‌ها از بقیه محصولات SAP هم استفاده می‌کنن. این Hybris، با جاوا نوشته شده و برای همین این بخش از شرکت ما پر از برنامه‌نویس‌های جاوا است چون راه‌اندازی و تغییر هایبریس نیاز به مهارت داشتن در جاوا داره (متاسفانه). توی پروژه‌های Commerce که با هایبریس راه‌اندازی می‌شن، معمولا برای راه‌اندازی بخش Front-End از Angular استفاده می‌شه. حالا تا قبل از اینکه من توی شرکت شروع به کار کنم از نسخه ۱ انگیولار استفاده می‌شد ولی از وقتی من اومدم (شش ماه پیش) شروع کردن به استفاده از نسخه ۲. با وجود اینکه من مقاومت زیادی کردم و نمی‌خوساتم از انگیولار استفاده کنم، ولی به دلایلی که پایین‌تر توضیح می‌دم، متوجه شدم که برای اون محیط و اون پروژه‌ها این بهترین گزینه بوده.

از طرفی هم من یک سال و نیمه که روی باترکاپ کار می‌کنم، یه نرم‌افزار مدیریت رمزعبور رایگان و متن‌باز که با دوست و همکارم Perry راهش انداختیم. اوایل که شروع کردم به کار روی این پروژه، برای بخش فرانت‌اند فریم‌ورک BackboneJS رو انتخاب کردم چون برام آشنا تر از بقیه فریم‌ورک‌ها بود، ولی به دلایلی که تو این نوشته شرح دادم خیلی سریع فهمیدم که گزینه مناسبی نبوده و کل پروژه رو با React و Redux بازنویسی کردم. نسخه‌ای که با ری‌اکت بازنویسی شده بود رو نوامبر ۲۰۱۶ منتشر کردیم و از اون موقع داریم به سرعت به روز رسانی می‌کنیم.

بعد از ۱۰ ماه کار روی یه پروژه React و ۶ ماه کار روی پروژه‌های Angular 2 (به صورت همزمان) فکر می‌کنم بتونم یه جمع بندی کلی بکنم در مورد تجربه کارم با هردو شاید بتونه به کسی که می‌خواد بینشون انتخاب کنه کمک کنه.

انگیولار ۲

یکی از بهترین چیزهایی که در مورد انگیولار می‌شه گفت اینه که به سرعت می‌شه یک نمونه اولیه از محصول رو راه‌اندازی کرد. چون انگیولار بیشتر یک Framework هست (و نه کتابخانه) و خودش به صورت پیش‌فرض شامل خیلی چیزها است که توسعه رو به شدت آسون می‌کنه.

یکی از نقات قوت انگیولار ۲، زبان توسعه‌اش (Typescript) است از نظر من. با اینکه می‌شه با جاواسکریپت معمولی هم کدها رو نوشت، ولی مستندات انگیولار توصیه می‌کنه که از تایپ‌اسکریپت استفاده بشه که به نظر من گزینه بسیار خوبی است. با اینکه من قبلا با تایپ‌اسکریپت مشکلات زیادی داشتم (بخاطر شبیه بودنش به سی‌شارپ و جاوا و همچنین چون توسط مایکروسافت توسعه داده می‌شه) ولی بعد از مدت‌ها کار باهاش، واقعا بهش علاقه پیدا کردم. جاواسکریپت بخاطر نداشتن تایپ (Type) در زبان، ضعف‌های بسیاری در زمینه Tooling (ابزار کار، ادیتور و ...) داشته همیشه و تایپ‌اسکریپت بسیاری از این مشکلات رو حل می‌کنه. تجربه استفاده از تایپ‌اسکریپت باعث شد که حتی تو پروژه‌های شخصی هم گاهی ازش استفاده کنم.

یکی دیگه از خوبی‌های (؟) انگیولار، اینه که از مفاهیم جا افتاده و استاندارد معماری نرم‌افزار استفاده می‌کنه و این (به علاوه تایپ‌اسکریپت) باعث می‌شه که حتی برنامه‌نویس‌های قدیمی جاوا هم بتونن راحت باهاش کنار بیان و کد فرانت‌اند بنویسن و در توسعه‌اش مشارکت داشته باشن. مثلا وقتی یکی از برنامه‌نویس‌های جاوا می‌خواد چیزی رو توی بک‌اند درست بکنه، شاید توی همون PR توی چیزی در فرانت‌اند هم دست ببره و درستش کنه چون کدها به نظرش آشنا میان حتی اگر هیچوقت کد سمت کاربر ننوشته باشه. این مزایای زیادی داره مخصوصا برای شرکت‌ها و سازمان‌های بزرگ. چون همیشه استخدام برنامه‌نویس‌های فرانت‌اند درحالی که برنامه‌نویس بک‌اند توی شرکت بیکار نشسته، کار علاقلانه‌ای نیست و شرکت براش خیلی بهتره که از نیروهای فعلیش استفاده کنه. شاید من و شما، که به این محیط‌ها و شرایط عادت نداریم این موضوع آزارمون بده، ولی خب واقعیت اینه که برای شرکت‌های مسایل دیگه اولویت دارن مثل همین چیزی که توضیح دادم.

موضوع بعدی که به نظرم توی توسعه یک سری از پروژه‌ها کمک زیادی می‌کنه اینه که انگیولار خودش خیلی چیزها رو به صورت پیش‌فرض داره. مثلا برای انجام درخواست‌های شبکه نیاز به نصب چیز اضافی نیست و از پکیج Http خود انگیولار میشه استفاده کرد و خیلی چیزهای دیگه. برای همین سرعت توسعه بالاتر می‌ره و از لحاظ اقتصادی هم به صرفه تره.

اما! بعد از ۶ ماه کار با انگیولار تو ۴-۵ پروژه مختلف، و همه مزایای بالا، باز هم اگر قرار باشه برای یک پروژه جدید فریم‌ورک انتخاب کنم، به هیچ وجه انگیولار رو انتخاب نمی‌کنم. به چند دلیل مختلف:

• انگیولار یه فریم‌ورک opinionated است، یعنی یک جورهایی روش طراحی و توسعه پروژه رو دیکته می‌کنه. این شاید برای شرکت‌های بزرگ خوب باشه، ولی برای من که می‌خوام پروژه رو بسته به نیازهام مهندسی بکنم چیز جذابی نیست.
• انگیولار سنگینه. با اینکه نسخه ۴ انگیولار سبک‌تر شده و خودشون اصرار دارن در حال رفع مشکلات هستن، ولی انگیولار خیلی بار اضافه به همراه داره. مثلا همین پکیج Http و چیزهای دیگه‌ای مثل RxJS، ابزارهای Browser و ... که به صورت پیش‌فرض با انگیولار نصب می‌شن. خیلی از این چیزها برای اینن که توسعه راحت‌تر بشه ولی خب من دوستشون ندارم.
• انگیولار از سیستم Templating متنی استفاده می‌کنه. برای اینکه چیزی رو در فرانت‌اند نمایش بدین، باید کد HTML بنویسید و توش از تگ‌های مخصوص انگیولار استفاده کنید. انگیولار هم در «زمان اجرا» (و نه زمان ساخت) این رشته HTML رو بررسی و Parse میکنه و متغیرها و ... رو توش جایگزین می‌کنه با مقادیر اصلی. کلا سیستم‌های templating هرچقدر هم خوب ساخته شده باشن و روی سرعت پردازششون کار شده باشه، ولی بازهم کندن و امکان بروز خطا هم درشون خیلی وجود داره. مثلا وقتی دارید روی پروژه انگیولار با وب‌پک کار می‌کنید، نصف مواقع اگر مشکلی توی کد HTML تون وجود داشته باشه، پیر میشین تا بفهمید مشکل از کجا بوده. دلیلش هم این است که کد HTML از نظر جاواسکریپت فقط یک رشته متن است و اون رو نمی‌فهمه و انگیولار باید پردازشش کنه.
• من از مفاهیم Reactive Programming (که به همراه پکیج RxJS وارد انگیولار می‌شه) خوشم نمیاد. به نظرم برای انجام کارهای ساده بیش از حد پیچیدست و ذهن برنامه‌نویس رو به سمت پیچیدگی بیشتر سوق می‌ده تا سادگی. این نظر خیلی شخصی است ولی خب من طرفدار برنامه‌نویسی Functional هستم و از Observe کردن اشیا، فراری‌ :)
• انگیولار، گذاشتن Side Effect توی کامپوننت‌ها رو ترغیب می‌کنه. اگر با مفاهیم Functional Programming آشنایی داشته باشید منظورم رو متوجه می‌شید، اگر نه، تو بخش پایین که ری‌اکت رو توضیح می‌دم سعی میکنم کمی هم در مورد اون بنویسم.

ری‌اکت و ریداکس

یکی از بزرگترین مشکلاتی که در شروع کار با ری‌اکت باهاش مواجه بودم این بود که یاد گرفتنش کار آسونی نبود. البته منظورم از یاد گرفتن ساختن برنامه‌های واقعی باهاشه، وگرنه Todo List رو که همه می‌تونن چشم بسته هم بسازن باهاش. وقتی توی اینترنت دنبال مقالات مربوط به ری‌اکت و ریداکس می‌گردی، هزار جور آدم مختلف هزار جور راه توسعه مختلف بهت پیشنهاد می‌دن و آدم خیلی راحت بین چیزهای مختلفی که می‌خونه گم می‌شه و نمیدونه کدوم به درد کارش می‌خوره. این موضوع دو تا دلیل داره، یکی اینکه برعکس انگیولار، ری‌اکت یه فریم‌ورک نیست و فقط یه View Library است و کارش فقط Presentation است و نوشتن منطق برنامه کاملا به عهده شماست و ری‌اکت روی هیچ روشی برای اینکار تاکید نداره. فقط به شما کمک می‌کنه خروجی رو سریع‌تر و راحت‌تر نمایش بدین. دوم اینکه چون opinionated نیست، شما دستتون کاملا بازه که چطور ازش استفاده کنید برای همین آدم‌های مختلف سعی می‌کنن opinionated اش بکنن و نظر خودشون رو به عنوان «استاندارد» به شما قالب کنن. نباید گولشون رو بخورید!

برای فهمیدن ری‌اکت (و در ادامه‌اش ریداکس)، شما باید یک چیز ساده در ریاضی رو درک کنید:

λx.y (z)

تابع (Function) ـی که یک ورودی (Argument) و یک نتیجه (Return value) داره. در نمای Lamda Calculus بالا، تابع ورودی x رو قبول می‌کنه و y رو به عنوان خروجی تولید می‌کنه. و ماهم مقدار z رو به این تابع می‌دیم.

اگر با مفاهیم برنامه‌نویسی Functional آشنا نیستید پیشنهاد می‌کنم این کتاب عالی رو مطالعه کنید. همه چیز در ری‌اکت و ریداکس بر اساس این مفاهیم طراحی شده. برنامه شما در واقع یک Function از ورودی‌هاست و یک خروجی (ظاهر برنامه تون) رو تولید می‌کنه. در برنامه‌نویسی فانکشنال، اگر ورودی تغییر نکنه، خروجی هم نباید تغییر کنه. بنابراین اگر ورودی‌های برنامه شما تغییر نکنه، همیشه یک خروجی رو باید تولید کنه. (برای حفظ ساختار این مطلب، از توضیح بیشتر خودداری می‌کنم و امیدوارم خودتون بیشتر در این زمینه تحقیق کنید و یا اگر دوست داشتید از من سوال بپرسید)

بعد از درک این مفاهیم، یاد گرفتن ری‌اکت و ریداکس خیلی خیلی ساده می‌شه و حداقل برای من نوشتنش لذت بخشه چون برنامه‌ای که می‌نویسم کاملا قابل پیش‌بینیه. یکی از چیزهایی که معمولا کسایی که می‌خوان ری‌اکت رو یاد بگیرن می‌ترسونه، JSX است، که قبلا به تندی (و اشتباه) در موردش غر زدم! بخاطر این‌که JSX ظاهر «شبیه» به HTML داره، همه فکر می‌کنن که شما در حال نوشتن اچ‌تی‌ام‌ال در جاواسکریپت هستید و این برای خیلی‌ها جذاب نیست. اما اصلا اینطور نیست. JSX غیر از ظاهرش، ارتباط خاصی با HTML نداره. بذارید سعی کنم توضیح بدم چرا. این تیکه کد React رو در نظر بگیرید:

const Title = ({ text }) => (
  <h1>
    <span className="colorize">{text}</span>
  </h1>
);
console.log(<Title text="hello" />);

با اینکه این شبیه به HTML است، ولی وقتی برنامه‌تون رو اجرا می‌کنید، قبل از اینکه به مرورگر برسه، این کد توسط Babel تبدیل می‌شه به کد زیر:

const Title = function Title({ text }) {
  return React.createElement(
    "h1",
    null,
    React.createElement(
      "span",
      { className: "colorize" },
      text
    )
  );
};
console.log(React.createElement(Title, { text: "hello" }));

و در واقع این تابع چیزی هست که مرورگر میبینه و اجرا می‌کنه. اگر باور نمی‌کنید، خودتون به جای نوشتن JSX، این‌بار از تابع استفاده کنید. اینجا بیشتر توضیح دادن در این مورد. پس همینطور که می‌بینید، JSX فقط کار شما رو راحت‌تر می‌کنه که با یه Syntax «واضح» تر، ساختار تو در تو بسازید. یک مثال دیگه برای اینکه باور کنید که JSX ربطی به HTML نداره پکیج react-blessed است. اگر به جای react-dom که به صورت پیش‌فرض باهاش کار می‌کنید با این پکیج کار کنید، خروجی برنامه شما به جای مرورگر (و در نهایت HTML)، توی ترمینال (کنسول) نمایش داده می‌شه. برای اطلاعات بیشتر صفحه همون پکیج رو ببینید. پس ری‌اکت در واقع فقط یک ابزار است که به شما کمک می‌کنه «تابع» بنویسید.

با اینکه به وضوح من از ری‌اکت خیلی خوشم میاد، اما در بعضی از شرایط ازش استفاده نمی‌کنم:

• ری‌اکت فقط یک View Library است. شما باید خودتون بقیه کارها رو بکنید. مثلا درخواست شبکه، کار با دیتابیس و ... همه به عهده شماست و براش باید ابزارهای مختلف نصب کنید. این برای خیلی‌ها مخصوصا در شرکت‌های بزرگ جذاب نیست چون به سرعت ممکنه چند دستگی به وجود بیاد بین برنامه‌ها.
• وقتی تیم شما از برنامه‌نویس‌هایی با پیش‌فرض ذهنی «شی گرایی» تشکیل شده، استفاده از ری‌اکت ممکنه هم‌تیمی‌هاتون رو کلافه کنه چون تقریبا با هرچیزی که تاحالا باهاش کار کردن تفاوت داره مفاهیمش و ممکنه قبول کردن این تغییر براشون سخت باشه. شما قرار نیست هم‌تیمی‌هاتون رو اذیت کنید.
• اگر برنامه‌نویسی Functional و Pure رو دوست ندارید و نمیتونید درکش کنید، یا به هر دلیلی فکر می‌کنید برای کار شما مناسب نیست، شاید استفاده از ری‌اکت و ریداکس براتون مناسب نباشه.

در نهایت

همونطوری که قبلا در این ارائه سعی کردم توضیح بدم، هر ابزاری در جا و مکان مناسب خودش قابل استفاده است و لازم نیست آدم بچسبه به یک ابزار یا زبان خاص و روی استفاده از اون تاکید کنه. هیچ فریم‌ورک، ابزار یا زبانی از سر بیکاری به وجود نیومده، همه این‌ها زاده نیازهای سازنده‌هاشون بودن و خیلی تصادفی ممکنه نیازهای ما با نیازهای اونا همسو باشه. بالاتر توضیح دادم که خود من دو سال پیش با یه سری چیزها کاملا مخالف بودم و الان دوستشون دارم، بخاطر اینکه سعی کردم ذهنم رو باز کنم و ببینم هر ابزاری در جای خودش قابلیت‌های زیادی داره و کمک زیادی بهم می‌کنه.

حالا چه از انگیولار استفاده می‌کنید و چه از ری‌اکت، سعی کنید براتون مهم نباشه که دیگران چه فکری در موردتون می‌کنن و آیا کارتون «باحال» است یا نه. ابزارها فقط ابزار هستن و سبک زندگی نیستن. از چیزی استفاده کنید که مشکلتون رو حل می‌کنه.

منبع: وب سایت سالار کابلی