مطمئنا میدانید چه زمانی به HTML و CSS نیاز دارید، تمام وب برپایه HTML و بخش مهمی از آن CSS است. فکر کردن به اینکه چه زمانی به جاوااسکریپت نیاز خواهید داشت نیز موضوعی ساده است، وقتی که بخواهید قابلیت تعاملی به صفحات یا کاربردهای مشخص دیگری را اضافه کنید، از آن بهره میگیرید. البته وقتی که قصد استفاده از کتابخانهها را نیز دارید، استفاده از آن اجباری است. برای مثال ما از جیکوئری برای دسترسی سادهتر و بهتر به DOM استفاده میکنیم، کتابخانهای که کاملا مبتنی بر جاوااسکریپت است.
وقتی که نیاز پیدا کردن به چنین کتابخانههایی کم شد و به صورت ناگهانی خیل عظیمی از فریمورکهای جدید بوجود آمد، دیگر استفاده از هرکدام آنها برای ما ساده و واضح نبود. ما در چه مرحله و زمانی به React نیاز داریم؟
در بسیاری مواقع من از ریاکت تنها زمانی استفاده میکنم که بخواهم چیزهای بزرگی را با جاوااسکریپت پیادهسازی کنم. در کنار این مواردی مانند Vue، Ember و… نیز هست. متوجه این قضیه هستیم که این موارد مشابه هم نیستند اما مهم آن است که بدانید این موارد میتوانند همگی تقریبا یک خروجی را برای شما داشته باشند.
در زیر میتوانید دلایل صحیح و اشتباه برای استفاده از این فریمورک را مشاهده کنید.
-
صحیح : بدلیل وجود تعداد زیادی از حالتها
البته ممکن است حالت کلمهای تا حدی نامفهوم باشد، اما منظور من مواردی مانند زیر است:
- کدام گزینه از منو ناوبری فعال است.
- کدام دکمه فعال و یا غیر فعال است.
- مقدار داخل یک ورودی چیست.
- کدام منو انتخابی آکاردئونی، انتخاب شده است.
- چه زمانی یک قسمت بارگذاری میشود.
- چه کاربری وارد شده و به چه تیمی تعلق دارد.
- آیا موردی که کاربر روی آن کار میکند منتشر شده یا در حالت پیشنویس است.
این حالتها میتواند مستقیما به خود محتوا نیز مرتبط باشد :
- مشاهده تمام کامنتها روی یک پست و مشاهده تمام مربوط به آنها.
- وضعیت نمایش کنونی محتوا و تمام متادادههای آن.
- آرایهای از تمام مقالههای مرتبط و متادادههای آن.
- لیستی از نویسندهها.
- لاگی از جدیدترین فعالیتهای مربوط به هر کاربر.
ریاکت به شما کمک نمیکند تا این وضعیتها را سازمان دهی کنید، تنها کاری که میکند این است که: من میدانم که میخواهید با وضعیت مواجه شوید، بنابراین تنها وضعیت را فراخوانی کن و از یک راه برنامهنویسی شده ورودی و خروجیهای آن را کنترل کن.
قبل از پیش آمدن بحث ریاکت ممکن بود که فکر کنیم اینکارها با ریاکت انجام میشود اما واقعیت آن است که هیچ قاعده یا مفهوم مستقیمی برای این کار وجود ندارد.
ممکن است تا به حال این جمله را که میگوید «یک راه برای واقعیت وجود دارد» را شنیده باشید، بسیاری از وقتها ما با DOM نیز درست مانند این موضوع رفتار میکنیم که تنها راه دست یافتن به واقعیت است. برای مثال فکر کنید که میخواهید بدانید که یک فرم آیا قابلیت ارسال شدن دارد یا خیر. ممکن است برای چنین کاری از دستوری مانند $(".form input[type='submit']).is(":disabled") استفاده کنید. به این دلیل که تنها راه منطقی برای این کار بررسی کردن یک شرط خواهد بود که در نهایت منجر به فعال بودن یا نبودن یک دکمه میشود. بنابراین در این شرایط دکمه منبع اصلی برای دستیابی به واقعیت در اپلیکیشن شماست.
ریاکت در چنین شرایطی به ما کمک میکند که:
- در رابطه با تمام مواردی که با آنها در ارتباطیم فکر کنیم.
- وضعیتها همراه با مقداری از Json هستند پس کار کردن با آن سادهتر میشود و تکنولوژیهای Back-End نیز میتوانند با آن بهتر کار کنند.
- بهترین مورد این است که شما با ریاکت نیازی نیست که مستقیما با DOM کار کنید، شما HTML خود را میسازید و از React برای دسترسی به این نقطه از واقعیت کمک می خواهید.
- صحیح: برای مبارزه با اسپاگتی
این موضوع به مواردی که تا به حال گفته شد بسیار مربوط است. کدنویسی اسپاگتی مربوط به زمانی است که ساختاربندی و سازماندهی کدهایتان بسیار سخت میشود. دوباره فرمی که روی وبسایتتان بود را تصور کنید. این فرم همراه با مقداری از قواعد منطقی و محاسباتی است (مخصوصا زمانی که با ورودیها کار میکنید). ممکن است برخی ورودی وجود داشته باشد که با تغییر دادن آن، محاسبات جدیدی را نمایش میدهد. پس در چنین شرایطی ممکن است به یک کتابخانه اعتبارسنجی نیاز داشته باشید. ممکن است بتوانید برای حل این مشکل کار دیگری نیز انجام دهید و آن این است که تا زمانی تمام کدهایتان بارگذاری میشوند، فرمتان را غیر فعال کنید. بعد از آن وقتی فرم فرستاده شد، دادههای درست ارسال شود و قسمت سرور وبسایت بتواند به درستی آن را مدیریت کند. هیچ اتفاق عجیبی رخ نمیدهد، اما ممکن است خیلی ساده شما را گیج کند.
چنین کاری را یک توسعهدهنده جدید چگونه روی پروژه انجام دهد ؟
ریاکت به شما این پیشنهاد را میدهد که موارد مختلف را در ماژولها بسازید. پس براساس این قضیه یک فرم میتواند یک ماژول در طراحی وبسایت شما باشد. هرکدام از این ماژولها کاری را انجام میدهند که به آنها داده شده و تاثیری روی یک دیگر نمیگذارند.
در چنین حالتی ریاکت میگوید : شما نمیتوانید به DOM به صورت مستقیم دسترسی پیدا کنید، به این دلیل که DOM از آن من است و به شما این اجازه برای کار کردن به صورت مستقیم داده نمیشود.
البته این موضوع را باید گفت که ریاکت به کاملی مشکل کدنویسی اسپاگتی را رفع نمیکند. اگر از آن استفاده کنید، باز هم ممکن است با مواردی مانند نامگذاری اشتباه، ارتباطات نادرست و… همراه باشید.
در تجربه من به نظر میآید که Redux تکنولوژی است که میتواند تمام اسپاگتیها را از بین ببرد. Redux میگوید که من میتوانم تمام وضعیتهای مهم را بررسی کنم و به کلی کار کنم نه ماژول به ماژول. من منبع اصلی واقعیت هستم.
اگر با Redux کار کنید در نهایت کدهایی را دریافت میکنید که بسیار محکم و قدرتمند هستند.
- صحیح: تعداد زیادی از حالتها برای مدیریت DOM.
به صورت دستی DOM یکی از بزرگترین دلایل برای بوجود آمدن کدهای اسپاگتی است.
- به اینجا HTML تزریق کن.
- بعضی چیزها را در آن قسمت حذف کن.
- به رویدادهای این قسمت گوش کن.
- یک رویداد جدید در این قسمت درست کن.
- محتوای جدیدی را بیاور، قسمت جدیدی را تزریق کن، مطمئن شو که رویداد درست را استفاده کردهاید.
تمام این موارد ممکن است به هر شیوهای در اپلیکیشن شما اتفاق بیافتد و تمام این موارد در نهایت به کدهای اسپاگتی تبدیل خواهند شد. سازمان دهی درست از دست میرود و این تماما به منبع اصلی شما یعنی DOM برمیگردد. وقتی به هر المانی یک سری دستورات خاص و رویدادها بدهید، شناسایی کردنشان و پی بردن به آنها برایتان بسیار سخت خواهد شد.
ریاکت میگوید: شما نیازی ندارید که به صورت مستقیم با DOM کار کنید. من یک DOM مجازی دارم که شما میتوانید با آن کار کنید. تمام رویدادها برای المانهای مختلف در نظر گرفته شده پس شما تنها نیاز دارید فراخوانی کنید و اگر بخواهید چیزی را دستی استفاده کنید تنها نیاز است که از ماژولها بهره ببرید. اگر اولویت قضیه نیز برایتان مهم است میتوانید ماژولهایی را بالاتر از ماژولهای دیگر تعریف کنید.
مدیریت سخت و پیچیده DOM نیز یکی دیگر از موضوعات است. یک اپلیکیشن چت را در نظر بگیرید که همزمان با دریافت داده از بانک اطلاعاتی و نمایش مداوم آنها باید DOM را اجرا کند. هر بار اجرای چنین حالتی در یک برنامه بلادرنگ به نظر بسیار پیچیده میرسد.
- اشتباه : فقط به خاطر اینکه تکنولوژی جدیدی است
یادگیری چیزی تنها برای یادگیری آن، یکی از موضوعات خارقالعاده است. اما وقتی این مسئله به ساخت پروژهای جدید برای یک مشتری میرسد باید کمی بهتر دقت کرد.
برای مثال یک وبلاگ را در نظر بگیرید که هیچکدام از سناریوهای بالا که ریاکت برای کار با آنها مناسب است را ندارد. به این دلیل که با سناریوهای آن همخوانی ندارد پس انتخاب بدی است و تنها باعث پیچیده شدن پروژه و بیشتر شدن مستقلات آن میشود. مواردی که هیچ وقت استفاده نمیشود.
اما اگر وبلاگ شما یک اپلیکیشن SPA (تک صفحهای) است و نیاز دارد تا بدون بروزرسانی مرورگر دادههای جدیدی در آن قرار بگیرد -از هر منبعی- پس ریاکت میتواند انتخاب مناسبی برای شما باشد.
- اشتباه : من جاوااسکریپت را دوست دارم به همین خاطر میخواهم همه چیز با آن نوشته شود
خیلی وقتها شنیدهام که میگویند: جاوااسکریپت رو یاد بگیر، خیلی عظیمه همه جا کاربرد داره و می تونی باهاش توی یه جایی استخدام شی.
درست است، اگر تاریخچه اخیر وب را مطالعه کنید مشاهده میکنید که جاوااسکریپت در همه جا حضور دارد. شما نودجیاس را روی قسمت سرور دارید، فریمورکهای مختلفی دارید که با CSS کار میکنند و React را دارید که در HTMLتان حضور دارد.
تمام اینها مواردی درست هستند. اما فقط به این دلیل که شما میتوانید از آن استفاده کنید، بایدی در کار نخواهد بود. تمام پروژههای ممکن است برای این زبان و تکنولوژیهای آن مناسب نباشند.
دلایل دیگری نیز وجود دارد که احتمال میدهد شما باید از ریاکت استفاده کنید در اینجا میتوانید آنها را نیز مطالعه کنید.
- شاید : موقعیتهای کاری زیادی دارد
هیچکسی تا به حال چنین حرفی را برای هیچ پروژهای نگفته است. شما میتوانید در جاوااسکریپت حرفهای شوید اما این موضوع زمان میبرد. هرکسی میتواند از هرچیزی که واقعا در آن حرفهای است پول در بیاورد.
- شاید : این چیزی است که من میدانم
شما در حال یادگیری هستید، این عالیست هرچقدر بیشتر بدانید موارد بیشتری برای استفاده کردن در اختیار دارید. اما متوجه این موضوع باشید که شما باید با چیزی که میدانید چیزی را نیز درست کنید.
دیدگاه و پرسش
در حال دریافت نظرات از سرور، لطفا منتظر بمانید
در حال دریافت نظرات از سرور، لطفا منتظر بمانید