Promises

Promises

اگر مشکلی در گرفتن X یا Y انجام نشد، یا چیزی به نحوی در حین جمع ناموفق بود، وعده ای که add(..) برمی گرداند رد می شود و دومین کنترل کننده خطای برگشتی به آن زمان (..) مقدار رد را از قول دریافت می کند. .

از آنجا که Promises حالت وابسته به زمان را در بر می گیرد – انتظار برای تحقق یا رد ارزش اساسی – از بیرون، Promise خود وابسته به زمان است، و بنابراین Promises می تواند بدون توجه به زمان یا نتیجه زیر به روش های قابل پیش بینی ترکیب شود (ترکیب شود). .

علاوه بر این، هنگامی که یک وعده حل شد، برای همیشه به همین شکل باقی می ماند – در آن نقطه به یک مقدار تغییر ناپذیر تبدیل می شود – و سپس می توان آن را هر چند بار که لازم است مشاهده کرد.

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

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

وعده ها مکانیسمی هستند که به راحتی قابل تکرار برای کپسوله کردن و ترکیب ارزش های آینده هستند.

رویداد تکمیل

همانطور که دیدیم، یک وعده فردی به عنوان یک ارزش آینده رفتار می کند. اما راه دیگری برای فکر کردن به حل و فصل یک Promise وجود دارد: به عنوان یک مکانیسم کنترل جریان — زمانی این-سپس-آن — برای دو یا چند مرحله در یک کار ناهمزمان.

بیایید تصور کنیم که یک تابع foo(..) را برای انجام برخی کارها فراخوانی می کنیم. ما نه از جزئیات آن اطلاع داریم و نه برایمان مهم است. ممکن است فوراً کار را کامل کند، یا ممکن است کمی طول بکشد.

ما فقط باید بدانیم که foo (..) چه زمانی تمام می شود تا بتوانیم به کار بعدی خود برویم. به عبارت دیگر، ما می‌خواهیم راهی برای اطلاع از اتمام foo(..) داشته باشیم تا بتوانیم ادامه دهیم.

در حالت معمولی جاوا اسکریپت، اگر نیاز به گوش دادن به یک اعلان دارید، احتمالاً از نظر رویدادها به آن فکر می کنید. بنابراین می‌توانیم نیاز خود به اعلان را به عنوان نیاز به گوش دادن به یک رویداد تکمیل (یا ادامه) منتشر شده توسط foo (..) مجدداً در نظر بگیریم.

توجه: اینکه آن را “رویداد تکمیل” یا “رویداد ادامه” بنامید بستگی به دیدگاه شما دارد. آیا تمرکز بیشتر بر روی آنچه که با foo(..) اتفاق می افتد، یا آنچه پس از پایان foo(..) اتفاق می افتد؟ هر دو دیدگاه دقیق و مفید هستند. اعلان رویداد به ما می گوید که foo(..) تکمیل شده است، اما همچنین ادامه دادن به مرحله بعدی اشکالی ندارد. در واقع، تماس پاسخی که برای فراخوانی برای اعلان رویداد ارسال می‌کنید، خود همان چیزی است که قبلاً آن را ادامه می‌نامیدیم. از آنجا که رویداد تکمیل کمی بیشتر بر روی foo(..) متمرکز است، که در حال حاضر بیشتر مورد توجه ما قرار گرفته است، ما کمی از رویداد تکمیل برای بقیه این متن حمایت می کنیم.

با تماس‌های برگشتی، “اعلان” پاسخ تماس ما خواهد بود که توسط کار فراخوانی می‌شود (foo(..)). اما با Promises، رابطه را تغییر می دهیم، و انتظار داریم که بتوانیم برای یک رویداد از foo (..) گوش دهیم، و زمانی که اطلاع داده شد، مطابق با آن عمل کنیم.