https://virgool.io/feed/@shxhryar Musician / WebHead fa 2026-06-16 21:59:35 https://files.virgool.io/upload/users/129563/avatar/avatar.png?height=120&width=120 https://virgool.io/@shxhryar https://virgool.io/@shxhryar/memoization-with-usememo-usecallback-in-react-msaycg8tazfq هوک‌های useCallback و useMemo هوک‌هایی هستند که توی دسته هوک‌های Memoize قرار میگیرند. یعنی اطلاعات رو در خودشون نگه می‎دارند.بهترین راه برای درک بهتر و کامل هوک‌هایی که "به یاد میسپارند"، این هست که خودمون رو در معرض مشکلی که قراره این هوک‌ها حل کنند قرار بدیم.مثال‌های اولیه از هوک‌ها خیلی این مشکلات رو نمایان نمی‌کنند. اون مثال‌ها یکجورایی هوک‌هارو خیلی منظم و راحت نشون میدند - که البته منطقی هم هست.مشکل اصلی زمانی خودش رو نشون میده که از هوک‌ها بیشتر و بیشتر می‌خوایم استفاده کنیم. اگر چندین و چند ساعت به عنوان یه مبتدیِ کار با هوک‌ها، باهاشون کار کنید، میبینید که توی یه گردابی افتادید که نمیدونید باید دقیقا چیکار کنید.چرا Memoize Hooks ؟خیلی ساده - این هوک‌ها قرار هست چیزی رو به خاطرشون بسپرند.این ساده‌ترین راهیه که میشه این هوک‌هارو تعریف کرد. سوال‌های اصلی و تیزبینانه اینها هستند:چرا باید چیزی یادشون بمونه؟چی به یادشون میمونه؟کِی دوباره به یاد میارند؟توی این مقاله تلاشم این هست که با پاسخ به این سه سوال، هوک‌های Memoize رو بهتر بشناسیم.1. چرا هوک‌ها ( در ری‌اکت ) نیاز دارند که به یاد داشته باشند؟برای اینکه بهتر درک کنیم که چرا نیازه که هوک‌ها به یاد بسپرند ( memoize )، باید در درجه اول انگیزه‌‌ی پشت سر این اتفاق در ری‌اکت رو بهتر درک کنیم. Memoization در برنامه‌نویسی استراتژی محاسباتی هست که توابع، مقدار خروجی اجرای قبلی خودشون رو " به یاد نگه می‌دارند " و ازش به عنوان یک معیار برای محاسباتی بعدی خودشون استفاده می‌کنند.اگر برای چندماهی ری‌اکت نوشته باشید، احتمالا با shouldComponentUpdate و یا PureComponent برخورد داشتید. با کمک این کامپوننت‌ها، تا زمانی که تغییرات state مستقیما بر رابط کاربری ( UI ) تاثیری نداشته باشه، بارگذاری مجددی ( re-rendering ) رخ نمیده.کاملا منطقیه، چون به عنوان مثال اگر کامپوننت App ما ساختاری به شکل زیر داشته باشه:با فرض اینکه Input ما باعث آپدیت state توی App بشه، کل درخت کامپوننت‌های ما ری-رندر میشه. کامپوننت List بارگذاری مجدد میشه، ListItem هم همینطور! محض رضای خدا شاید ما فقط یه چک باکس روی توی Input تیک زده باشیم، چرا باید کل کامپوننت ها ری-رندر بشه؟باشه، شاید من خیلی دارم جو میدم، این ساختار خیلی کوچیکتر از اونیه که ما بخوایم نگران پرفورمنس و بازدهیش باشیم. اما چی می‌شد اگر ما 5 تا 10 تا کامپوننت تو در توی دیگه داشتیم؟ اون زمان فکر کنم باید نگران پرفورمنس باشیم.یک مثال دیگه ای داریم که بهتر نشون میده چه اتفاقی داره میوفته. این صفحه رو باز کنید و بعدش React Dev Tools مرورگرتون رو اجرا کنید و به تنظیمات برید و گزینه‌ی "Highlight Updates" رو تیک بزنید.زمانی دکمه‌‌های افزایش یا کاهش رو کلیک کنید، میبینید که تک تک کامپوننت‌ها فلش میزنند؛ که یعنی دارند ری-رندر میشند :)دقیق‌تر به دکمه‌ها نگاه کنید. ببینید که چطور با کادر آبی نشون میدند که دارند ری-رندر میشند. اگر درست بخوایم در نظر بگیریم، تنها کامپوننتی که باید ری-رندر بشه، کامپوننت Counter هست که مسئول نمایش عدد نهاییه. کامپوننت‌های Button نباید دوباره بارگذاری بشند.همونطور که قبلا هم گفتیم، ری‌اکت از shouldComponentUpdate و یا PureComponent برای کنترل کردن آپدیت‌هایی بدین شکل استفاده میکنه. با کمک اینها ما میتونیم کامپوننت Button رو طوری بازنویسی کنیم که زمانی که Count تغییر میکنه، این کامپوننت مجدد ری-رندر نشه:من دارم به Button با کمک shouldComponentUpdate میگه که " هی! مهم نیست که چه اتفاقی داره میوفته، فقط زمانی دوباره ری-رندر بشو که padding تغییر کرده باشه! " . که یعنی زمانی که count داره تغییر میکنه، دکمه‌های ما دیگه ری-رندر نمیشند. اگر نگران مقایسه‌ی سطحی به شکل this.props.padding !== nextProps.padding هستید ( که بیشتر اوقات باعث نگرانی هم هست ) میتونید از PureComponent استفاده کنید:این ساختار با توجه به چیزی که توی مستندات گفته شده باید کار کنه، ولی بنا به دلایلی برای مثالی که ما اینجا داریم کار نمیکنه. اگر شما دکمه افزایش یا کاهش رو کلیک کنید، میبینید که هردو کامپوننت Button دارند فلش میزنند که یعنی دارند ری-رندر میشند. کجا رو اشتباه کردیم؟باگ ما تابع هست که به شکل props توسط App داره به Button پاس داده میشه. هربار که ری-رندری توی App رخ میده، یک ورژن جدیدی از ساخته میشه و به Button داده میشه. برای همینم Button دوباره ری-رندر میشه.چطور ما این تابع رو کَش کنیم؟ ( cache, ذخیره کنیم؟ )، شاید روش قدیمی bind کردن با کمک this یادتون باشه؟ میتونیم با کمک this این تابع رو توی constructor گره بزنیم. این ترفند درستش میکنه!تبدیل arrow function به یک instance function و گره زدنش با this در constructor. با اینکار میشه تابع رو نبست به رندرهای متعاقب کـَش کرد. کاری کردیم که تابع مقدار آخرین محاسبات خودش رو "به یاد داشته باشه".اینجا میتونید نسخه دمو رو مشاهده کنیددو نکته‌ای که از این مشاهدمون بدست آوردیم اینه که:دیدیم که چطور میتونیم با کمک shouldComponentUpdate و PureComponent ری-رندر شدن کامپوننت رو کنترل کنیم.همچنین دیدیم که چطور میتونیم توابع رو memoize کنیم تا از ری-رندر شدن الکیشون جلوگیری بشه.مسئله اینجاست که این دو نکته تنها در class component ها امکان پذیر هستند و در functional component ما نمیتونیم چنین ساختاری داشتیم باشیم، چون:فانکشنال کامپوننت‌ها نمیتونند instance از متد‌ها داشته باشند، پس sCU در کار نیست.فاکنشنال کامپوننت‌ها نمیتونند کلاس‌های دیگه ای رو Extend کنند، پس خبری از PureComponent نیستفانکشنال کامپوننت‌ها constractor ندارند، پس نمیتونیم متد‌ها رو اونجا کش کنیم.هوک‌های Memoize به فانکشنال کامپوننت‌ها کمک می‌کنند که بتونند از پس چنین چالشی بر بیانداین جواب سوال اول مارو میده: چرا این هوک‌ها نیاز دارند که به یاد داشته باشند؟ چرا ما به memoize کردن احتیاج داریم؟یک جدولی درست کردم از مقایسه memoization با هوک‌ها در مقابل کلاس کامپوننت‌ها2. چرا این هوک‌ها به یاد میسپارند؟سوال اول تقریبا جواب این سوال رو هم به شکل ضمنی داد. نیازه که این هوک‌ها ( Memoized Hooks ) اطلاعات و یا توابع رو به خاطر بسپارند تا:از ری-رندر شدن غیرضرروی جلوگیری کننداطلاعات و یا توابع رو نگه میدارند ( کش / cache کنند ) تا کپی جدیدی ازشون ساخته نشه3. کی به یاد می‌آورند؟جواب این سوال تقریبا خیلی مشخصه - زمان ری-رندر به یاد میارند.رابطه بین Data Hooks و Memoize Hooksهوک‌های اطلاعات، هوک‌هایی هستند که اطلاعات رو در خودشون ذخیره می‌کنند. ذخیره کردن با نگه‌داشتن اطلاعات متفاوته. شما اطلاعاتی که قسمتی از تغییرات UI بهش وابسته هست رو ذخیره میکنید ( store ) و بخشی از اطلاعاتی که اون قسمت از UI مستقیما باهاش در ارتباط نیست رو به شکل کَش نگه می‌دارید.یک خط مبهم و باریک هم این وسط هست. useRef هوکیه که میتونه هر دو نقش رو بازی کنه. بستگی داره شما چطور ازش استفاده کنید.بطور کلی useState و useRef ( و همچنین useReducer ) هوک‌های اطلاعات هستند و useCallback , useMemo هوک‌های کش کردن و memoize هستند. با کمک تصویر زیر بهتر میتونید محدوده کارایی این هوک‌ها رو ببینید:کش کردن اطلاعات با کمک useMemoهوک useMemo ذاتا یه هوک memoize ـه و اینطوری طراحی شده. بقیه هوک‌ها مثل useCallback و useRef یجورایی با توجه به شرایط اینجوری هستند. این هوک یه تابع رو با رفرنسی به مقادیر وابسته به اون تابع میگیره و فقط زمانی این تابع رو اجرا میکنه که اون مقادیر تغییر کرده باشند. نکته مهم: این هوک موقع اجرا، تابعی که در بر گرفته رو اجرا میکنه و مقدار برگشتی اون تابع رو برگشت میده.مثالی که اول مقاله داشتیم رو دوباره به شکل فانکشنال بازنویسی کردم، و میبینید که دوباره برگشتیم به جایی که دکمه‌ها هم موقع آپدیت، ری-رندر میشندمیتونیم Button رو با تمام مقادیری که بهش پاس دادیم توی useMemo قرار بدیم، یا بهتر بگم میتونیم useMemo رو دور Button بکشیم. چون ما میخوایم که تحت هیچ شرایطی این دکمه‌ی ما ری-رندر نشه:فقط دکمه‌ی increment رو با useMemo گرفتم و همونطور که فلشر‌های آپدیت نشون میدند، دکمه‌ی increment ما ری-رندر نمیشه و فقط Decrement داره هربار ری-رندر میشه:اما یه سوتی اینجا رخ داده! وقتی که دکمه افزایش رو میزنیم، با اینکه ری-رندر نمیشه، ولی فقط یکبار عمل میکنه و دیگه کار نمیکنه!خب باید بگم که اینکار رو عمدا انجام دادم تا بهتون نشون بدم که باگ‌هایی شاید با memoization رخ بده. من دارم تابعی رو memoize میکنم که کل کامپوننت رو برگشت میده، این یعنی نتیجه اولین محاسبات این تابع داره کش میشه و به همین دلیل هی به شما همون جواب رو میده. میتونید ببینید که count روی 1 گیر میکنه و هرچی شما کلیک میکنید، فقط 1 نمایش داده میشه.اگر فقط میخواستیم یک مقدار استاتیک رو لاگ کنیم، یا میخواستیم یک عملیات رو برای یکبار انجام بدیم که این عملیات به مقدار state بعدی ما وابسته نبود، این راه بهترین راه برای انجام اینکار بود، برای مثال:جمله‌ی ' I got clicked ' هربار لاگ میشه که این یعنی تابع همیشه اجرا میشه. مشکل اینجاست که تابع کش شده و از مقدار state بعدی اپلیکیشن شما بی خبره.این مسئله رو با پاس دادن count به آرایه مقادیر وابسته‌ی useMemo میتونید حل کنید، ولی اینکار دوباره باعث ری-رندر شدن button ها میشه که خب یجورایی هدف ما از انجام memoize کردن رو از بین میبره.ری‌اکت یک روش متفاوت دیگه‌ای داره که میتونه جایگزین PureComponent بشه، و اون memo هست. اگر ما کامپوننت Button رو با React.memo ( نه React.useMemo ) در بر بگیریم، مثل اینجا:متاسفانه با اینکار هم حتی Button با هر کلیک ری-رندر میشه، چون همچنان تابع ما کش نشده. شاید راه حلی که به ذهنتون برسه اینه که میتونیم بجای اینکار از useCallback استفاده کنیم:و بعد هم اینطوری به کامپوننتمون پاسش بدیم:متاسفانه همچنان بازهم این روش کار نمیکنه چون اینبار count ما در closure میوفته و فقط به 1 آپدیت میشه و ما دوباره همون نتیجه‌ایی رو میگیریم که با useMemo داشتیم.در حال حاضر تنها راهی که میشه انجام داد اینه که Button رو به کلاس کامپوننت برگردونیم و از shouldComponentUpdate و گره زدن توی constructor استفاده کنیم.اینکه useMemo نتونست توی این شرایط کمکمون کنه دلیل بر این نیست که خوبی‌های خودش رو نداره. توی قسمت بعدی که میخوایم در مورد useCallback صحبت کنیم، مثال‌هایی رو میبینیم که با کمک useMemo میتونیم چطور توابع رو کش کنیم. نقطه قوت useMemo بیشتر جاییه که شما یه محاسبات خیلی سنگینی دارید و نمیخواید که این محسبات هر دفعه اجرا بشه و فقط تنها زمانی اجرا بشه که مقدار جدیدی وارد معادله شده.مقایسه تاثیر useMemo روی محاسبات سنگین رو توی این مثال ساده میتونید ببینید. همچنین Brian Holt هم توی این مثال فوق‌العاده تمام هوک‌های رایج رو باهم مقایسه کرده. ببینید که چطور useMemo و useCallback رو مثال زده.کش کردن اطلاعات با useCallbackیه Counter دیگه‌ای رو در نظر بگیرید که به مقدار count وابسته نباشه، مثلا:کامپوننت کانتر جدید ما و دکمه‌های داخلش با anotherCount کنترل میشه ، و کاملا بی ربط به کامپوننت counter اول ما هستند. فکر میکنید زمانی که یکی از چهارتا دکمه رو کلیک کنیم، چه اتفاقی میوفته؟ اینجا تست کنیدازونجایی که state توی کامپوننت App ما داره کنترل میشه، هر تغییری چه توی count و یا anotherCount باعث ری-رندر شدن App میشه و این کامپوننت با تمام بچه‌هاش دوباره ری-رندر میشهاگر ما ما تابع‌هایی که روی دکمه‌های count هستند رو با کمک useCallback کش کنیم، اینجوری میتونیم از ری-رندر شدن بی دلیل اونها جلوگیری کنیم:با اینکار چیزی که داریم به ری‌اکت میگیم اینه که:" ببین، زمانی که App شروع بعه ری-رندر کرد، چک کن ببین که count اگر تغییر کرده، فقط دکمه‌های count رو ری-رندر کن. اگر فقط anotherCount تغییر کرده، پس اینهارو دیگه ری-رندر نکن"مقدار count به عنوان استدلال دوم به تابع useCallback پاس داده شده تا تنها در صورتی این تابع اجرا بشه که تغییری در count رخ داده باشه. اگر شما مقدار count رو پاس ندید، دوباره همون مشکلی که داشتیم رخ میده، یعنی هی ما توی هر رندر مقدار 1 رو دریافت میکنیم:حتی میتونید کامپوننت Counter اولی رو با کمک React.memo تبدیل به PureComponent کنید تا زمانی که anotherCount تغییری کرد، این کامپوننت ری-رندر نشه.تفاوت useMemo و useCallback:1. هوک useMemo "مقدار" کش شده رو بازگشت میده؛ و زمانی که بخواد آپدیت بشه، فانکشن رو اجرا میکنه و دوباره "مقدار" جدید رو بازگشت میده2. هوک useCallback "رفرنس به تابع" رو کش میکنه و اجازه ساخت تابع جدید رو نمیده، زمانی که آپدیتی رخ بده، این هوک "تابع" رو در اختیار شما قرار میده تا دوباره اجرا کنید، به همین دلیل با کمک useCallback شما میتونید argument های متفاوتی به هوک پاس بدید تا هربار فانکشن اونهارو حساب کنه.همچنین گفتن این نکته حايز اهمیته که بدونیم:با این شکل از useMemo، عملکرد یکسانی دارند:پس میتونیم تابع‌هایی که با useCallback کش کرده بودیم رو اینطوری هم بنویسیم:کش کردن اطلاعات با useRefاین هوک در اصل قرار بود مثل class ref عم کنه و درکل ref ها قرار بود که به ما توی دسترسی به DOM node ها کمک کنند.توی تلاش اینکه این نقش توی هوک‌ها هم اجرا بشه، useRef یجورایی تبدیل به یه هوک خیلی قدرتمند شد که نه تنها میتونه به ما کمک کنه تا به DOM node ها دسترسی پیدا کنیم، بلکه:میتونه اطلاعات رو در خودش ذخیره کنهزمانی که تغییری توی اطلاعاتی که ذخیره کرده رخ میده، باعث ری-رندر نشهحتی زمانی که تغییر توی state رخ میده و useState ری-رندر میکنه، بازهم یادش بمونه که چه اطلاعاتی ذخیره داشتهخیلی خفنه نه؟ بریم چندتا مثال ببینیم:برگردیم به همون اپ شمارنده خودمون و بیاین سعی کنیم که بازنویسیش کنیم. مثلا بجای decrementMemoizedCallback بیایم از useRef بجای useCallback استفاده کنیم:هوک useRef میتونه یک مقدار اولیه بگیره، ولی اگر لازم نباشه میتونید بذارید خالی بمونه تا بعدا ست کنید.توی حرکت بعد باید سعی کنید راهی پیدا کنید که تابع برگشتی از decrementMemoizedCallback فقط زمانی اجرا بشه که count تغییری کرده باشه. اینجا جاییه که useEffect میاد وسط:میتونید از اینجا مثال آپدیت شده رو ببینید. میبینید که اولین دکمه Decrement یکبار فلش میزنه و بعد وایمیسته؟ این بخاطر اینه که قانون اول هوک useEffect اینه که حداقل یکبار اجرا بشه. مسلما useRef به قدرت useCallback و useMemo نیست ولی همچنان یه هوک خیلی پرقدرته. اگر توی شرایط درست و به شکل درست ازش استفاده بشه میتونه کلی کمک به ما بکنه. توی مثال بالا ما میتونیم به همون useCallback و یا useMemo برگردیم.امیدوارم ازین مقاله لذت برده باشید، اگر سوالی بود حتما توی قسمت نظرات بپرسید تا باهم به نتیجه برسم. این مقاله ترجمه‌ی این مقاله‌ی بسیار عالی بود و مقالات دیگه‌ رو میتونید از طریق لینک‌های زیر بخونید https://coderlife.ir/classcomponent-vs-functionalcomponent-react-nmlyr2tns0eh https://virgool.io/@shxhryar/hoisting-%D8%AF%D8%B1-%D8%AC%D8%A7%D9%88%D8%A7-%D8%A7%D8%B3%DA%A9%D8%B1%DB%8C%D9%BE%D8%AA-%D8%A8%D9%87-%D8%B2%D8%A8%D8%A7%D9%86-%D8%B3%D8%A7%D8%AF%D9%87-qliuupossapk https://virgool.io/apieco/what-is-jamstack-m4b3ldc6tg3x شهریار شهریار Wed, 16 Sep 2020 17:41:23 +0430 https://virgool.io/coderlife/classcomponent-vs-functionalcomponent-react-nmlyr2tns0eh دقیقا فانکشن کامپوننت‌ها چجوری با کلاس کامپوننت‌ها متفاوتند؟برای مدت زیادی، تنها جوابی که درجا به ذهن میرسید این بود که کلاس کامپوننت ها امکانات بیشتری در اختیار ما میذارند ( مثل مدیریت state ). با اومدن Hooks ها این گذاره دیگه بکار نمیاد.شاید شنیده باشید که یکیشون نسبت به اون یکی پرفورمنس بهتری داره. کدومشون؟ خیلی از اعداد و ارقامی که منتشر میشه ناقص هستند و خیلی نمیشه بهشون اتکایی کرد، منم بر اساس اونها نتیجه گیری نمیکنم. پرفرومنس در درجه‌ی اول به اینکه کدتون دقیقا داره چیکار میکنه بستگی داره، تا اینکه کلاس یا فانکشنال بودن کامپوننت بخواد روش تاثیری بذاره. تا جایی که ما مشاهده کردیم، تفاوت پرفورمنس بسیار ناچیزه، البته استراتژی‌های بهینه سازی کمی متفاوت از این جریان هستند.در هر حالت پیشنهاد ما این نیست که بشینید کدتون رو بازنویسی کنید، اگرم اینکار رو میخواید انجام بدید باید دلایل بیشتری داشته باشید. hooks هنوز در ابتدای راه قرار داره ( مثل خود React در سال 2014 ) و خیلی از بهترین روش‌ها هنوز پیدا نشدند و توی فیلم‌های آموزشی دیده نمیشد.خب این مارو به کجا میرسونه؟ آیا اصلا تفاوت اساسی بین فانکشنال کامپوننت‌ها با کلاس کامپوننت‌ها هست؟ البته که هست، توی الگوی ذهنی.در این مقاله ما به بزرگترین تفاوت بین این دو نگاه می‌کنیم. از زمانی که در سال 2015 فانکشن کامپوننت‌ها معرفی شدند این تفاوت وجود داشت.فانکشن کامپوننت‌ها مقدار (value) رندر شده را ذخیره می‌کنند.بریم ببینیم که این یعنی چی. این کمپوننت رو در نظر داشته باشید:یک دکمه Follow نمایش داده شده که یکجورایی درخواست Follow ( مثل شبکه‌های اجتماعی ) رو با کمک setTimeout شبیه سازی می‌کنه و بعد از 3 ثانیه، پیام تاییدیه رو به شکل alert نمایش میده. اگر prop.user مثلا 'Dan' باشه، بعد از 3 ثانیه پیغام 'Followed Dan' رو نمایش میده. بسیار ساده.( این نکته رو بگم که مهم نیست که در مثال بالا از arrow function استفاده بشه یا function declarations. در هر صورت handleClick کاملا یکسان عمل میکنه )اگر بخوایم مثال بالا رو به شکل کلاس کامپوننت بنویسیم چجوری میشه؟ یکجور ترجمه‌ی ساده انگارانش میشه به این شکل:اینکه فکر کنیم این دوتا کد کاملا یکسال هستند خیلی تفکر رایجیه. مردم اکثرا خیلی راحت و بدون هیچ نگرانی و شناخت تفاوت مفاهیم این دو نوع، کدهاشون رو از این مدل به اون مدل تغییر میدن و فکر میکنند که کاملا یکسان هستند.درواقع، این دو تیکه کد تفاوت ظریفی باهم دیگه دارند. خیلی خوب بهشون نگاه کنید، تفاوتشون رو هنوز پیدا نکردید؟ شخصا برای من خیلی طول کشید تا متوجه تفاوت بشم.کمی پایین‌تر کاملا این تفاوت براتون شفاف و واضح میشه، اما اگر قبلش خودتون میخواید امتحان کنید تا تفاوت رو پیدا کنید، میتونید از این دمو استفاده کنید. کمی جلوتر دقیقا تفاوتشون رو توضیح میدیم.قبل از اینکه ادامه بدیم این نکته رو هم اضافه کنم که تفاوتی که میخوایم راجع بهش صحبت کنیم ربطی به React Hooks نداره. در مثال‌های بالا حتی از Hooks استفاده نشده.این موضوع کاملا در مورد تفاوت فانکشن‌ها و کلاس‌ها در React هست. اگر در نظر دارید که توی برنامه‌هاتون بیشتر از فانکشن‌ها استفاده کنید، به نظرم باید خوب به این تفاوت مسلط بشید.این تفاوت رو ما با یک باگی که خیلی توی اپلیکیشن‌های ری‌اکت شایع هست نشون میدیم.این نمونه مثال رو باز کنید. در این مثال یک منو برای انتخاب پروفایل قرار گرفته، بهمراه دو دکمه فالو کردن که یکی به شکل فانکشنال نوشته شده و یکی به شکل کلاس. هر دو هم میخوان اینکه کی فالو شده رو به شکل alert نشون بدند.حالا این کارها رو به ترتیب انجام بدید:یکی از دکمه‌های فالو رو کلیک کنید.پروفایل انتخاب شده رو قبل از 3 ثانیه تغییر بدید.پیغام نمایش داده شده رو بخونید.مطمئنا متوجه تفاوت عجیب و غریبی میشید:اگر صفحه روی Dan باشه و شما دکمه‌ی فالوی فانکشنال رو بزنید و زیر 3 ثانیه، صفحه رو به Sophie تغییر بدید، میبینید که پیغام نمایش داده شده همچنان 'Followed Dan' ـه.اگر همینکار رو با دکمه فالوی کلاس انجام بدید و زیر 3 ثانیه، صفحه رو تغییر بدید میبینید که پیغام نمایش داده شده میشه 'Followed Sophie'در این مثال، رفتار درست همون اتفاق اول هست. اگر من کسی رو فالو کردم ولی بعد رفتم به پروفایل شخص دیگه‌ای، کامپوننت من نباید گیج بشه که من کی رو فالو کردم. کلاس کامپوننت اینجا گیج میزنه و مسبب باگ میشه.بیاید دقیق‌تر نگاه کنیم که چرا کامپوننت کلاس ما اینطور رفتار میکنه؛ برای اینکار باید متد showMessage ـش رو بررسی کنیم.این متد کلاس ما یوزر رو از روی this.props.user میخونه. توی ری اکت props ها غیر قابل تغییر هستند (immutable). پس هیچوقت نمیتونند عوض بشند. اما اما اما ! این this همیشه قابل تغییر بوده! ?مسلما تمام غایت وجود this توی کلاس‌ها همینه. خود ری‌اکت به مرور اون رو تغییر میده تا بتونه جدیدترین ورژن رو توی متدهای render و lifecycle داشته باشه.پس اگر کامپوننت ما زمانی که درخواستی فرستاده شده ری-رندر بشه، this.props تغییر میکنه. متد showMessage هم user رو از "زیادی جدیدترین" props ما میخونه. این مشاهده مارو در معرض درک جالبی از طبیعت رابط کاربری قرار میده. اگر ما میگیم که رابط کاربری به شکل مفهومی مثل فانکشنی هست که state حاضر اپلیکیشن رو میخونه، پس! event handlers ها ( مثل showMessage ) هم قسمتی از نتیجه render هستند - دقیقا مانند خروجی بصری. event handler های ما "متعلق" به رندر خودشون با state و props همون رندر هستند.بیاید فرض کنیم که فانکشنال کامپوننت وجود نداشت. چطور میتونستیم این مشکل رو حل کنیم؟ما میخوایم که یکجورایی ارتباط render با prop صحیح رو با showMessage که اون prop رو میخونه "تعمیر" کنیم. یکجاهای در مسیر props ما گم میشه.یک راهی که وجود داره اینه که مقدار this.props رو زودتر بخونیم و صریحا اون مقدار رو به تابع showMessage بدیماین روش کامل جواب میده و کار میکنه. اما این روش کد رو به طرز قابل ملاحظه‌ای طولانی میکنه و به مرور زمان مستعد خطا میشه. اگر به بیشتر از یک prop نیاز داشتیم چی؟ اگر همزمان نیاز بود که به state هم دسترسی داشته باشیم چی؟ اگر showMessage خودش یک متد دیگه‌ای رو صدا میزد و اون متد مقدار دیگه ای props رو میخواست بخونه یا میخواست state رو بخونه، ما دوباره همین مشکل رو داشتیم. اون زمان می‌‌بایست مقدارهای this.props و this.state رو به شکل argument به تمام متدهایی که توسط showMessage صدا زده میشدند پاس میدادیم.انجام اینکار تمام ارگونومی‌ای که توسط کلاس‌ها ارائه میشه رو از بین میره. همچنین به خاطر سپردن مسیر کد رو و اجرا رو سختتر میکنه و بخاطر همینم هست که اکثرا برنامه نویس‌ها تمام زورشون رو برای رفع باگ میذارند.بطور مشابه، قراردادن alert درون handleClick هم به نظر نمیاد مشکل مارو حل کنه. ما میخوایم که ساختار کدمون به شکلی باشه که به ما اجازه‌ بده که بتونیم به متد‌های بیشتر و متفاوتی تقسیمش کنیم اما! خیالمون راحت باشه که مقدار state و props صحیح مرتبط با همون رندر-کال خودش خونده و اجرا میشه.این مشکل حتی فقط مربوط به ری‌اکت نیست! شما میتونید این باگ رو با تمام کتابخونه‌های رابط کاربری که از this استفاده میکنند شبیه سازی کنید.شاید اگر متد‌هارو توی constructor قرار بدیم مشکلمون حل بشه؟خیر، این به هیچ وجه مشکل رو حل نمیکنه. یادتون باشه که مشکل ما اینه که مقدار this.props رو داریم دیر میخونیم، ربطی به سینتکسی که استفاده میکنیم نداره! البته اگر کاملا از closure استفاده کنیم مشکل ما حل میشه.اکثرا همه Coluser رو ندیده میگیرند چون شاید درک اینکه یک مقدار در طی زمان میتونه تغییر کنه (mutate بشه) سخت باشه. اما توی ری‌اکت ما این مشکل رو نداریم، چون state و props ما غیرقابل تغییر هستند (حداقل بطور قوی این موضوع پیشنهاد داده شده).این یعنی اگر ما یک state و props رو درون render خودش به دام بندازید (!) میتونید مطمئنا باشید که همیشه مقدار اون دقیقا همون چیزی هست که مربوط به همون render خودشه!توی مثال بالا، تونستید مقدار prop رو زمان رندر ضبط کنید!با این روش، هر کدی درون اون رندر (مثل همون showMessage) صددرصد مقدار props مربوط به همون render رو میبینه. ای‌اکت دیگه مهره‌های مارو تکون نمیده!مثال بالا کاملا درسته ولی در عین حال عجیب هم هست! چه معنی داره از کلاس کامپوننت استفاده کنیم ولی فانکشن‌هامون رو توی متد render تعریف کنیم بجای اینکه بخوایم از متد‌های کلاس استفاده کنیم؟پس، میتونیم خیلی راحت کدمون رو ساده کنیم و اون "پوسته" ی کلاس دورش رو حذف کنیم ?دقیقا مثل مثال قبل، توی این حالت هم props کماکان ضبط و ذخیره میشه - ری‌اکت به شکل آرگیومنت اونارو پاس میده و برخلاف this ، دیگه ابجکت props توسط ری‌اکت mutate نمیشه.حتی اگر از object destruction استفاده کنید این موضوع واضح تر میشه:زمانی که کامپوننت مادر، ProfilePage رو رندر میگیره، ری‌اکت دوباره دکمه‌ی فالو فانکشنال رو صدا میزنه. ولی event handler های ما همچنان "متعلق" به رندر قبلی هستند و مقدار user قبلی رو درون خودشون نگه داشتند و متد showMessage از همون استفاده میکنه.بخاطر همین موضوعه که توی مثال ما، ورژن فانکشنال، زمانی که سوفی رو فالو میکنید ولی درجا پروفایل رو به سانیل تغییر میدید ( رندر جدید ) همچنان مقدار رندر قبلی یعنی 'Followed Sophie' رو نشون میده. چون اون event hanlder متعلق به رندر قبلی بوده، و فانکشنال کامپوننت مقدار قبلی رو توی خودش نگه داشته.این رفتار کاملا درسته!حالا شاید بهتر این جمله رو درک کنیم:فانکشن کامپوننت‌ها مقادیر رندر شده را ذخیره می‌کنند.با هوک‌ها هم میشه این نظام رو برای state ها هم بخوبی اجرا کرد. این مثال رو در نظر بگیرید:این مثال رو اینجا میتونید ببینیدبا اینکه این برنامه‌‌ی ما خیلی مسنجر خوبی نیست، اما نکته‌ی مدنظر مارو بخوبی نمایان میکنه: اگر من پیامی فرستادم، کامپوننت ما نباید گیچ بشه که چه پیامی فرستاده شده. توی این فانکشن کامپوننت ما، message مقدار state ایی که "متعلق" به رندری که تابع event handler توسط مرورگر باهاش صدا زده شده رو ذخیره میکنه. پس مقدار message برابر با اونچیزی هست که موقع کلیک روی 'Send" توی input بوده!خب تا اینجای کار ما میدونیم که فانکشن‌ها توی ری‌اکت بطور پیش‌فرض مقادیر state و props رو ذخیره میکنند. اما چی میشه اگر ما بخوایم "جدیدترین" مقادیر props و state رو بخونیم که "متعلق" به این رندر "نیستند" ؟ چی میشه اگر ما بخوایم اونهارو از "آینده" بخونیم؟توی کلاس کامپوننت‌ها شما خیلی راحت با this.props و this.state این مقادیر رو میخونید، چون خود this تغییر پذیره و همیشه آخرین و جدیدترین مقادیر رو نشون میده. توی فانکشنال کمپوننت هم شما میتونید مقادیر تغییر پذیر داشته باشید که بین تمام رندر‌های کامپوننتتون به "اشتراک" گذاشته بشه. بهش میگن 'ref' :با ref.current شما میتونید جدیدترین مقدار رو بخونید یا بنویسید.البته باید خودتون مدیریتش کنید.هوک useRef یکجورایی توی زمین instance ها بازی میکنه. یکجور راه گریزی به دنیای mutable هاست. حتی بطور بصری میشه this.something رو یکجورایی آینه‌ی something.current دونست؛ مفهوم یکسانی دارند.بطور پیش فرض، ری‌اکت توی فانکشنال کامپوننت هیچ رفرنسی به جدیدترین مقادیر props و state ایجاد نمیکنه. در بیشتر مواقع شما بهش نیازی ندارید، اما اگر در یک شرایطی نیاز داشتید، میتونید به شکل دستی خودتون این رفرنس رو ایجاد کنید:اگر ما مقدار message درون showMessage رو بخونیم میبینیم که زمان کلیک دکمه Send داشتیم رو نشون میده، اما اگر مقدار latesMessage.current رو بخونیم، میبینیم که ما جدیدترین مقدار رو دریافت میکنیم - حتی اگر بعد از کلیک روی Send هم تایپ کنیم باز اون مقدار لحاظ میشه.بطور کلی، بهتره که در زمان رندر خیلی از رفرنس‌ها استفاده نشه، چون اونها تغییر پذیرند و خوبه که ازشون مقادیر رو نخونیم، ما میخوایم که رندرهای ما پیش بینی پذیر باشند. اما اگر تحت شرایطی نیاز بود که آخرین مقدار از state یا prop رو بخونید، اینکه بخواید دستی اینکار رو انجام بدید خیلی آزاردهنده میشه. برای اینکار میتونید از useEffect استفاده کنید:دمو رو اینجا ببینیدبا اینکار، ما مطمئنیم که هربار Dom اپدیت شد رفرنس ما هم آپدیت میشه و این به ما این اطمینان رو میده که تغییر پذیری این مقدار باعث break شدن امکان‌هایی مثل Suspense و Time Slicing نمیشه.توی این مقاله، ما به الگوهایی که باعث خراب شدن کلاس‌ کامپوننت‌ها میشه نگاه کردیم و دیدیم که با کمک Closure چطور میتونیم اون رو حل کنیم. البته شاید متوجه این موضوع شده باشید که زمانی که میخواید hooks هارو با کمک dependency بهینه کنید، باگ‌هایی از سمت closure ایجاد میشه. این به این معنیه که کلوژر مشکله؟ بعید بدونم.همونطور که توی مثال‌های بالا دیدیم، دراصل کلوژر مشکلی که سخت بود دیدنش رو کامل حل میکنه. همزمان هم باعث میشه راحتتر بشه کدی نوشت که توی حالت Concurrent درست کار کنه. این امکان به این دلیل وجود داره که منطق موجود درون کامپوننت ما مقادیر متعلق به رندر خودش رو حفظ میکنه.توی تمام حالت‌هایی که تا به حال دیدم، این مشکل کلوژر بیشتر به این دلیل رخ میده که ما فرض بر این داریم که "توابع تغییر نمیکنند" و یا "مقدار props همیشه ثابت میمونه". موضوع اینه که مسئله اینها نیست و امیدوارم که این مقاله تونسته باشه این رو مسئله واضح نشون بده.فانکشن‌‎ها مقادیر state و props رو درون خودشون ذخیره میکنند. این باگ نیست بلکه خاصیت فانکشنال کامپوننت‌هاست. فانکشن‌‌ها در ری‌اکت همیشه مقادیر خودشون رو ذخیره میکنند - و حالا شما هم میدونید که چرااین مقاله ترجمه‌‌‌ای بود از مقاله‌ای از Dan Abramov از اعضای تیم ری‌اکت و نویسنده Redux.زمانی که این مقاله رو خوندم حیف‌ام اومد که جامعه برنامه‌نویس ایران دسترسی به این مقاله رو نداشته باشه و میدونستم خیلی‌ها شاید هنوز راحت مقاله‌های انگلیسی رو نتونند بخونند. برای همین تصمیم گرفتم حتما این مقاله رو ترجمه کنم و اینجا قرار بدم.مطالب دیگه‌ی من که میتونید بخونید: https://virgool.io/@shxhryar/web-development-roadmap-ikppgzexfssl https://virgool.io/@shxhryar/hoisting-%D8%AF%D8%B1-%D8%AC%D8%A7%D9%88%D8%A7-%D8%A7%D8%B3%DA%A9%D8%B1%DB%8C%D9%BE%D8%AA-%D8%A8%D9%87-%D8%B2%D8%A8%D8%A7%D9%86-%D8%B3%D8%A7%D8%AF%D9%87-qliuupossapk https://virgool.io/apieco/what-is-jamstack-m4b3ldc6tg3x شهریار شهریار Sun, 30 Aug 2020 16:28:08 +0430 https://virgool.io/apieco/what-is-jamstack-m4b3ldc6tg3x زمانی که بحث توسعه تحت وب مطرح میشه، ترکیب تکنولوژی و ابزارهای مختلفی هستند که میشه از بینشون انتخاب کرد. این ترکیب‌های مختلف رو به اسم Web Stack می‌شناسیم. هر وب استک شامل یک سیستم عامل، یک وب سرور ، یک نرم افزار مختص دیتابیس و زبان برنامه نویسی برای بخش فراند-اند و بک-اند میشه. وب استک‌های زیادی هستند که توسعه دهنده می‌تونه با توجه به نیازش و مهارتش از بینشون انتخاب کنه:LAMP Stack: Linux - Apache - MySQL - PHP (Pearl , Phython)MEAN Stack: Mongo - Angular - Express - NodeMERN Stack: Mongo - React - Express - Nodeاما مدتی میشه که انگار سر و کله ی یه تازه وارد پیدا شده و کلی هم سر و صدا به پا کرده، خیلی هم دوروبرش شلوغ شده و همه دارند در موردش سوال میپرسند و میخوان بدونند که چه فرقی با بقیه داره؟ توی چه چیزهایی بهتره و کجاها بهتر استفاده میشه؟JAMStack دقیقا چیه؟در واقع JAMStack بیشتر از اینکه یه ترکیبی از ابزار باشه، یک معماری جدید و مدرن برای ساخت وب سایت و وب اپلیکیشن هاست. گذشت زمانی که وب‌سایت‌های استاتیک فقط یه فایل HTML بودند با یسری CSS و جاوا اسکریپت کنارشون که بهترین حالت فقط ازشون میشد برای سایت رزومه و وبلاگ شخصی استفاده کرد. امروزه ما وب‌سایت های استاتیکی داریم که به شکل Realtime با کاربر تبادل اطالاعات می‌کنند، میتونند فرایند خرید و پرداخت مالی رو انجام بدند و . . .اینکه بخوایم همچنان این نوع وبسایت های جدید رو با اسم "استاتیک" صدا بزنیم، یجورایی انگار داریم ارزش واقعی کاری که دارند انجام میدند رو کمتر جلوه میدیم. برای همین شد که اولین بار Mathias Billmann بنیانگذار وبسایت Netlify از اصطلاح و کلمه ی JAMStack استفاده کرد.الان شاید براتون سوال باشه، خب یعنی پس ما هر زمان داشتیم سایت استاتیک می‌نوشتیم تماما داشتیم با JAMStack سر و کله میزدیم؟ در واقع کلمه‌ی JAM ، از حروف اول سه کلمه‌ی JavaScript , API , Markup ساخته شده، جالب شد نه؟جاوا اسکریپت: یک برنامه کامل که مسئولیت ارسال درخواست‌ها و دریافت جواب‌ها رو به شکل کامل انجام بده و "تماما" در سمت کاربر اجرا بشه.یک API: تمام فعالیت‌های بخش سرور و دیتابیس، توسط یک API از طریق HTTPS و با کمک JavaScript انجام میشه. این API میتونه شخصا نوشته شده باشه، میتونه SaaS باشه یا برای هر شرکت سومی باشه.فایل Markup: فایل‌های مارکاپ که در زمان نوشتن برنامه، پیش نویس میشند و زمان اجرای برنامه توسط یک Static Site Generator ( مثل Gatsby ) در سمت کاربر بازسازی و اجرا می‌شند.خیلی هم عالی! اما خب یعنی چی؟برای یه مدت خیلی طولانی، استفاده از CMS ها بین توسعه دهنده‌های وب خیلی رایج بود. مسیر طراحی و توسعه نسبتا سر راستی داشت و به مشتری‌ها هم این امکان رو میداد که راحتتر محتوای خودشون رو کنترل کنند. اما خب این مسئله تقریبا برای 5 سال پیش بود! تعداد خیلی زیادی از توسعه دهنده‌ها از اون زمان سعی کردند مسیر خودشون رو از CMS ها جدا کنند. کم کم متوجه این موضوع شدند که CMS های سنتی ( مثل وردپرس و دراپال ) یجورای خب ... خیلی داستان رو شلوغش کردند .. ?کم کم این موضوع بیشتر حس شد که چقدر سنگین و بدون انعطاف و خشک هستند و اون پیشخوان ادمین مثلا کاربرپسندشون به مرور زمان کمتر پسندیده می‌شد.. با تشکر از مرورگر‌های مدرن امروزی، میبینیم که با کمک CDN ها و API ها و Static Site Generator ها ، داریم از برنامه‌های داینامیک سمت سرور به سمت برنامه‌های ماژولار سمت کاربر میریم.جم-استک یک انتقال اساسی نگاه و تمرکز از بخش انتزاعیه بک-اند به سمت قدرتمند فرانت-اند محسوب میشهبا کمک JAMStack ما دیگه در مورد تکنولوژی‌های مختلف و سیستم عامل‌ها و وب سرورها و برنامه‌های سمت سرور و دیتابیس صحبت نمیکنیم. این یه روش جدیده که میشه با کمکش وبسایت و اپلیکیشن‌هایی رو ساخت که سبکتر هستند و قدرت اجراییشون بالاست، امنیت بالاتری دارند و هزینه اجرا و توسعه ـشون بسیار کمتره.در حال حاضر، بیشترین نوع توسعه وب اینجوریه که یک بخش فرانت-اند با سرور چفت شده، مثلا node.js و هر درخواستی که داده میشه باید از سرور رد بشه تا بتونه اطلاعات رو از دیتابیس بگیره، اونو به HTML تبدیل کنه و از طریق شبکه بفرسته.درسته که میشه این فرایند رو بهتر کرد، ولی چرا برای هر درخواست هی صفحه رو دوباره بسازیم؟ حتی زمانی که یک صفحه دوبار فراخوانی میشه؟ نمیشه یکبار فایل HTML رو بازسازی کنیم و به تمام درخواست‌ها جواب بدیم؟این دقیقا کاریه که JAMStack انجام میده! در معماری JAMStack، یک درخواست صفحه برای دریافت HTML به سرور نمیره، در عوض html ای که توسط Static Site Generator تولید شده رو از یک CDN "دانلود "میکنه و هیچ سروری توی این مسیر وجود نداره! نقش Static Site Generetor هاچرا JAMStack؟ چون سریعتره: از اونجایی که فایل های HTML از پیش ساختند، پس دیگه لازم نیست درگیر دریافت اطلاعات از دیتابیس و ساخت HTML حین runtime بشیم. فایل html روی یک CDN بازگذاری شده که "نزدیک" به محل کاربره و خیلی سریع میتونه "دانلود" بشه. از اونجایی که html یه فایل استاتیکیه که از یک لینک دانلود شده، خیلی راحت cache میشه و تا زمانی که توسط توسعه دهنده فایل آپدیت نشه، این فایل در cache میمونه.چون امن‌تره: وب سایت‌ها و اپلیکیشن‌های JAMStack از نظر امنیت خیلی خیال مارو راحت می‌کنند. از اونجایی که هیچ سرور و دیتابیسی در کار نیست، لازم نیست نگران حمله و هک سرورها بخوایم بشیم. ( با فرض رعایت تمام نکات امنیتی به شکل صحیح حین نوشتن برنامه )چون ساده‌تره: توسعه دهنده‌های فرانت-اند میتونند با خیال راحت تمرکزشون رو روی تجربه کاربری (UI) بذارند بدون اینکه بخوان درگیر دیتابیس و سرور بشند. چون ارزونتره: از اونجایی که هیچ سروری لازم نیست! یک CDN میتونه خیلی خوب از پس تحویل فایل‌ها و اطلاعات بر بیاد و چون CDN ها فقط دستور "خوانش" رو انجام میدند و عمل "نوشتنی" وجود نداره میتونند تعداد درخواست بالاتری رو پاسخگو باشند و از طرف دیگه لازم نیست ما نگران ترافیک بالای وبسایت باشیم چون CDN ها مقیاس پذیر هستند.جریان کار سنتی در مقابل JAMStack: جریان کار سنتی/رایج:--> ساختن و میزبانی چفت شدست و یکجا انجام میشه--> کاربر درخواست یک صفحه رو میده. فایل ها بعد از یک سری فعل و انفعال (نسبتا طولانی) بین سرور و دیتابیس و کدهای بک-اند و مرورگر پردازش میشند.--> اپدیت‌های اساسی هسته‌ی کد باید (غالبا) از طریق FTP به سرور ارسال بشند و خود دیتابیس نیاز به نگهداری و آپدیت داره.--> تولید و مدیریت محتوا از طریق CMS های سنتی مثل Wordpress یا Drupal انجام میشه.جریان کار JAMStack: --> ساخت و میزبانی فایل‌ها از هم جداست.--> کاربر درخواست یک صفحه رو میده. فایل به شکل کامل کامپایل شدست و مستقیما به مرورگر کاربر از طریق CDN ارسال میشه--> آپدیت‌های اساسی هسته‌ی کد از طریق Git انجام میشه؛ کل سایت با کمک ابزارهای مدرن مثل SSG ها کاملا بازسازی میشه.--> تولید و مدیریت محتوا از طریق Git و یا Headless CMS ها انجام میشه ( Headless CMS رو شاید بعدا یک مقاله براش نوشتم )شروع کار با JAMStack: اگر به تازگی با کل ایده‌ی JAMStack آشنا شدید، احتمالا الان حس سرگردونی خیلی زیادی دارید. اینکه متوجه بشید از کجا باید شروع کرد شاید سخت ترین قسمت قضیه باشه.در درجه‌ی اول، یادتون باشه که ما داریم در مورد توسعه " فرانت-اند محور " صحبت می‌کنیم. اگر درکل در دنیای توسعه وب تازه کار هستید، حواستون باشه که باید توانایی جاوا اسکریپتتون رو تا جایی که می‌تونید بالا ببرید! از طرف دیگه، تا جایی که می‌تونید در مورد API ها و ابزارهایی که میشه باهاشون کار کرد یاد بگیرید. قدرت مانورتون توی کار با API میتونه سطح پروژه هاتون رو به مرحله بالاتری منتقل کنه.پروژه‌ی جدید:شروع کردن از ابتدای داستان همیشه بهترین راه برای درک و ساخت یه JAMStack ـه "خالصه". اینجوری می‌تونید ذره ذره پیش برید و تیکه های ضروری که برای ساختن لازم دارید رو کنار هم قرار بدید. همونطور که قبلا گفتیم، ساخت و میزبانی از هم کاملا جداست، پس در قدم اول باید تصمیم بگیرید که سایت یا اپلیکیشنتون رو با چی میخواید بسازید؟اکوسیستم‌های مدرنی که برای بخش فرانت-اند وجود داره یکم کارتون رو سخت می‌کنه. نه بخاطر کم بودن ابزارها، راستش دقیقا برعکس! هزاران هزار امکان مختلف وجود داره که میشه ازشون استفاده کرد؛ حتی با اینکه بعضی‌هاشون کمی بیشتر شناخته شدند.فریمورک‌های معروف جاوا اسکریپتفریمورک‌های معروف جاوا اسکریپتجاوا اسکریپت امروزه دیگه همه جا هست! و بیشترین جایی که میشه این رو حس کرد، پیشرفتیه که این سه غول دنیای فرانت-اند توی چندسال اخیر داشتند. اونها دنیای وب سایت‌ها رو طوری پیشرفت دادند که الان ما داریم در مورد Single-page-app ها و Progressive Web App ها و نرم افزارهای موبایل تحت وب حرف میزنیم و فکر میکنیم.بسیار بسیار تاکید میشه که قبل از انتخاب کردن یکی از این فریمورک‌ها، حتما جاوا اسکریپت رو بخوبی یاد بگیرید. و همچنین سعی کنید این فریمورک‌ها رو قبل از اینکه بخواید وارد دنیای Static Site Generator ها بشید یاد بگیرید.برای مثال Gatsby با React کار میکنه و بهتر اینه که قبل از یادگیری گتسبی، به ری-اکت مسلط باشید.تولید کننده‌ی سایت استاتیکساده بخوایم بگیم، یه SSG ، محتوا رو میگیره و اونو توی قالب از پیش نوشته شده ( توسط توسعه دهنده ) قرار میده و یک فایل استاتیک ساده‌ی HTML تولید میکنه که آمادست برای رسیدن به کاربر.اون فریمورک‌های معروف جاوا اسکریپت که در بالاتر اشاره شد میشه گفت باعث تولید معروف ترین SSG های حال حاضر شدند. Gatsy و Next برای React و همچنین Next و Gridsome برای Vue. این SSG ها در حال حاضر دارند به طرز شگفت آوری قلمروی Static Site Generator ها رو پیشرفت میدند.Headless CMS ها برای مدیریت بهتراینکه Headless CMS ها دقیقا چی هستند و چه تفاوتی های با CMS های سنتی مثل وردپرس دارند، خودش واقعا میتونه موضوع یک مقاله مفصل باشه، اما در کل بخوام بگم، این نوع CMS ها خوبی های یک سیستم کنترل محتوا رو دارند و بدی ‌هاش رو حذف کردند.توی این نوع CMS ها بخش فرانت-اند و بک-اند کاملا از هم جداست و به هم از طریق API متصل هستند. سعی کردم خیلی ساده بگم .. ( آیا میشه Wordpress رو هم Headless کرد؟ آری .. ? )با کمکشون، میشه خیلی راحت‌تر کاربرها رو مدیریت کرد، یکسری ادیت ها انجام داد و خب مسلما.. محتوا تولید کرد .. ?انتشار و گسترش - امکانات بیشتر با کمک سرویس‌های SaaSوقتی که وبسایت/اپلیکیشنتون رو ساختید، نیازه که یجایی قرار بگیره تا آنلاین بشه و برای اینکار وبسایتهای زیادی هستند.وبسایت‌های ساخته شده با این معماری خیلی خیلی هایپر-داینامیک‌تر از وبسایت‌های استاتیک هستند. با کمک اکونومی API ها و سرویس‌های مختلفی که وجود داره میتونید اپ/وبسایتتون رو با چند کلیک تبدیل به یک پروژه بزرگ کنید.در این مقاله دیدیم که JAMStack چیه و چرا می‌تونیم از این معماری برای پروژه‌های بعدیمون استفاده کنیم. مسلما این معماری جای پیشرفت بسیار بسیار زیادی داره و روز به روز هم داره به تعداد مخاطب‌هاش اضافه میشه.این معماری ابعاد زیادی داره که هرکدومش میتونه مبحث یه مقاله تمام عیار باشه، Headless CMS ها یا Static Site Generator ها ، یا حتی اینکه چطور وبسایت قدیمی حال حاضرمون رو تبدیل به این معماری کنیم؟نوشته‌های دیگه‌ی من https://virgool.io/@shxhryar/web-development-roadmap-ikppgzexfssl https://virgool.io/@shxhryar/hoisting-%D8%AF%D8%B1-%D8%AC%D8%A7%D9%88%D8%A7-%D8%A7%D8%B3%DA%A9%D8%B1%DB%8C%D9%BE%D8%AA-%D8%A8%D9%87-%D8%B2%D8%A8%D8%A7%D9%86-%D8%B3%D8%A7%D8%AF%D9%87-qliuupossapk https://virgool.io/@shxhryar/javascript-runtime-environment-cad9snkl9syj شهریار شهریار Fri, 10 Apr 2020 21:04:17 +0430 https://virgool.io/@shxhryar/%D8%A2%D9%85%D8%A7%D8%B1-%D8%A8%D8%A7%D8%B2%D8%AF%DB%8C%D8%AF-%D9%85%D8%B7%D8%A7%D9%84%D8%A8-%D9%85%D9%86-%D8%AF%D8%B1-%D8%B3%D8%A7%D9%84-%DB%B9%DB%B8-qhnlsiiq0d2g اگر دستاوردی را نتوانم اندازه بگیرم، چیزی در دست ندارم.اشتباه نشود، این به معنای تمایل به بهترین بودن و یا میل به اثبات چیزی نیست، اما تنها چیزی که می‌تواند برای بهتر شدن به من کمک کند یک نقشه راه است، از مسیری که طی کرده‌ام، تا بدانم چه اثری از خود به جا گذاشته‌ام. یک تصویر کلی که بتواند خیلی ساده نشانم دهد تلاش من چه اثری بر جامعه‌ام گذاشته است.ویدیوی آمار مخاطبین من را ببینید: https://cdn.virgool.io/annual-report/1398/akupruvtlcj0-CAiBV.mp4 دستاوردهای من در سال ۹۸در سال ۹۸، من در مجموع ۳ پست در ویرگول منتشر کردم و پست‌های من ۶۸ مرتبه لایک شدند و افراد ۲۶ بار نظرات خود را روی پست‌های من به اشتراک گذاشتند. امسال ۳۴ نفر در ویرگول من را دنبال کردند تا پست‌های بعدیم را بخوانند. اما چیزی که این دستاورد را ارزشمندتر می‌کند اثری است که این پست‌ها از خود به جا گذاشتند.اثر پروانه‌ای منطبق آمار ۸۸۱ بار پست‌های من خوانده شدند و زمانی حدود ۱۷۶,۷۳۹ ثانیه صرف مطالعه آنها شده است، که با توجه به جمعیت ۷۲٬۹۴۰٬۰۰۰ نفری که در ایران به اینترنت دسترسی دارند، من توانستم حدود ۰/۰۰۲۴۲۳ ثانیه، سرانه مطالعه دیجیتال کشور را بالا ببرم. عددی که با تمام کوچک بودنش، اثر بزرگ و ارزشمندی است.اما این عددها فقط توضیحی است از آنچه که برای مخاطبانم به ارمغان آورده‌ام، اثر ارزشمند‌تری که با نوشتن در ویرگول از خود به جا گذاشته‌ام، تلاش پنهانی بوده که برای حفظ محیط زیست کرده‌ام. من با انتشار پست‌های خودم در فضای ویرگول توانستم در مصرف کاغذ صرفه جویی کنم؛ یعنی اگر قرار بود پست‌هایم را چاپ و به دست تک تک خوانندگان برسانم باید ۸,۳۱۵ کاغذ مصرف می‌شد. شهریار شهریار Thu, 26 Mar 2020 22:44:46 +0430 https://virgool.io/coderlife/web-development-roadmap-ikppgzexfssl حالا که به آخر سال نزدیک شدیم، خیلی‌ها شاید برای برنامه‌ریزی هدف سال بعدشون سردرگم باشند. خیلی‌ها شاید ندونند که چه چیزهایی رو نمی‌دونند، دوست داشته باشند چیز جدید یاد بگیرند یا تسلط خودشون رو روی موضوعی که می‌دونند بیشتر کنند.توی این مقاله سعی شده از ابتدا مسیر برنامه‌نویسی تحت وب به شکل کاربردی و قدم به قدم بررسی بشه تا هم اگر کسی میخواد در سال جدید این حرفه/مسیر رو شروع کنه تمام ابعاد رو خوب بشناسه و یا اگر شخصی توی مسیر هست بدونه که تا کجا پیش رفته و چه ابعاد دیگه‌ای هست که می‌تونه روش متمرکز بشه.این مقاله‌ی نسبتا طولانی هست، پیشنهاد می‌کنم یه چایی/قهوه برای خودتون دم کنید و آروم آروم بخونید، خیلی چیزها هست که میخوایم بررسی کنیم و راجع بهشون حرف بزنیم ?بِرَد تراورسی (Brad Traversy) یکی از مدرسین محبوبم در زمینه آموزش توسعه وب، به تازگی ویدیویی منتشر کرده که در اون ابزارها و مباحثی که حس می‌کنه یک توسعه دهنده‌ی وب خوبه که باهاش آشنا باشه رو مرور میکنه.برد سوار موج‌هایی که توی شبکه‌های اجتماعی و انجمن‌ها در مورد چیزهایی که شخص باید بدونه نمیشه و بیشتر سعی میکنه یک دید واقعی و کاربردی رو منتقل کنه. مهمترین نکته‌ای که روش تاکید می‌کنه اینه که سعی کنید اصلا دلهره پیدا نکنید و سردرگم نشید.در این مقاله سعی شده که نکات مهمی که برد در ویدیو بهشون اشاره کرده به شکل خلاصه بررسی و بیان بشه.توسعه وب در سال جدید: چه چیزهایی باید بدونیم؟ هدف اصلی توی این ویدیو اینه که به توسعه دهنده‎ی وب، یک آشنایی کامل با ابزارهای پرکاربرد و پررونق توی این حوزه رو بده." سعی‌ام این نیست که شمارو با تکنولوژی‌های مختلف غرق کنم... اینا انتخاب‌هاییه که میتونید داشته باشید... واقعیت اینه که تکنولوژی‌های ( ابزارهای ) خیلی زیادی وجود داره؛ دلم می‌خواد وقتی مثلا اسم Nuxt یا Gatsby رو شنیدید بدونید که اون چیه.. که بعدش بتونید تصمیم بگیرید میخواید یاد بگیرینش یا نه ... "در وهله‌ی اول بِرَد این موضوع رو مطرح می‌کنه که از خودتون بپرسید که می‌خواید چیکار کنید ( چی کاره بشید؟ ) میخواید توی یه شرکت تولید محصول کار کنید؟ یا به عنوان مشاور کار کنید؟ یا حتی فریلنسر بشید؟ یا برای خودتون بیزینسی راه بندازید؟اکثر نظرها و پیشنهادهایی که برد میده آخرش به این ختم میشه که باید با توجه به هدفی که دارید مسیر و ابزار رو انتخاب کنید. در شروع ویدیو، توصیه اولش یادگیری چیزهایی که خودش اسمشون رو گذاشته "ضروریات"تصاویر از ویدیو گرفته شدند. کلماتی که زیرشون خط کشیده شده، پیشنهاد اول خودش هستندیک نکته‌ای که به وضوح مشخصه: هیچ نیازی به یک کامپیوتر خیلی عجیب و غریبی ندارید." .. برعکسه شاید توسعه‌دهنده‌هایی که توی زمینه ساخت بازی یا اینجور چیزها کار میکنند، شما نیازی به یه کیس بالارده‌ عجیب و غریبی ندارید، یه لپ تاپ یا کیس میان رده یا حتی پایین رده هم میتونه اکثر کارها رو انجام بده.."خودش یکی از طرفدارهای بزرگه VSCode برای نوشتن کده و برای دیباگ کردن کدهاش از کروم استفاده می‌کنه. فایرفاکس مسیر رشد خیلی خوبی داشته و می‌تونه گزینه دوم خیلی خوبی باشه.نظرش اینه که با HTML , CSS یادگیری شروع بشه و بعد ابزارهای جدید CSS مثل Flexbox , Grid یاد گرفته بشند. از نظرش یادگیری ساخت یک وبسایت ریسپانسیو یکی از ضروریات اصلی سال جدید هستند." .. هر پروژه‌ای که کار می‌کنید باید روی تمام دستگاه‌ها ( کامپیوتر، موبایل، تبلت و.. ) خوب نمایش داده بشند .. بجای تکیه روی فریمورک‌های CSS مثل Bootstrap، توصیه می‌کنه که بهتره یاد بگیرید چطور برای خودتون ماژول و کامپوننت CSS تعریف کنید. Bootstrap یا فریمورک‌های دیگه رو می‌تونید هرزمان که دارید روی یک پروژه برای مشتری کار می‌کنید یاد بگیرید.بوت استرپ با اختلاف معروف‌ترین فریمورک CSS هست ولی گزینه‌های خوب دیگه‌ای هم هست یکی از فریمورک‌های متفاوت CSS که بطور مشخصی بهش اشاره می‌کنه Tailwind ـه؛ تمرکز اصلی این فریمورک روی استفاده از ' utility classes ' هاست که با استفاده ازشون می‌تونید به شکلی که خودتون میخواید صفحه رو طراحی کنید.و سورپرایزی نیست که مسلما یادگیری جاوا اسکریپت به شکل خیلی خوب و عمیق، از توصیه‌های اصلیه.مباحثی که توی جاوا اسکریپت (قبل از رفتن سراغ فریمورک‌هاش) باید یاد بگیرید در تصویر لیست شدهبه شکل کاربردی/بهینه یاد بگیریددر تمام طول ویدیو، به شکل مکرر روی این موضوع تاکید میشه که چقدر بهینه پیش رفتن مهمه. آره، هرکاری رو میشه یاد گرفت و انجام داد، اما در بیشتر مواقع کلی راه و روش خوب هست که میشه ازشون استفاده کرد تا بدون اینکه بیش از حد درگیر ابزارهای مختلف بشیم،کار پیش بره.یکی از جالب‎ترین نکاتی که میگه اینه:" .. برای یک وبسایت کوچیک لازم نیست که بخواد DevOps و AWS رو یاد بگیرید. یک سایت میزبان دامنه خوب کافیه. این سایت‌ها اکثرا ابزارهای خوبی برای Deploy (گستردن) و مدیریت دارند. لازم نیست همه چیز رو بیش از حد پیچیده کنیم .. "برای کسایی که تازه وارد دنیای برنامه نویسی تحت وب شدند/می‌خواند بشند، پیشنهاد خوب اینه که با حوزه Front-end ( سمت کاربر ) شروع کنند تا هم با کد زدن آشنا بشند و هم بتونند سریعتر وارد شرایط واقعی کار بشند. با یادگیری حتی مقدماتی این حوزه، این امکان براشون پیش میاد که برای بیزینس‌های کوچیک یا محلی به شکل فریلنسری بتونند وبسایت‌های ساده بسازند." .. میگند که حتما حتما باید یه فریمورک فرانت-اند رو بلد باشین و یاد بگیرید، راستش من اینطور فکر نمیکنم. اگر بخواید می‌تونید حتی بدون فریمورک یک قالب رو طراحی کنید و روی سرور بارگذاریش کنید، به نظرم هیچ مشکلی هم نداره، اما این نکته رو باید در نظر گرفت که خیلی خیلی موقعیت‌های شغلی هست که دنبال کساییند که به فریمورک‌های مثل React یا Vue مسلطند .. "زمانی که حس کردید می‌تونید یادگیری یه فریمورک فرانت-اند رو شروع کنید ( سعی می‌کنم توی مقاله‌ی بعدی توضیح بدم که چه زمانی مناسبه که شخص شروع به یادگیری فریمورک‌ فرانت-اند مثل React یا Vue کنه ) سعی کنید هر سه فریمورک معروف و رایج امروزه یعنی React و Vue و Angular رو تست کنید و ببینید که با کدومش بهتر می‌تونید ارتباط برقرار کنید.برد یه اشاره‌ای هم به Svelte هم می‌کنه ( که البته بیشتر از اینکه فریمورک باشه یه کامپایلره )، اما خودش هم میگه که برای یادگیری توی سال جدید هنوز این فریمورک یکم خیلی نوپا و تازست و پیشنهاد نمی‌کنه که الان سراغش برید.بعد از صحبت‌ها راجع به فریمورک، برد راجع به Server Side Rendering که این اواخر خیلی محبوب شده صحبت می‌کنه. اینکه SSR چی هست و دقیقا چه تفاوتی با Client Side Rendering داره خودش موضوع یک مقاله مفصل و طولانیه، ولی درکل می‌شه اینطور گفت که با این روش شما تمام محتوایی که قراره در مرورگر کاربر نمایش داده بشه رو روی سرور سایت سرهم می‌کنید و بعد به شکل آماده میفرستید برای مرورگر تا نمایش بده؛ در مقابل CSR هست که اصطلاحا مواد خام و محتوای خام رو در اختیار مرورگر قرار میده تا مرورگر بعد از دریافت، در خودش همه چیز رو سرهم کنه و بعد نمایش بده ( چیزی که در سال‌های اخیر کاملا رایج بوده). اینکه کدوم شیوه طراحی رو انتخاب کنید کاملا بسته به پروژه و هدفش می‌تونه متفاوت باشه، ولی در مجموع بدونید که باید با این مفاهیم آشنا باشید.دوتا از ابزارهای معروف که توی این زمینه استفاده می‌شند Next.js (برای React) و Nuxt.js (برای Vue) هست.یکی دیگه از ابزارهای جدیدی که جدیدا رواج پیدا کرده، Static Site Renders هستند که به گفته‌ی خودش لازم نیست که یاد بگیرید، ولی بهتره که باهاشون آشنا باشید. به عنوان مثال سایت‌هایی که با Gatsby کار میشند بسیار سریع هستند و نیازی به سرور ندارند.ابزارهای توسعه و برنامه‌نویسی Back End/سمت سرورزبان‌های برنامه‌نویسی سمت سرور و فریمورک‌هاشونبرای توسعه سمت سرور، برد شخصا Node.js رو پیشنهاد می‌کنه. به علت سرعت بیشتر در نوشتن و هم اینکه می‌تونه از JavaScript در دو سمت کاربر و سرور استفاده کنه. فریمورک پیشنهادیش هم Express هست چون هم خیلی شناخته شدست ( و جامعه فعالی داره ) و هم " .. آزادی عمل زیادی بهتون میده تا بتونید اونطور که میخواید و راحت هستید همه چیز رو بسازید .. "البته این رو هم میگه که از پایتون برای برخی از پروژها استفاده می‌کنه و اون رو هم پیشنهاد می‌کنه." .. پایتون دو فریمورک عالی داره. جانگو بسیار بزرگ و غنی با کلی امکانات ـه و فِلَسک ساده‌تر و مینیمال. چیزهای لازم رو در اختیارتون قرار میدند و بقیه تصمیم گیری‌ها با خودتونه. راستش واقعا نمی‌تونم یکدومشون رو انتخاب کنم، جفتشون رو دوست دارم و روی پروژه‌های متفاوت ازشون استفاده میکنم .. "و در دفاع از PHP هم نکاتی رو میگه:" .. خیلی‌ از برنامه‌نویس‌ها PHP رو جدی نمی‌گیرند و این جای تاسف داره چون PHP واقعا پتانسیل بالایی داره. یک زبان ساده و راحت برای توسعه که هرجایی میشه ازش استفاده کرد. PHP برای کسایی که میخواند به شکل فریلنسری کار کنند انتخاب بسیار عالی ـه! چون می‌تونند خیلی سریع پروژه رو راه اندازی کنند باهاش ( و چون میزان سفارش کارهای فریلنسری بر پایه Wordpress خیلی خیلی بیشتره ). البته اگر قصد دارید که توی یک شرکت بزرگ کار کنید، PHP نمیتونه خیلی انتخاب خوبی باشه، ( چون اکثر شرکت‌ها با PHP کار نمی‌کنند) اما اگر میخواید فریلنسری کار کنید و پروژه‌های خصوصی و کوچک‌تر کار کنید، واقعا انتخاب خوبیه.اینکه برخی برنامه‌نویس‌ها PHP رو مسخره کنند و جدی نگریند یجورایی نماد خفن بودن شده. PHP اولین زبانی بود که من یاد گرفتم و هنوزم ازش لذت میبرم، اگر به کدهای Laravel نگاه کنید میبینید که چقدر کدها ظریف و زیبا هستند .. "پایگاه دادهاکثر وبسایت‌ها نیاز به فضایی برای ذخیره اطلاعات دارند. پایگاه داده یا دیتابیس جایی هست که این اطلاعات ذخیره میشند. دیتابیس‌ها انواع مختلفی دارند و با توجه به نیاز مختلف، میشه ازشون استفاده کرد. شناخت انواع ـشون و یادگیری کار باهاشون بسیار مهمه. لازم نیست در ابتدا همه رو یاد بگیرید. با توجه به اولین پروژه‌تون پایگاه داده مناسب رو انتخاب کنید و با اون شروع کنید. انواع پایگاه داده و تفاوت و معرفیشون هم کاملا می‌تونه یک مقاله‌ی کامل باشه که فکر کنم توی ویرگول مقاله‌های خوبی هست.برد نگاهی به دیتابیس‌ها میندازه و عشق چند ساله‌ی خودش یعنی PostgreSQL رو توصیه می‌کنه.ابزارهای دیگه‌ای که بهشون اشاره شدهزمانی که بخواید با API ها و دریافت اطلاعات به شکل JSON کار کنید، یکی از ابزارهایی که شاید باهاش برخورد کنید، GraphQL هست. اینطور که خود برد میگه: " .. GraphQL چیزی نیست که بخواید همین الان یادش بگیرید، اما می‌تونم بگم که حتما باهاش برخورد می‌کنید چون به نظر نمیاد که یک موج باشه و حالا حالاها موندنیه .. "بعدش سراغ ' Content Management System ' یعنی سیستم مدیریت محتوا ( CMS ) ها میره که چطور راه خودشون رو توی دنیای برنامه نویسی وب باز کردند و شما میتونید ازشون به عنوان یک سمت سرور کامل استفاده کنید و خودتون سمت کاربر رو بسازید." .. فریلنسر‌هایی که با مشتری‌هایی برخورد دارند که می‌خوان خیلی راحت توی سایتشون لاگین بشند و براحتی پُستی ارسال کنند، CMS ها انتخاب خیلی کاربردییه. خیلی‌ها WordPress رو جدی نمی‌گیرند و ازش ایراد میگیرند، اما درصد خیلی بالایی از وبسایت‌های کل اینترنت با وردپرس اجرا می‌شند و هنوز از محبوبیت بالایی برخورداره .. "برای وب‌سرور پیشنهادش NGINX ـه نسبت به Apache چون " .. خیلی کمتر پیچیده به نظر میاد .. "از دید اون، تصویرسازی خیلی می‌تونه توی حل مسئله و ساده کردن پروژه‌های پیچیده کمک کنه. " .. یکی از ابزارهای خوب توی این زمینه Docker ـه، البته از اینکه میگند همیشه باید از داکر استفاده کرد خوشم نمیاد؛ میتونه فقط یه مرجع باشه. اگر میخواید که خیلی راحت با یه LAMP سرور کار کنید هیچ مشکلی نیست و اصلا احساس نکنید حتما باید کار با Docker رو یاد بگیرید.. "و یه موضوع خیلی مهمی رو اشاره می‌کنه که واقعا ارزش تاکید و اشاره رو داره:" میدونم خیلی‌ خوره‌ها (nerds) الان هستند که دوست دارند تا جای ممکن همه چیز رو پیچیده کنند.. حواستون باشه که چون اینجا همه چیز لیست شده، دلیل نمیشه که خودتون رو توش غرق کنید .. " و در آخر این نکته رو میگه که خیلی از کمپانی‌ها تیم‌هایی دارند که می‌تونند توی خیلی از این موارد به شما کمک کنندتوانایی‌هایی که به عنوان متخصص خوبه داشته باشیداگر دوست دارید با استفاده از تکنولوژی تحت وب خودتون رو توی محیط توسعه برنامه برای موبایل تست کنید، توصیه برد استفاده از فریمورک Flutter هست. این فریمورک از زبان Dart استفاده می‌کنه. برد زبان Dart رو یکچیزی بین Java و JavaScript تعریف می‌کنه و میگه اگر یکدوم از این دو رو بلدید، میتونید Dart رو راحت‌تر یاد بگیرید.انتخاب دومش برای ساخت برنامه موبایل، React Native هست که خب مسلما اگر React رو بلد باشید، کار با React Native می‌تونه براتون راحت‌تر باشه.حوزه‌ی دیگه‌ای که می‌تونه جالب باشه، Progressive Web Apps هستند. خیلی ساده بخوایم بگیم، با استفاده از تکنولوژی‌های حوزه وب شما می‌تونید وبسایت‌هایی بسازید که مثل یک نرم‌افزار گوشی کار کنند. مثلا اینکه آفلاین هم بتونند یکسری کار‌هارو انجام بدند، یا نوتیفیکیشنی بفرستند و یا . . . درواقع ترکیب دنیای نرم‌افزارهای موبایل با وب. با کمک HTML,CSS,JS می‌تونید شروع به کار توی این حوزه کنید.میرسیم به Electron، ابزاری که بهتون این قابلیت رو میده تا با کمک HTML,CSS,JS برای کامپیوتر‌ها نرم افزار بنویسید. دوتا از معروف‌ترین نرم‌افزارهایی که با این ابزار نوشته شدند، خود ادیتور VSCode و Discord هست.موضوعات پیشرفته‌تر این حوزه میتونه JAMstack یعنی JavaScript , APIs , Markup و معماری بدون نیاز به سرور 'Serverless architecture' باشه که بهش نگاهی بندازید حتما.و بالاخره میرسیم به محبوب‌ترین موضوع این روزها ?یادگیری ماشین و Web Assemblyچون همه دارند راجع به یادگیری ماشین صحبت می‌کنند، دلیل نمیشه شما همه چیز رو ول کنید و بخواید برید یادش بگیرید. برد اینجوری این بخش توضیحات رو شروع کرد ?و اینکه بله، شما میتونید با کمک جاوا اسکریپت یادگیری ماشین رو هم انجام بدید." .. پایتون پادشاه یادگیری ماشین ـه، ولی با جاوا اسکریپت هم شما TensorFlow.js و Brain.js رو دارید که میتونید شبکه عصبی بسازید و کلی کارهای خفن باهاش انجام بدید .. "" .. اسمبلی وب هنوز توی مراحل اولیست، ولی حس می‌کنم تو سال جدید چیزهای بیشتری ازش ببینیم. به شکل سنتی ما از جاوا اسکریپت برای دستکاری کردن DOM و اجرای محاسبات استفاده میکنیم. اما جاوا اسکریپت از دید سرعت کمی محدوده. زبان های مثل C یا C++ خیلی سریعتر از JavaScript هستند. وب اسمبلی یه راه برای نوشتن بهینه کدهای سطح پایین‌تر و اجراشون به کمک مرورگره که واقعا سریعه .. "زبان Rust یکی از زبان‌هاییه که برای اسمبلی وب می‌تونید ازش استفاده کنید؛ به نسبت C و C++ خیلی ساده‌تر میشه یادش گرفت و ازش استفاده کرد.اما یادتون باشه که دلیل نمیشه بخاطر وب اسمبلی نخواین جاوا اسکریپت رو یاد بگیرید!" .. می‌تونید جاوا اسکریپت رو مثل رئیس در نظر بگیرید که میتونه به وب اسمبلی بگه که چیکار باید بکنه. استفاده از زبان‌های سطح پایینی مثل C++ توی مرورگر، این قابلیت رو بهمون میده که روزی بتونیم بازی‌های ویدیویی یا نرم‌افزارهای ادیت ویدیو رو توی مرورگر اجرا کنیم، چیزی که با جاوا اسکریپت خالی نمیشه بهش فکر کرد .. "در آخر: " .. یادتون باشه که هرچی بیشتر یاد بگیرید، یادگیری براتون راحت‌تر میشه، خودتون رو غرق نکنید و سردرگرم نشید، کمی زمان بذارید و فکر کنید که چیکار دوست دارید انجام بدید و راجع بهش تحقیق کنید و بعد آروم شروع به یادگیری کنید .. "? امیدوارم با خوندن این مقاله، مسیر براتون واضح‌تر و منظم‌تر شده باشه و تونسته باشه یک ذهنیت خوب رو جا بندازه.? اگر دوست داشتید پیشنهاد می‌کنم حتما ویدیو اصلی که این مقاله از روش گرفته شده رو ببینید؛ مدت زمان ویدیو 73 دقیقست و مطمئنا کلی نکات ریزی هست که توی این مقاله نگنجیده ولی واقعا می‌تونه مفید باشه? اگر موضوعی یا مفهومی توی این مقاله هست که دوست دارید در آینده براش مقاله‌ای تالیف/ترجمه بشه برام توی کامنت‌ها بنویسید. ? نوشته‌های قبلی من رو هم از لینک‌های زیر می‌تونید مطالعه کنید. https://virgool.io/@shxhryar/hoisting-%D8%AF%D8%B1-%D8%AC%D8%A7%D9%88%D8%A7-%D8%A7%D8%B3%DA%A9%D8%B1%DB%8C%D9%BE%D8%AA-%D8%A8%D9%87-%D8%B2%D8%A8%D8%A7%D9%86-%D8%B3%D8%A7%D8%AF%D9%87-qliuupossapk https://virgool.io/@shxhryar/javascript-runtime-environment-cad9snkl9syj شهریار شهریار Fri, 06 Mar 2020 15:31:56 +0330 https://virgool.io/@shxhryar/hoisting-%D8%AF%D8%B1-%D8%AC%D8%A7%D9%88%D8%A7-%D8%A7%D8%B3%DA%A9%D8%B1%DB%8C%D9%BE%D8%AA-%D8%A8%D9%87-%D8%B2%D8%A8%D8%A7%D9%86-%D8%B3%D8%A7%D8%AF%D9%87-qliuupossapk یکی از چیزهایی که خیلی از توسعه‌ دهنده‎های جاوا اسکریپت باهاش برخورد کردند، کلمه‌ی Hoisting ـه، اونم بخاطر اینه که هربار خطای عجیب غریبی توی برنامه دیدن، تو گوگل سرچش کردند و سر از Stackoverflow در آوردند و اونجا یه بابایی داشت میگفت که این خطا بدلیله Hoisting رخ داده ? خب واقعا Hoisting چیه؟اگر تازه وارد دنیای جاوا اسکریپت شده باشید، احتمالا رفتار عجیبش که بعضی وقتها انگار به شکل تصادفی متغیرها رو با undefined و RefrenceError تعریف می‌کنه رو دیدید. اینجور مواقع اکثرا Hoisting رو اینجوری تعریف می‌کنند: " جاوا اسکریپت ( در زمان اجرا ) تمام متغیرها و توابع رو در بالای فایل قرار میده "؛ اما راستش.. نهه... با اینکه شاید اینطور به نظر بیاد، ولی اینجوری نیست ?زمانی که جاوا اسکریپت فایل اسکریپت مارو دریافت می‌کنه، اولین کاری که برای ذخیره اطلاعاتی که توی کد ما هست میکنه، راه اندازی و چیدمان حافظه ـست . هیچ کدی توی این مرحله اجرا نمیشه، فقط خیلی ساده برای اجرای بهتر برنامه جاوا اسکریپت بدون در نظر گرفتن مقادیر، اعلام توابع و متغیرها رو ذخیره می‌کنه.توی این مرحله، شکلی که اعلام توابع و متغیرها ذخیره می‌شند کمی متفاوته. توابع به شکل کامل و با آدرس‌دهی به کل تابع ذخیره می‌شند.اما متغیرها کمی متفاوت هستند. ES6 دو تعریف جدید برای اعلام کردن متغیرها معرفی کرد: let و const. متغیرهایی که با این دو کلمه اعلام بشند به شکل uninitialized در حافظه قرار می‌گیرند. ( یجور یعنی بارگیری یا شروع نشده )متغیرهایی که با کلمه‌ی var اعلام بشند، در حافظه به شکل undefined ذخیره‎ میشند.زمانی که مرحله چیدمان حافظه تمام شد، برنامه می‌تونه راحت وارد مرحله اجرای کدها بشه. بیاید ببینیم که اگر قبل از اعلام توابع و متغیرها دستور console.log رو در بالای فایل اجرا کنیم چه جوابی میگیریم.از اونجایی که توابع با آدرس‌دهی کامل به کل تابع ذخیره میشند، با فراخوانی‌شون حتی قبل از اعلام کردنشون، میتونیم به شکل کامل بهشون دسترسی داشته باشیم! ?زمانی که قبل از اعلام یه متغیر با تعریف var بخوایم بهش رجوع کنیم، جاوا اسکریپت خیلی ساده مقداری رو که باهاش اون متغیر رو ( توی مرحله قبل ) ذخیره کرده برمیگردونه، یعنی undefiend. اگرچه شاید در بعضی اوقات، این موضوع باعث رفتارهای غیر قابل پیش‌بینی بشه؛ در بیشتر اوقات این معنی رو میده که شما بطور ناخواسته به این متغیر رجوع کردید (در هر صورت فکر نکنم بخواید که جواب متغیرتون undefiend باشه ?)برای اینکه یوقت به شکل تصادفی undefiend رو در جواب به متغیرهای اعلام شده با var دریافت نکنید ( و این باعث گیج شدن برنامه نویس بشه )، هر زمانی که بخواید به متغیرهای let , const قبل از اعلامشون دسترسی پیدا کنید، خطای RefrenceError برگشت داده میشه. این متغیرها قبل از اینکه اعلام بشند، توی شرایطی قرار میگیرند که بهش میگند Temporal dead zone، محیط مرگ موقت؟ میتونیم بگیم برزخ طور، برای همین نمیتونید قبل از اعلام شدنشون فراخوانیشون کنید ( و انتظار مقدار صحیح داشته باشید ) و به همین علت پیغام RefrenceError براتون برگشت داده میشه.زمانی که موتور جاوا اسکریپت ( در زمان اجرای کد ) به اعلام متغیرها میرسه، مقدار اونها رو در حافظه بازنویسی می‌کنه. به آخرش رسیدیم! ? مروری کوتاه:توابع و متغیرها قبل از اجرای کد، برای مرحله اجرا در حافظه ذخیره می‌شند که به این Hoisting میگند.توابع با آدرس‌دهی کامل به کل اون تابع ذخیره میشند، ولی متغیرها متفاوتند. متغیرهای var به شکل undefiend و متغیرهای let , const به شکل uninitialized در حافظه قرار می‌گیرند.✔️ توی کامنت‌ها نظرتون رو راجع به این مقاله بنویسید، براتون مفید بود؟ یا اگر فکر می‌کنید میشه بهتر و ساده‌تر Hoisting رو تعریف کرد حتما حتما برام بنویسید.✔️ اگر موضوعی توی جاوا اسکریپت یا در کل دنیای برنامه نویسی تحت وب هست که دوست دارید راجع بهش مقاله‌ای تالیف/ترجمه بشه حتما برام بنویسید.✔️ این مقاله ترجمه‌ی مقاله‌ی بسیار عالی خانم Lydia Hallie بود که ‌می‌تونید از اینجا متن اصلی رو ببینید.✔️ مطلب قبلی من در مورد جاوا اسکریپت رو هم می‌تونید از طریق لینک زیر بخونید. https://virgool.io/@shxhryar/javascript-runtime-environment-cad9snkl9syj شهریار شهریار Fri, 28 Feb 2020 13:39:23 +0330 https://virgool.io/@shxhryar/javascript-runtime-environment-cad9snkl9syj در این مقاله نگاهی به محیط اجرایی جاوا اسکریپت ( ترجمه‌ی سخت Runtime environment) در بستر مرورگر میندازیم و یاد میگیریم که موتور جاوا اسکریپتِ V8 گوگل، چطور کدها رو تحلیل و تجزیه ( Parse ) می‌کنه و همچنین با نقش حلقه ی رویداد ( Event Loop ) در شرایط Single Thread ، چه به شکل خطی ( synchronously ) و "یک جورایی" غیر خطی ( asynchronously ) آشنا می‌شیم.از اولش شروع کنیم ..هر مرورگر ( مثل کروم، فایرفاکس یا سافاری ) یک محیط اجرایی جاوا اسکریپت داره که یکسری API ها رو در اختیار توسعه دهنده/برنامه نویس میذاره، چیزهایی مثل AJAX , DOM tree , setTimeOut و غیره. اینها جز هسته اصلی خود جاوا اسکریپت نیستند، بلکه آبجکت و متدهایی هستند که مرورگر در محیط اجرایی جاوا اسکریپت خودش در اختیار موتور اصلی برنامه میذاره.در واقع موتور جاوا اسکریپت جزیی از محیط اجرایی جاوا اسکریپت مرورگر هست. هر مرورگر موتور مخصوص خودش رو داره، کروم از موتوری به اسم V8 استفاده میکنه که الان میخوایم نگاهی بهش بندازیم.موتور جاوا اسکریپت V8زمانی که کروم کدهای جاوا اسکریپت رو دریافت میکنه، موتور V8 شروع به تجزیه اونها می‌کنه. در ابتدا کل کدها یکبار چک می‌شند تا مشکل و خطای سینتکس نداشته باشند. اگر در این مرحله خطایی مشاهده نشد، موتور شروع به خوندن کدها از بالا به پایین میکنه. هدف نهایی اینه که کدهای جاوا اسکریپت تبدیل به کدهای ماشین بشند تا کامپیوتر بتونه اونها رو متوجه بشه؛ اما قبل از اینکه بخوایم بفهمیم دقیقا چه اتفاقی داره میوفته، باید محیط اجرایی جاوا اسکریپت در مرورگر رو خوب متوجه بشیم. محیط اجرایی جاوا اسکریپت ( Javascript Runtime Environment )این محیط رو مثل یک ظرف بزرگ (دربردارنده) در نظر بگیرید، یک ظرف بزرگی که درونش چندین ظرف کوچکتر و مستقل دیگه وجود داره؛ زمانی که موتور جاوا اسکریپت شروع به تجزیه و تحلیل کدها میکنه، هر بخشی از کد با توجه به عملکردی که داره درونه یکی از این ظرف‌ها قرار میگیره.تصویر ساده برای درک بهتر این محیطپشته‌ی حافظه ( The Heap )اولین دربردارنده (ظرف) در این محیط که جزیی از موتور اصلی جاوا اسکریپت هست، پشته‌ی حافظه ( شما همون Memory Heap بخونید و به ذهن بسپرید ) نام داره. زمانی که موتور به متغیرها و تعریف توابع می‌رسه اونها رو در اینجا ذخیره می‌کنه تا بعدا زمانی که بهشون نیاز داشت ازشون استفاده کنه.پشته‌ی اجرایی ( The Call Stack )دومین دربردارنده‌ در این محیط، Call Stack نام داره، که این هم جزیی از هسته‌ی اصلی موتور جاوا اسکریپت هست. زمانی که موتور به کدهای اکشن محور و اجرایی میرسه اونها رو در اینجا لیست میکنه تا اجراشون کنه.زمانی که یک تابع در استک لیست میشه، جاوا اسکریپت به سرعت شروع به تجزیه کدش میکنه، متغیرهاش رو از حافظه فراخوانی میکنه، یا اگر تابع‌ یا متد دیگه‌ای لازم داشته باشه اون رو به بالای لیست اضافه می‌کنه یا شاید ( با توجه به نوع تابع ) اون رو به ظرف سوم یعنی Web API بفرسته تا مرورگر مسئولیتش رو به عهده بگیره.زمانی که تابع مقداری رو برگردونه یا بسته به شرایطش به ظرف Web API ها ارسال بشه ، فورا از لیست استک حذف می‌شه و تابع بعدی در دستور کار برای تجزیه شدن قرار میگیره. اگر موتور جاوا اسکریپت یک تابع رو کامل حل کنه ولی مقدار مشخصی به شکل صریح ( explicitly ) برگردونده نشده باشه، موتور بطور خودکار مقدار "تعریف نشده ( undefined ) " رو برگشت میده و تابع رو از لیست اجرایی خارج میکنه. این نوع پردازش توابع در جاوا اسکریپت که توابع رو دونه دونه حل میکنه و از لیست اجرایی خودش خارج می‌کنه ( و منتظر مقدار نمیمونه اگر در لحظه درش برگشت داده نشه ) همون چیزی هست که باعث میشه از جاوا اسکریپت به عنوان یک زبان خطی ( synchronous ) نام ببرند. در هر لحظه فقط یک پردازش انجام میده.نکته مهم: ساختار داده در پشته اجرایی جاوا اسکریپت ( Call Stack ) به شکل Last In, First Out هست (LIFO). به غیر از تابعی که در بالای لیست قرار داره، هیچ تابع دیگه‌ای مورد توجه و تحلیل قرار نمیگیره و تا موتور تابع رو حل نکنه ، سراغ تابع بعدی نمیره مگر اینکه یا تابع رو کامل حل کنه یا اون رو به عهده ی مرورگر بذاره. قسمت Web APIزمانی که موتور جاوا اسکریپت به توابع و کدهایی مثل event listeners , HTTP/AJAX request و یا در کل توابعی که در زمان خاصی اعمال میشند میرسه، اونها رو به اینجا میفرسته تا مرورگر مسئولیتش رو به عهده بگیره و در زمان درست، مرورگر اون عمل خاص رو بهش "یادآوری" کنه. این عمل میتونه یک "کلیک" کاربر در جای خاصی از صفحه باشه، یا یک درخواست دریافت اطلاعات از منبع‌ای خارجی. زمانی که هر کدوم از این نوع اعمال اجرا شد، تابع برگشتی اون به لیست انتظار توابع برگشتی ارسال میشه.دلیل این نوع برخورد جاوا اسکریپت اینه که زمان بارگذاری یک صفحه ( از اونجایی که توابع رو یک به یک حل میکنه و خطی پیش میره ) منتظر حل شدن یک تابع نباشه تا مقدارش کامل دستش برسه و بعد بره سراغ تابع بعدی. فرض کنید شما در سایتتون یک درخواست به سایت خارجی دیگه ای فرستادید؛ موقع بارگذاری صفحه اون درخواست ارسال میشه، اگر قرار باشه موتور جاوا اسکریپت تا زمان برگشت مقدار، صفحه رو بارگذاری نکنه، همه چیز با مشکل مواجه میشه. برای همین، موقعی که موتور جاوااسکریپت با چنین توابعی مواجه میشه، درخواست رو ارسال میکنه و تابع رو از لیست اجرایی خودش خارج میکنه ( تا به سراغ تابع بعدی بره ) و مسئولیت اون تابع با مرورگر میمونه تا زمانی که مقداری برگشت داده بشه. صف انتظار Callback هادر این لیست، تمام توابع برگشتی از سمت Web API در صف قرار می‌‎گیرند. نکته‌ی بسیار مهم این هست که این توابع برای اجرا شدن باید تا "خالی شدن" پشته‌ی اجرایی "صبر" کنند. زمانی که پشته‌ی اجرایی کاملا خالی شد، این توابع برای اجرا شدن به اونجا ارسال میشه. زمانی که دوباره استک خالی شد، تابع برگشتی بعدی به اونجا ارسال میشه.نکته مهم: ساختار داده‌ای این قسمت به شکل First In, First Out هست (FIFO). در استک از متد Push , Pop ( اضافه کردن به آخر لیست و برداشتن از اول لیست ) اجرا می‌شد اما در این قسمت متد Push , Shift اجرا میشه ( اضافه کردن به اول لیست و برداشتن از اول لیست )حلقه رویداد ( Event Loop )خب فکر کنم با صحبت‌هایی که تا اینجا شد، خیلی راحت کار حلقه رویداد براتون مشخص بشه. کار این قسمت اینه که به شکل مداوم callback queue و call stack رو چک کنه تا ببینه کی اون لیست خالی میشه یا آیا تابعی در صف قرار گرفته یا نه. شاید در زمانهایی، callback queue و call stack هردو کاملا خالی باشند، ولی Event Loop هرگز غیرفعال نمیشه و دائما در حال چک کردن هردوتاست. زمانی که اولین فانکشن به صف انتظار از سمت مرورگر وارد بشه، EL خیلی سریع Call Stack رو چک میکنه و اگر خالی بود، تابع رو به اونجا ارسال میکنه.زمانی که گفته میشه جاوا اسکریپت به شکل غیرخطی ( asynchronously ) اجرا میشه، منظورشون همینه، در واقع به شکل تکنیکی این حرف غلطه، چون توی واقعیت چنین اتفاقی نمیوفته، ولی اینطور به نظر میاد که انگار جاوا اسکریپت داره چند وظیفه رو به شکل همزمان دنبال میکنه. جاوا اسکریپت در هر لحظه فقط میتونه یک وظیفه رو دنبال کنه و اونم تنها در بالای لیست Stack، اما با کمک Web API هایی که مرورگر در اختیارش قرار میده، میتونه وظایفی که منجر به انتظار هستند رو به مرورگر بسپره و مرورگر در زمان وقوع، اونها رو به صف انتظار بفرسته تا جاوا اسکریپت اونهارو اجرا کنه.مسدود کردن / عدم مسدود کردنوقتی در مورد مسدود کردن صحبت می‌کنیم، به یک حلقه‌ی بینهایت فکر کنید؛ زمانی که یک تابع دائما در حال اجرا باشه. اگر تابع همچنان در حال اجرا باشه هیچوقت از لیست اجرایی خارج نمیشه و در این صورت جلوی اجرا شدن توابع بعدی رو میگیره و یکجورایی اونها رو "مسدود" میکنه. احتمال دیگه‌ای که وجود داره اینه که تابع ما مجبور به انجام محاسبات و منطق پیچیده‌ای باشه که حل شدندش خیلی زمان ببره، طی اون زمان توابع بعدی نمیتونند اجرا بشند و "مسدود" میشند. اینها نکات مهمیه که موقع نوشتن کد برنامه باید در نظر گرفت.نکته‌ی دیگه‌ای که میتونید در نظر داشته باشید، همون مثال HTTP request هست که بالاتر گفتم، اگر قرار باشه بنا به هر دلیلی، جاوا اسکریپت منتظر حل شدن این تابع تا زمان برگشت اطلاعات بمونه، توابع بعدی توی لیست "مسدود" میشند و نمیتونند اجرا بشند. پس همونطور که دیدیم، این کار رو به مرورگر میسپره تا درخواست رو پیگیری کنه.یک مثال ساده برای درک بهتر ..این مثال تو خیلی از ویدیوها و مقاله‌های آموزشی هست، با این مثال شاید بهتر بشه تمام این داستان رو درک کرد...setTimeout(function(){ console.log('Hey, why am I last?'); }, 0); function sayHi(){ console.log('Hello'); } function sayBye(){ console.log('Goodbye'); } sayHi(); sayBye();اگر این کد رو توی کنسول مرورگرتون کپی/پیست کنید، میبینید که به ترتیب مقادیری که دریافت میکنید اول Hello هست، بعد Goodbye ، بعدش undefined و در آخر Hey, why am I last نمایش داده میشه. با اینکه متد setTimeOut در اول فراخوانی شده و زمان تعللش روی 0 ثانیه هست، با اینحال در آخر نمایش داده میشه. کدها رو نگاه کنید و سعی کنید تصور کنید که چه اتفاقی داره پشتش میوفته و موتور جاوا اسکریپت چجوری داره کدها رو تجزیه و تحلیل میکنه. میتونیم باهم بررسی کنیم و ببینیم که موتور V8 گوگل چطور این چندخط کد رو تحلیل میکنه...موتور یکبار کل کدها رو چک می‌کنه تا ببینه خطای سینتکسی وجود داره یا نه. اگر دید که خطایی نیست، شروع به تجزیه کردن کدها میکنه.موتور متد setTimeOut رو میبینه و اون رو توی Call Stack قرار میده.درجا به سراغش میره و میبینه که این متد جزیی از Web API هاست، پس اون رو به ظرف Web API میفرسته و از لیست اجرایی حذفش میکنه.بدلیل اینکه زمان تعلل/تاخیر تابع 0 ثانیست، Web API درلحظه تابع برگشتی رو به صف انتظار میفرسته، Event Loop میبینه که تابعی برای اجرا توی صف قرار گرفته، لیست اجرایی رو چک میکنه تا ببینه اگر خالیه این تابع رو به اونجا منتقل کنه، اما استک خالی نیست چون ....در اولین لحظه‌ای که تابع setTimeOut از استک حذف شد و به Web API فرستاده شد، موتور جاوا اسکریپت تعریف توابع بعدی رو میبینه و اونهارو توی Heap ذخیره میکنه، بعدش فراخوانی تابع sayHi رو میبینه و اون رو به استک برای اجرا شدن میفرسته.تابع sayHi متد console.log رو صدا می‌زنه و اون به بالای لیست اجرا اضافه میشهموتور جاوا اسکریپت سریع سراغ console.log میره و شروع به تجزیه کردنش میکنه و مقدار Hi رو در کنسول چاپ میکنه و متد رو از لیست خارج میکنه.حالا دوباره موتور به تابع sayHi برمیگرده و میبینه که دیگه چیزی برای انجام دادن نیست و به براکت بسته میخوره، پس این تابع رو هم از لیست اجرا خارج میکنه.در لحظه‌ای که این تابع از لیست خارج شد، تابع sayBye به لیست اضافه میشه. تجزیه میشه، متد console.log رو صدا میزنه، در کنسول مقدار Goodbye رو چاپ میکنه، از لیست اجرا خارج میشه، موتور به تابع برمیگرده، اون رو کامل شده میبینه و از لیست اجرا خارج میکنه.حلقه‌ی رویداد ( Event Loop ) بالاخره میبینه که Call Stack خالی شده؛ حالا میتونه اون تابع برگشتی از setTimeOut رو به استک بفرسته تا اجرا بشه. این تابع هم مثل توابع قبلی، متد console.log رو صدا میزنه و روند مشابه به قبلی‌ها رو میره و مقدار Hey, why am I last رو در کنسول چاپ میکنه.شما هم امتحان کنیدبرای اینکه به شکل تصویری بتونید کل این روند رو ببینید، میتونید از این وبسایت استفاده کنید. در این وبسایت به شکل کامل تمام اتفاق‌های درون محیط اجرایی جاوا اسکریپت مرورگر با سرعت آهسته و قدم به قدم اجرا میشه که شما میتونید خیلی راحت هر قدم رو دنبال کنید.امیدوارم از این مطلب لذت برده باشید. سعی میکنم از این به بعد مقاله‌‎هایی که میخونم و فکر میکنم می‌تونند مفید باشند رو اینجا به شکل ترجمه/تالیف بذارم. شهریار شهریار Fri, 21 Feb 2020 18:35:28 +0330