Printable View
سلام
من مدته زیادی نیست که با react اشنا شدم این طور که فهمیدم برای کار با react باید صفحه رو به چندین کامپوننت تبدیل کنیم
و برای هر کامپوننت کدهایی موسوم به jsx بنویسیم
چیزی که ازش سر در نیاوردم اینه که ایا وقتی ما با react کار میکنیم دیگه باید اون روش قدیمی کار با html رو فراموش کنیم؟
یعنی همه چیز باید در قالب کامپوننت های react قرار بگیره؟ پس تمام بخش مربوط به front end پروژه ی ما به چندین و چند
کامپوننت react تبدیل میشه؟
ممنون
در کل تمامی فریمورک های جاوا اسکریپتی که کار تولید و مدیریت html رو در سمت کلاینت بر عهده دارن به این شکل کار میکنن. شما یک قالب برای html خود دارین که حالا ممکنه template یا کامپوننت نامیده بشه. این همون چیزی هست که شما در سمت سرور مینوشتین و زبان سمت سرور اون رو با کدهای زبان سروری ترکیب و نتیجه نهایی در قالب html به کلاینت ارسال میشه.نقل قول:
نوشته شده توسط roya_django
برای مثال در یک حلقه for شما سطرهای یک جدول رو ایجاد میکنید. مزیت بسیار بزرگ این فریمورکها کاهش بار پردازش CPU در سمت سرور، کاهش مصرف حافظه و کاهش چشمگیر عملیات IO در سمت سرور هست.
من به مدت 3 ساله که تمامی وب سایتهای خودم رو با ناک اوت (knockout) پیاده سازی میکنم. با react و angular هم کار کردم ولی به نظرم سینتکس و سبکی ناک اوت نسبت به بقیه بهتره. آنگولار امکانات بسیار زیادی داره که واقعا از همه اونها استفاده نمیشه در عوض ناک اوت بسیار سطح پایین هست و شما خیلی چیزها رو خودت باید انجام بدی در عوض سرعت بسیار خوبی داره، حجم به مراتب از آنگولار کمتر هست. react هم همانند ناک اوت سطح پایین هست ولی سینتکس پیچیده تری نسبت به ناک اوت داره از لحاظ سرعت و حجم کد تولیدی هم تفاوتی ندارن.
با استفاده از این کتابخونه ها اگر تسلط خوبی روی جاوا اسکریپت داشته باشین به راحتی میتونید جی کوئری رو از پروژه حذف کنید هرچند وجود جی کوئری هم مشکلی بوجود نمیاره.
کدهای html شما فقط یکبار با اولین درخواست در کلاینت کش میشه و دیگه تا اعلام صریح شما از سرور درخواست نمیشن و این یعنی به مراتب سرعت شما بالاتر میره.
شما یک جدول رو فرض کنید که 500 سطر و 10 ستون داره. مدام باید کدهای تکراری <tr> و <td> و غیره تکرار بشن و تقریبا بالای 50 درصد حجم کد تولیدی تکراری هست. با استفاده از کتابخانه های جاوا اسکریپتی شما تنها از سرور json دریافت میکنید که در بری مواقع تنها 20 درصد حجم کدها در حالت عادی هست و سپس این json رو میسپارید به کتابخونه و اون کاری رو که قبلا سرور انجام میداد (یعنی تولید html نهایی) رو در سمت کلاینت برای شما انجام میده.
اگر فرض بگیریم بصورت همزان سرور باید 1000 درخواست رو پردازش کنه و از حالت کلاسیک تولید html در سمت سرور استفاده کنیم در واقع cpu سرور شما 1000 بار کدهای html رو پردازش میکنه و 1000 بار با اون حجم زیاد به سمت کلاینت ارسال میکنه. تصور کنید چه ترافکی و چه حجمی از حافظه نیاز هست. در حالیکه با spa تنها رکوردها در قالب شیئ جیسون بازگشت داده میشن و cpu هیچ پردازش اضافی و غیرضروری انجام نمیده و میتونه همزمان درخواستهای بیشتری رو با سرعت بیشتری پردازش کنه.
آینده وب حتما به سمت SPA پیش میره و اگر شما مانند من با اون کار کنید بهتون قول میدم برای همیشه حالت کلاسیک رو کنار میذارید چون سرعت توسعه پروژه رو دهها برابر بیشتر میکنه و از انجام کارهای تکراری و خسته کننده راحت میشن.
در ابتدا ممنون بابت توضیحات.
اگه جی کوئری رو حذف کنیم پس دیگه برای ajax چه اتفاقی می افته ؟من تا حالا هرچی از ajax استفاده کردم با متدهای load و ajax جی کوئری بوده
ایا کتابخانه ای مثل react یا فریم ورکی مثل angular میتونه جایگزین ajax باشه؟
مشکل اینه که بازار کار و درخواست ریکت و انگولار با توجه به پشتیبان های یکه این دو دارن خیلی بیشتر از ناک اوت هست و خواهد بود و مخصوصا که با اومدن آیونیک و ریکت نیتیو به بازار موبایل هم گسترش پیدا کردننقل قول:
من به مدت 3 ساله که تمامی وب سایتهای خودم رو با ناک اوت (knockout) پیاده سازی میکنم. با react و angular هم کار کردم ولی به نظرم سینتکس و سبکی ناک اوت نسبت به بقیه بهتره.
ایجکس چیزی نیست که جیکوئری از خودش در آورده باشه که با حذف جیکوئری هم از بین برهنقل قول:
اگه جی کوئری رو حذف کنیم پس دیگه برای ajax چه اتفاقی می افته ؟من تا حالا هرچی از ajax استفاده کردم با متدهای load و ajax جی کوئری بوده
ایا کتابخانه ای مثل react یا فریم ورکی مثل angular میتونه جایگزین ajax باشه؟
اینجوری فکر کن که جیکوئری یه لایست که امده رو جاواسکریپت قرار گرفته تا دستورات رو ساده کنه
اگر برای دیگران بخواین کار کنید بله از شما angular میخوان ولی اگر خودتون بخواین کار کنید از کسی نمیدونه SPA چیه. در مورد بازار کار زیاد مطمئن نباشید هر آن ممکنه تکنولوژی جدیدی بیاد که بازار رو تحت تاثیر قرار بده. به زودی با انتشار نسخه 2 دات نت core و app جدیدی که دارن روش کار میکنن ناک اوت عرض اندام خواهد کرد.نقل قول:
مشکل اینه که بازار کار و درخواست ریکت و انگولار با توجه به پشتیبان های یکه این دو دارن خیلی بیشتر از ناک اوت هست و خواهد بود و مخصوصا که با اومدن آیونیک و ریکت نیتیو به بازار موبایل هم گسترش پیدا کردن
angular بطور درونی از نسخه سفارشی jquery که jqlite نامیده میشه استفاده میکنه. همچنین در تمامی این کتابخونه ها امکاناتی (نه در حد jquery) برای درخواستهای ایجکس پیشبینی شده.نقل قول:
اگه جی کوئری رو حذف کنیم پس دیگه برای ajax چه اتفاقی می افته ؟من تا حالا هرچی از ajax استفاده کردم با متدهای load و ajax جی کوئری بوده
ایا کتابخانه ای مثل react یا فریم ورکی مثل angular میتونه جایگزین ajax باشه؟
خود من به شخصه کدهای ajax رو از jquery جدا کردم و بطور مستق در پروژه هام استفاده میکنم. حجم این کدها بدون فشرده سازی 20 کیلوبایت و با فشرده سازی به 8 کیلوبایت میرسه. و هیچ نیازی هم به jquery نیست مگر اینکه پلاگینهای jquery رو بخواین استفاده کنید که اگر به جاوا اسکریپت مسلط باشین براحتی میتونید اونها رو به جاوا اسکریت محلی تبدیل کنید هرچند اینکار توصیه نمیشه. چون اسکریپتها یکبار لود و کش میشن و نگرانی از بابت سرعت وجود نداره.
استفاده از آنگولار رو در یک شبکه اجتماعی آغاز کردم به جرات میتونم بگم از اون کتابخونه حجیم تنها 30 درصد در پیچیده ترین پروژه ها قابل استفاده ست و این کتابخونه جوری طراحی شده که همه نیازها رو پشتیبانی کنه و دیدگاهی عمومی داره. تزریق وابستگی ها مهمترین امکاناتی هست که در این کتابخونه وجود داره که ناک اوت و react هردو فاقد اون هستن.
برای داشتن سیستم تزریق وابستگی شما با 4 کیلوبایت کد میتونید این سیستم رو پیاده سازی کنید.
من با جی کوئری و jquery-UI تونسته بودم کارهایی مثل تقویم و autocomplete داشته باشم حالا وقتی من شروع به استفاده از react یا انگولار کنم ایا تمام
اونها باید دوباره نویسی بشن؟
پس من از تمام اون امکانات محروم شدم؟
دوباره باید بگردم کتابخانه برای datepicker پیدا کنم که در react و angular پیاده سازی شده باشه؟
این که اشکارا یک گام رو به عقبه
خیر نیازی به برگشت به عقب نیست. بلکه با کمی تسلط به جاوا اسکریپت میتونید از اونها بسیار بهتر و راحتتر استفاده کنید. نگران کامپوننت و پلاگین نباشید همیشه میتونید جایگزینهای بهتری پیدا کنید.نقل قول:
نوشته شده توسط roya_django
شما این قدر شفاف و عمیق پاسخ میدین که در های زیادی رو به روم باز می کنین و باز شدن درهای بیشتر به معنی سوال های بیشتره:
هم انگولار هم react قابلیتی دارند به نام routing که با کمک اون ها می تونیم لینک های مختلفی رو که کاربر ممکنه وارد کنه handle کنیم .
وقتی این قابلیت رو میبینم به علاوه ی تعریفی که از SPA یاد گرفته ام برام سوال پیش میاد که ایا در سایت من فقط باید یک صفحه با پسوند html باشه؟ یعنی مثلا
من فقط یک صفحه ی index.html دارم که بر حسب نیاز کامپوننت های لازم رو return می کنم توش؟ ایا این هدف از تک صفحه ای کردن کار هست؟
یعنی سایتی مثل سایت سنجش یا همین برنامه نویس یا سایت خیلی بزرگی مثل فیس بوک میتونند به این ترتیب پیاده سازی بشن؟
اینکه SPA تنها و تنها یک صفحه ست کمی اغراق آمیزه هرچند قابل انجامه ولی واقعیت اینه که که خیر ما فقط یک صفحه نداریم ولی به شدت تعداد صفحات ما کم هست. معمولا به ازای هر موجودیت و اکشنی (Select، حذف ویرایش، افزودن) ما چندین صفحه داریم که در SPA میشه همه رو به یک صفحه انتقال داد چون لزومی به اونها نداریم.نقل قول:
نوشته شده توسط roya_django
در کل پیاده سازی یک سایت SPA با یک صفحه قابل انجام ولی در بیشتر مواقع باید از چند صفحه استفاده کرد. چون برخی مواقع ناگزیر میشیم تغییرات کلی در صفحه html و body ایجاد کنیم که بهتره برای مثال صفحه لاگین جداگانه طراحی بشه. اینکار علاوه بر کاهش پیچیدگی سبب میشه تا از مسائلی مثل memory leak و کرش کردن مرورگر در ابزارهای ضعیف مثل گوشی و تبلت جلوگیری بشه.