React هنوز هم بیش ازحد پیچیده است و کسی درباره اش حرف نمی زند

React هنوز هم بیش ازحد پیچیده است و کسی درباره اش حرف نمی زند

اخیراً یک پروژهٔ جانبی انجام دادم و در پست دیگری درباره اش نوشتم. می خواستم فقط چند خط دربارهٔ نقاط ضعف React بنویسم، اما قلمم گرفت و حسابی درباره اش نوشتم. حالا این شده یک مقالهٔ کامل دربارهٔ اینکه چرا React آزاردهنده است و شاید اصلاً مشکل از خودِ آن نباشد.

روزهای Angular قدیم

وقتی تازه کار بودم، برای درآمد مجبور بودم با AngularJS کار کنم. آن زمان این ابزار واقعاً تازه و بزرگ بود و اولین چیزی بود که نه فقط چند تابع آماده، بلکه یک چارچوب کلی برای برنامه نویسی صفحات وب به ما می داد. قبل از آن فقط کتابخانه هایی مثل jQuery داشتیم که کار با عناصر صفحه را ساده می کردند، اما نه ساختار کاملی برای کل برنامه.

jQuery فقط یک لایهٔ ساده روی کدهای دستکاری صفحه بود و برای پروژه های بزرگ به سرعت تبدیل به کابوس نگهداری می شد. وقتی Angular آمد، همه چیز منظم شد: می توانستی بخش های مختلف صفحه (کامپوننت ها) را جداگانه تعریف و بارها استفاده کنی و داده ها را به صورت خودکار بین آن ها هماهنگ نگه داری. برای اولین بار این امکان میسر شد که برنامه های وب بزرگ و تعاملی بسازیم.

سر و کله React پیدا می شود

چند سال بعد فرصت پیدا کردم React یاد بگیرم و در چند پروژه از آن استفاده کنم. در مقایسه با Angular 2 که کلی کد تکراری، نوع گذاری با TypeScript و قواعد سخت برای جریان داده داشت، React در اوّل ساده به نظر می رسید. کم تر کسی باید از آن سر در می آورد و برای شروع کار فقط به خودِ React و چند کتابخانهٔ جانبی نیاز داشتی.

اما پشت این سادگی، هر تیم و هر پروژه ساختار خودش را می سازد و هیچ استاندارد ثابتی وجود ندارد. نتیجه؟ هیچ دو پروژهٔ React شبیه هم نیستند و هر کدام یک جور فریمورک شخصی سازی شده دارند که نگهداری اش واقعاً سخت است.

معماری و ساختار بخش ها

React شما را مجبور نمی کند از یک سبک معماری خاص پیروی کنید، اما وجود قالب JSX—جایی که کد HTML و JavaScript کنار هم اند—بخش ها (کامپوننت ها) را به صورت بلوک های کوچک به هم پیوسته نمایش می دهد. اگر بخواهی داده ها را از بالا به پایین به این بخش ها بفرستی، باید برای هر لایه  کلی دست و پا بشکنی و کار زیادی برای اتصال درست داده ها انجام دهی.

برای حل این مشکل، ابزارهایی به نام Hooks معرفی شد که می گذارند هر بخش بدون اتصال مستقیم به بخش بالاتر، از داده های سراسری استفاده کند. اما این در عمل یعنی هر جایی می تواند وضعیت کلی برنامه را تغییر دهد و هر جایی ممکن است تأثیری روی هر جای دیگر بگذارد. انگار دارد از یک متغیر جهانی استفاده می کنید، فقط با آداب و ساختار بیشتر.

ابزارهای React (Hooks)

یکی از اصلی ترین این ابزارها تابع useEffect است. قرار بود برای کارهایی که تأثیر بیرونی دارند—مثل درخواست به سرور—به کار رود. اما الان بسیاری از ما آن را برای هر کاری از جمله بارگذاری اولیهٔ بخش ها و مدیریت وضعیت هم استفاده می کنیم. یعنی با یک ابزار جانبی، اصلی ترین منطق برنامه را اجرا و وضعیت ها را جابجا می کنیم. برای هر مرحله از وضعیت جدید هم معمولاً باید یک useEffect دیگر تعریف کنیم. این کدها در عمل مثل یک زنجیرهٔ پیچیده اند که باید از آخر به اول دنبال شان کنی و بفهمی چه اتفاقی می افتد.

روش های رایج طراحی

اگر فکر می کنید همه چیز فقط با useEffect شلوغ است، کافی است نگاهی به مقالاتی بیندازید که بهترین روش های طراحی React را معرفی می کنند. برای انجام ساده ترین کارها هم باید چند الگوی پیچیده و لایه لایه را یاد بگیرید. آن وقت بعضی ها می روند CSS را هم داخل همان فایل های JSX می نویسند. یعنی صفحه، کد و سبک ظاهری همه در یک جا جمع شده و تبدیل شده به یک موجود عجیبی که فهمیدن ش سخت است.

چرا این قدر پیچیده شده؟

به نظر می رسد ما از ابتدا خودمان را گرفتار پیچیدگی کرده ایم. اکثر صفحات وب لازم نیست به این شدت تعاملی باشند؛ اما چون ممکن است بعدها به این قابلیت ها نیاز پیدا کنیم، از اول از ابزارهای سنگین مثل React استفاده می کنیم. در حالی که یک صفحهٔ سادهٔ بارگذاری شده از سمت سرور بسیار سبک تر و قابل فهم تر است. می توانید جاوااسکریپت کمکی هم در موارد ضروری اضافه کنید و تا حد امکان ساده بمانید.

اما وقتی تصمیم گرفتیم هر چیزی را قابل تغییر از هر جایی کنیم، پیچیدگی ناگزیر بالا رفت. ساختن یک رابط کاربری که هر بخش آن بتواند هر بخش دیگر را تغییر دهد، از همان اول مشکل بزرگی است.این مشکل مخصوص React نیست؛ Angular یا jQuery هم در مقیاس بالا کم می آوردند.

چطور می توان بهتر شد؟

می توانیم تعداد ورودی ها و خروجی های برنامه را کم کنیم. یعنی تا جایی که ممکن است تعداد دکمه ها و تعاملات روی صفحه را کاهش دهیم. شاید محصول ساده تر باشد، اما نگهداری اش به مراتب راحت تر است.

برای خروجی ها هم می توانیم بیشتر از سمت سرور صفحه را بسازیم و فقط در چند نقطهٔ خاص یک قطعهٔ کوچک React یا هر ابزار دیگری را قرار دهیم. به این سبک درباره ش صحبت شده به اسم «جزیره های تعامل»—جایی که بقیه صفحه ثابت است و فقط بخش های ضروری پویا می شوند.

در نهایت، ساده ماندن بهتر از پیچیده شدن بی دلیل است. اگر واقعاً نیاز به تعامل پیچیده داشته باشید، ابزارها و روش های مناسب تر هم در آینده ممکن است به وجود بیایند؛ اما تا آن زمان، همین ترکیب سرور-محور و چند بخش کوچک تعاملی کار اکثر برنامه های وب را راه می اندازد.

تصویر نویسنده مهدی پشوتن
مهدی پشوتن

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


پست هایی که مطالعه آن ها خالی از لطف نیست

نظرات کاربران
ارسال دیدگاه
هنـوز دیدگاهی ثبــت نشــده اولیــن باشــید شــما