سری ویدیوهای VS Code Day 2021
This is a cumulative servicing update that provides fixes to Microsoft Visual Studio 2015 Update 3. These fixes address high-impact bugs that were either found by the product team or reported by the community. This update will be released on a recurring basis as new bugs are found and fixed. New fixes will be added to the previous fixes
داشتن یک کتابخانهی مدیریت حالت برای برنامههای React بسیار مفید است؛ خصوصا اگر این برنامه پیچیده باشد و برای مثال در آن نیاز به اشتراک گذاری دادهها، بین دو کامپوننت یا بیشتر که در یک رده سلسه مراتبی قرار نمیگیرند، وجود داشته باشد. اما حتی اگر از یک کتابخانهی مدیریت حالت استفاده شود، شاید راه حلی را که ارائه میکند آنچنان تمیز و قابل انتظار نباشد. با MobX میتوان از ساختارهای پیچیدهی شیءگرا به سادگی استفاده کرد (mutation مستقیم اشیاء در آن مجاز است) و همچنین برای کار با آن به همراه React، نیاز به کدهای کمتری است نسبت به Redux. در اینجا از مفاهیم Reactive programming استفاده میشود؛ اما سعی میکند پیچیدگیهای آنرا مخفی کند. در نام MobX، حرف X به Reactive بودن آن اشاره میکند (مانند RxJS) و ob آن از observable گرفته شدهاست. M هم به حرف ابتدای نام شرکتی اشاره میکند که این کتابخانه را ایجاد کردهاست.
خواص محاسبه شده در جاوا اسکریپت
برای کار با MobX، نیاز است تا ابتدا با یکسری از مفاهیم آن آشنا شد؛ مانند خواص محاسبه شده (computed properties). برای مثال در اینجا یک کلاس متداول جاوا اسکریپتی را داریم:
class Person { constructor(firstName, lastName) { this.firstName = firstName; this.lastName = lastName; } fullName() { return `${this.firstName} ${this.lastName}`; } }
const person = new Person('Vahid', 'N'); person.firstName; // 'Vahid' person.lastName; // 'N' person.fullName; // function fullName() {…}
در ES6 برای اینکه تنها با ذکر person.fullName بدون هیچ پرانتزی در مقابل آن بتوان به مقدار کامل fullName رسید، میتوان از روش زیر و با ذکر واژهی کلیدی get، در پیش از نام متد، استفاده کرد:
class Person { constructor(firstName, lastName) { this.firstName = firstName; this.lastName = lastName; } get fullName() { return `${this.firstName} ${this.lastName}`; } }
اگر شبیه به همین قطعه کد را بخواهیم در ES5 پیاده سازی کنیم، روش آن به صورت زیر است:
function Person(firstName, lastName) { this.firstName = firstName; this.lastName = lastName; } Object.defineProperty(Person.prototype, 'fullName', { get: function () { return this.firstName + ' ' + this.lastName; } });
اکنون فرض کنید قسمتی از state برنامهی React، قرار است خاصیت ویژهی fullName را نمایش دهد. برای اینکه UI برنامه با تغییرات نام و نام خانوادگی، متوجه تغییرات fullName که یک خاصیت محاسباتی است، شود و آنرا رندر مجدد کند، باید در طی یک حلقهی بینهایت، مدام آنرا فراخوانی کند و نتیجهی جدید را با نتیجهی قبلی محاسبه کرده و تغییرات را نمایش دهد. اینجا است که MobX یک چنین پیاده سازیهایی را به کمک مفهوم decorators، ساده میکند.
Decorators در جاوا اسکریپت
تزئین کنندهها یا decorators در سایر زبانهای برنامه نویسی نیز وجود دارند؛ اما پیاده سازی آنها در جاوا اسکریپت هنوز در مرحلهی آزمایشی است. Decorators در جاوا اسکریپت چیزی نیستند بجز بیان زیبای higher-order functions.
higher-order functions، توابعی هستند که توابع دیگر را با ارائهی قابلیتهای بیشتری، محصور میکنند. به همین جهت هر کاری را که بتوان با تزئین کنندهها انجام داد، همان را با توابع معمولی جاوا اسکریپتی نیز میتوان انجام داد. یک نمونه از این higher-order functions را در سری جاری تحت عنوان higher-order components با متد connect کتابخانهی react-redux مشاهده کردهایم. متد connect، متدی است که متدهای نگاشت state به props و نگاشت dispatch به props را دریافت کرده و سپس یک کامپوننت را نیز دریافت میکند و آنرا به صورت محصور شدهای ارائه میدهد تا بجای کامپوننت اصلی مورد استفاده قرار گیرد؛ به یک چنین کامپوننتهایی، higher-order components گفته میشود.
برای تعریف تزئین کنندهها، به نحوهی پیاده سازی Object.defineProperty در مثال فوق دقت کنید:
Object.defineProperty(Person.prototype, 'fullName', { enumerable: false, writable: false, get: function () { return this.firstName + ' ' + this.lastName; } });
در ذیل روش تعریف یک تزئین کننده را مشاهده میکنید که دقیقا از یک چنین الگویی پیروی میکند:
function decoratorName(target, key, descriptor) { // … }
function readonly(target, key, descriptor) { descriptor.writable = false; return descriptor; }
class Person { constructor(firstName, lastName) { this.firstName = firstName; this.lastName = lastName; } @readonly get fullName() { return `${this.firstName} ${this.lastName}`; } }
مثالهایی از تزئین کنندهها
برای نمونه میتوان تزئین کنندهی bindThis@ را طراحی کرد تا کار bind شیء this را به متدهای کامپوننتهای React انجام دهد و یا کتابخانهای به نام core-decorators وجود دارد که به صورت زیر نصب میشود:
> npm install core-decorators
@autobind @deprecate @readonly @memoize @debounce @profile
نمونهی دیگری از این کتابخانهها lodash-decorators است که تعدادی دیگر از تزئین کنندهها را ارائه میکند.
MobX چگونه کار میکند؟
انجام یکسری از کارها با Redux مشکل است؛ برای مثال تغییر دادن یک شیء تو در توی پیچیده که شامل تهیهی یک کپی از آن، اعمال تغییرات و غیرهاست. اما با MobX میتوان با اشیاء جاوا اسکریپتی به همان صورتی که هستند کار کرد. برای مثال آرایهای را با متدهای push و pop تغییر داد (mutation اشیاء مجاز است) و یا خواص اشیاء را به صورت مستقیم ویرایش کرد، در این حالت MobX اعلام میکند که ... من میدانم که چه تغییری صورت گرفتهاست. بنابراین سبب رندر مجدد UI خواهم شد.
ایجاد یک برنامهی خالی React برای آزمایش MobX
در اینجا برای بررسی MobX، یک پروژهی جدید React را ایجاد میکنیم:
> create-react-app state-management-with-mobx-part1 > cd state-management-with-mobx-part1 > npm start
> npm install --save mobx
مثالی از MobX، مستقل از React
در اینجا نیز همانند روشی که در بررسی Redux در پیش گرفتیم، ابتدا MobX را به صورت کاملا مستقل از React، با یک مثال بررسی میکنیم و سپس در قسمتهای بعد آنرا به React متصل میکنیم. برای این منظور ابتدا فایل src\index.js را به صورت زیر تغییر میدهیم:
import { autorun, observable } from "mobx"; import React from "react"; import ReactDOM from "react-dom"; ReactDOM.render( <div> <input type="text" id="text-input" /> <div id="text-display"></div> <div id="text-display-uppercase"></div> </div>, document.getElementById("root") ); const input = document.getElementById("text-input"); const textDisplay = document.getElementById("text-display"); const loudDisplay = document.getElementById("text-display-uppercase"); console.log({ observable, autorun, input, textDisplay, loudDisplay });
- با استفاده از observable میخواهیم تغییرات یک شیء جاوا اسکریپتی را تحت نظر قرار داده و هر زمانیکه تغییری در شیء رخ داد، از آن مطلع شویم.
برای مثال شیء سادهی جاوا اسکریپتی زیر را در نظر بگیرید:
{ value: "Hello world!", get uppercase() { return this.value.toUpperCase(); } }
به همین جهت اینبار شیء فوق را توسط یک observable ارائه میدهیم، تا بتوانیم به تغییرات خواص آن گوش فرا دهیم:
const text = observable({ value: "Hello world!", get uppercase() { return this.value.toUpperCase(); } });
input.addEventListener("keyup", event => { text.value = event.target.value; });
autorun(() => { textDisplay.textContent = text.value; loudDisplay.textContent = text.uppercase; });
برای آزمایش آن، برنامه را اجرا کرده و متنی را داخل textbox وارد کنید:
نکتهی جالب اینجا است که هرچند فقط خاصیت value را تغییر دادهایم (تغییر مستقیم خواص یک شیء؛ بدون نیاز به ساخت یک clone از آن)، اما خاصیت محاسباتی uppercase نیز به روز رسانی شدهاست.
زمانیکه mobx را به یک برنامهی React متصل میکنیم، قسمت autorun، از دید ما مخفی خواهد بود. در این حالت فقط یک شیء معمولی جاوا اسکریپتی را مستقیما تغییر میدهیم و ... در نتیجهی آن رندر مجدد UI صورت خواهد گرفت.
یک observable چگونه کار میکند؟
در اینجا یک شبهکد را که بیانگر نحوهی عملکرد یک observable است، مشاهده میکنید:
const onChange = (oldValue, newValue) => { // Tell MobX that this value has changed. } const observable = (value) => { return { get() { return value; }, set(newValue) { onChange(this.get(), newValue); value = newValue; } } }
کدهای کامل این قسمت را میتوانید از اینجا دریافت کنید: state-management-with-mobx-part1.zip
Dynamic Semantics
Objectها علاوه بر داده و رفتار به عنوان توصیفات ثابت، در زمان اجرا دارای یک Local State (a snapshot) از مقادیر داینامیک مربوط به اعضای دادهای خود، میباشند. مجموعه تمام حالاتی که وهلههای یک کلاس میتوانند بین آنها گذر (transition) داشته باشد، dynamic semantics مربوط به کلاس نامیده میشود و به وهلههای کلاس این امکان را میدهند تا به یک پیغام مشابه رسیده و در زمانهای مختلف از چرخه زندگی خود، به اشکال مختلف پاسخ دهند.
Method junk for the class X if (local state #1) then do something else if (local state #2) then do something different End Method
بخش اصلی هر طراحی شیء گرا، dynamic semantics وهلهها میباشد. dynamic semantics هر کلاسی باید در قالب یک دیاگرام state-transition مستند شود. شکل زیر dynamic semantics پروسههای موجود در یک سیستم عامل را در قابل یک دیاگرام حالت نمایش میدهد. این پروسهها توانایی این را دارند که در هر کدام از حالات: runnable، current process، blocked، sleeping و یا در حالت exited، قرار داشته باشند. همچنین به عنوان مثال، یک پروسه زمانی میتواند در حالت current process قرار گیرد که حتما قبلا در حالت runnable قرار داشته باشد. این اطلاعات برای ایجاد تست برای کلاسها و وهلههای آنها میتواند مفید واقع شود.
شکل 2.8 State-transition diagram notation
برخی از طراحان به طور تصادفی، dynamic semantics یک کلاس را به عنوان static semantics آن کلاس مدل میکنند. به عنوان مثال اگر color یکی از اعضای داده ای (data member) کلاس توپ باشد و بعد از وهله سازی از کلاس توپ، color آن بازهم قابل تغییر باشد، منظور اینکه توپ آبی به عنوان یک وهله از کلاس توپ در زمان حیات خود تغییر رنگ دهد، اصطلاحا میگویند: color جزء dynamic semantics کلاس توپ میباشد. با توجه به توضحیاتی که داده شد، حال اگر طراحی برای هر رنگ توپ یک کلاس جدا در نظر گرفته باشد، dynamic semantics را به عنوان static semantics مدل کرده و به احتمال زیاد ما را به سمت ایجاد مشکل Class Proliferation (ازدیاد کلاس ها) سوق خواهد داد.
Abstract Classes
به سوالات زیر توجه کنید:
- آیا هرگز میوه خوردهاید؟
- آیا هرگز پیش غذا خوردهاید؟
- آیا هرگز دسر خوردهاید؟
حال با توجه به سوالات «مزه غذا چطور بود؟ دسری که خوردید، چه تعداد کالری داشت؟ هزینه پیش غذایی که خوردید چقدر بود» پاسخ چه خواهد بود؟
من (نویسنده) ادعا میکنم که هیچ کسی تا به حال میوه نخورده است. بیشتر مردم، سیب، موز و پرتقال خوردهاند؛ میوهی قرمز رنگی به ارزش 3 پوند را نخوردهاند.
شبیه به این مسئله برای زمانی است که گارسون رستوران از شما سوال میکند: «برای شام چه چیزی میل دارید» و شما جواب میدهید: «یک پیش غذا، یک غذای اصلی و یک دسر». در این حالت چون شما دقیقا مشخص نکردهاید چه نوعی میخواهید، گارسون، مات و مبهوت خواهد ماند. همه میدانیم که چیزی تحت عنوان میوه، پیش غذا و یا وهله دسر در واقعیت وجود ندارد؛ بله این عبارات اطلاعات مفیدی را تسخیر میکنند. اگر من در دستم یک ساعت زنگی گرفته و از شما میپرسیدم: «نظرتان در مورد میوه من چیست؟»؛ بدون شک فکر میکردید من دیوانه شدهام. حال اگر در دستم سیبی گرفته و سوال قبلی را میپرسیدم، این بار از نظر شما من یک شخص عاقل بودم.
با وجود اینکه نمیتوان از میوه وهله سازی کرد، اما اطلاعات مفیدی را تسخیر میکند. در واقع میوه، یک کلاسی (concept) است که دانشی از نحوه وهله سازی وهله هایش به وسیله Type پیاده ساز خود، ندارد.
کلاسی که دانشی از نحوه وهله سازی وهلههای خود ندارد، abstract class (کلاس مجرد یا انتزاعی) نامیده میشود.
کلاسی که دانش نحوه وهله سازی وهلههای خود دارد، concrete class نامیده میشود.
در پارادایم شیء گرا، مهمترین استفاده از کلاسهای انتزاعی در مباحث ارث بری مطرح میشود.
Roles Versus Classes
مطمئن باشید انتزاع هایی را که مدل میکنید کلاس بوده و نه نقشهایی که وهلههای آنها بازی میکنند. (Be sure the abstractions that you model are classes and not simply the roles objects play)آیا مادر و پدر به عنوان یک کلاس هستند یا نقشهایی هستند که وهلههای کلاس شخص، بازی میکند؟ پاسخ این سوال وابسته به دامینی (domain) است که طراح در حال مدل سازی آن میباشد. اگر در دامین مورد نظر، مادر و پدر رفتارهای مختلفی دارند، احتمالا باید به عنوان کلاسهای جدا مدل شوند. اگر رفتارهای یکسانی دارند، در نتیجه نقشهای مختلفی هستند که وهلههای کلاس شخص بازی میکنند. به عنوان مثال، میتوان کلاس خانواده را متشکل از وهلهای از کلاس پدر، وهلهای از کلاس مادر و مجموعهای از وهلههای کلاس فرزند در نظر گرفت. در مقابل ممکن است کلاس خانواده را متشکل از وهلهای از کلاس شخص به عنوان پدر، وهلهای از کلاس شخص به عنوان مادر و آرایهای از وهلههای شخص به عنوان فرزندان، مدل کنید. قرار گرفتن در وضیعتی که هر نقش، بخشی از رفتاریهای شخص را مورد استفاده قرار میدهد، کافی نیست و باید مطمئن شوید که رفتارها واقعا متفاوت میباشند. همچنین باید به یاد داشته باشید که زمانیکه وهلهای از بخشی از رفتارهای کلاس خود استفاده میکند، نیز مشکلی وجود ندارد و لازم نیست کلاسهای دیگری را به خاطر این موضوع در طراحی خود در نظر بگیرید.
شکل 2.9 Two views of a family
برخی از طراحان به این شکل تست میکنند که اگر عضوی از واسط عمومی را نمیتوان برای نقش مورد نظر مورد استفاده قرار داد، این موضوع نشان از این دارد که باید برای نقش مورد نظر در طراحی خود کلاس جداگانهای را در نظر داشته باشند. اگر هم عضو مذکور قابل استفاده نباشد، کلاس یکسانی برای نقشهای مختلف استفاده خواهد شد. به عنوان مثال، اگر عملیات ()go_into_labor جزء عملیاتی میباشد که مادر انجام میدهد، در حالیکه پدر چنین عملیاتی را نمیتواند انجام دهد، در این حالت نیز لازم است مادر به عنوان کلاس جداگانهای در نظر گرفته شود. اگر در دامین دیگری، عوض کردن پوشاک را تنها مادر انجام میدهد، در این حالت مادر نقشی از کلاس شخص میباشد، چرا که پدر هم توانایی انجام این عملیات را دارد.
قواعد شهودی فصل دوم
همه دادهها باید در داخل کلاس خود پنهان شده باشند. (All data should be hidden within its class)
استفاده کنندگان از کلاس باید به واسط عمومی آن وابسته باشند، اما یک کلاس نباید به استفاده کنندگان خود، وابسته باشد. (Users of a class must be dependent on its public interface, but a class should not be dependent on its users)
تعداد پیغامهای موجود در قرارداد یک کلاس را کمینه سازید. (Minimize the number of messages in the protocol of a class)
پیاده سازی یک واسط عمومی یکسان کمینه برای همه کلاسها (Implement a minimal public interface that all classes understand [e.g., operations such as copy (deep versus shallow), equality testing, pretty printing, parsing from an ASCII description, etc.].)
جزئیات پیاده سازی، مانند توابع خصوصی common-code ( توابعی که کد مشترک سایر متدهای کلاس را در بدنه خود دارند) را در واسط عمومی یک کلاس قرار ندهید. (Do not put implementation details such as common-code private functions into the public interface of a class)
واسط عمومی کلاس را با اقلامی که یا استفاده کنندگان از کلاس توانایی استفاده از آن را نداشته و یا تمایلی به استفاده از آنها ندارند، آمیخته نکنید. (Do not clutter the public interface of a class with items that users of that class are not able to use or are not interested in using )
اتصال و پیوستگی مابین کلاسها باید از نوع Nil یا Export باشد؛ به این معنی که یک کلاس فقط از واسط عمومی کلاس دیگر استفاده کند یا کاری با آن نداشته باشد. (Classes should only exhibit nil or export coupling with other classes, that is, a class should only use operations in the public interface of another class or have nothing to do with that class.)
یک کلاس باید یک و تنها یک Key Abstraction را تسخیر نماید. (A class should capture one and only one key abstraction)
داده و رفتار مرتبط را در یک جا (کلاس) نگه دارید. (Keep related data and behavior in one place)
اطلاعات نامرتبط به هم را در کلاسهای جدا از هم قرار دهید. ((Spin off nonrelated information into another class (i.e., noncommunicating behavior)
مطمئن باشید انتزاع هایی را که مدل میکنید کلاس بوده و نه نقشهایی که وهلههای آنها بازی میکنند. (Be sure the abstractions that you model are classes and not simply the roles objects play)
RxJS اکنون جزئی از پروژههای گوگل است
توسعه دهندهی اصلی RxJS یا همان Ben Lesh اکنون به گوگل پیوستهاست و جزو تیم Angular است. بنابراین در آینده شاهد یکپارچگی بهتر این دو با هم خواهیم بود. البته RxJS هنوز هم به عنوان یک پروژهی مستقل از Angular مدیریت خواهد شد.
آشنایی با تغییرات RxJS 5.5 جهت مهاجرت به RxJS 6.0 ضروری است
در مطلب «کاهش حجم قابل ملاحظهی برنامههای Angular با استفاده از RxJS 5.5» با pipe-able operators آشنا شدیم و این موارد پایههای مهاجرت به RxJS 6.0 هستند. بنابراین پیش از مطالعهی ادامهی بحث نیاز است این مطلب را به خوبی مطالعه و بررسی کنید.
تغییر رفتار خطاهای مدیریت نشده در RxJS 6.0
تا پیش از RxJS 6.0 اگر خطای مدیریت نشدهای رخ میداد، این خطا به صورت synchronous به فراخوان صادر میشد. این رفتار در نگارش 6 تغییر کرده و صدور آن اینبار asynchronous شدهاست.
برای مثال یک چنین کدی تا پیش از RxJS 6.0 کار میکرد:
try { source$.subscribe(nextFn, undefined, completeFn); } catch (err) { handleError(err); }
برای اصلاح این کد در نگارش 6، همان پارامتر دوم متد را مقدار دهی کنید و try/catch را در صورت وجود حذف نمائید.
تغییرات مهم importها در RxJS 6.0
همانطور که در مطلب «کاهش حجم قابل ملاحظهی برنامههای Angular با استفاده از RxJS 5.5» نیز بررسی کردیم، تا نگارش 5 این کتابخانه، importها به صورت زیر بودند:
import 'rxjs/add/operator/map';
import { map } from 'rxjs/operators';
import { timer } from 'rxjs/observable/timer'; import { of } from 'rxjs/observable/of'; import { from } from 'rxjs/observable/from'; import { range } from 'rxjs/observable/range';
import { interval, of } from 'rxjs'; import { filter, mergeMap, scan } from 'rxjs/operators';
البته RxJS 6.0 در کل به همراه 4 گروه کلی importها است که در زیر مشاهده میکنید (در اینجا مواردی که کمتر در برنامههای Angular به صورت مستقیم استفاده میشوند مانند ajax آن و یا webSocket هم قابل مشاهده هستند):
rxjs rxjs/operators rxjs/testing rxjs/webSocket rxjs/ajax
مواردی که از RxJS 6.0 حذف شدهاند
برای کاهش حجم کتابخانهی RxJS و همچنین جلوگیری از بکارگیری متدهایی که نمیبایستی خارج از کدهای اصلی خود RxJS استفاده شوند، تعداد زیادی از متدهای قدیمی آن و روشهای کار پیشین با RxJS حذف شدهاند. برای مثال شما در RxJS 5.5 میتوانید برای کار با عملگر of، یا آنرا از مسیر rxjs/add/observable/of دریافت کنید (همان روش وصله کردن تا پیش از RxJS 5.5) و یا آنرا از مسیر rxjs/observable/of به روش مخصوص ES 6.0 به برنامه اضافه کنید و یا حتی امکان دریافت آن از مسیر rxjs/observable/fromArray نیز میسر است.
در RxJS 6.0 تمام اینها حذف شدهاند و فقط روش زیر باقی ماندهاست:
import { of } from 'rxjs';
معرفی بستهی rxjs-compat
در مطلب «ارتقاء به Angular 6: بررسی تغییرات Angular CLI» روش ارتقاء وابستگیهای پروژه به نگارش 6 را بررسی کردیم. یکی از مراحل آن اجرای دستور زیر بود:
ng update rxjs
پس از آن اگر پروژه را کامپایل کنید، پر خواهد بود از خطاهای rxjs، مانند:
ERROR in node_modules/ng2-slim-loading-bar/src/slim-loading-bar.service.d.ts(1,10): error TS2305: Module '"/node_modules/rxjs/Observable"' has no exported member 'Observable'.
برای رفع این مشکل و ارائهی راهحلی کوتاه مدت، بستهای به نام rxjs-compat ارائه شدهاست که سبب هدایت تعاریف قدیمی به تعاریف جدید میشود و به این ترتیب کدهای کتابخانهی ثالث، بدون مشکل با نگارش 6 نیز قابل استفاده خواهند بود.
برای نصب آن نیاز است دستور زیر را صادر کنید:
npm i rxjs-compat --save
البته دقت داشته باشید از rxjs-compat به عنوان یک راه حل موقت باید استفاده کرد و نیاز است ابتدا کدهای خود را به روش pipe-able operators بازنویسی کنید و مسیرهای importها را اصلاح کنید و در آخر بستههای جدید وابستگیهای ثالث را که از RxJS6 استفاده میکنند، نصب نمائید. در نهایت rxjs-compat را حذف کنید.
خودکار سازی اصلاح importها در برنامههای پیشین، جهت مهاجرت به RxJS 6.0
با توجه به این تغییرات و حذف و اضافه شدنها در نگارش 6، تقریبا دیگر هیچکدام از importهای قبلی شما کار نمیکنند! و اصلاح آنها نیاز به زمان زیادی خواهد داشت. به همین جهت تیم RxJS ابزاری را طراحی کردهاند که با اجرای آن بر روی پروژه، به صورت خودکار تمام importهای قبلی را به نگارش جدید تبدیل میکند. برای اینکار ابتدا ابزار rxjs-tslint را نصب کنید:
npm i -g rxjs-tslint
{ "rulesDirectory": [ "node_modules/rxjs-tslint" ], "rules": { "rxjs-collapse-imports": true, "rxjs-pipeable-operators-only": true, "rxjs-no-static-observable-methods": true, "rxjs-proper-imports": true } }
rxjs-5-to-6-migrate -p src/tsconfig.app.json
البته توصیه شدهاست این ابزار را بیش از یکبار نیاز است اجرا کنید.
خلاصهی روش مهاجرت به RxJS 6x
ابتدا آخرین نگارش rxjs را نصب کنید:
ng update rxjs
npm i rxjs-compat --save
npm i -g rxjs-tslint rxjs-5-to-6-migrate -p src/tsconfig.app.json
یافتن معادلهای جدید دستورات قدیمی
در حین تبدیل کدهای قدیمی به جدید نیاز خواهید داشت تا معادلها را بیابید. برای این منظور به مستندات رسمی این مهاجرت مراجعه کنید:
https://github.com/ReactiveX/rxjs/blob/master/MIGRATION.md
برای مثال در اینجا مشاهده خواهید کرد که معادل Observable.throw حذف شده، اکنون throwError است و همینطور برای مابقی.
یک مثال واقعی تغییر یافته
مخزن کد تمام مثالهای سایت جاری که پیشتر منتشر شدهاند، به نسخهی 6 ارتقاء داده شد. ریز تغییرات RxJS 6.0 آنها را در اینجا میتوانید مشاهده کنید.
فرض کنید برنامه شما از یک فایل exe به همراه دو اسمبلی A و B، تشکیل شدهاست. اسمبلی A، نگارش یک دارد. اسمبلی B نگارش 2 و کل برنامه در نگارش 2.5 است. خطایی به شما گزارش شدهاست که در آن استثنای حاصل، از نگارش یک اسمبلی A صادر شدهاست. این مشکل که در نتیجهی در یافت پردازش اشتباهی از اسمبلی B بوده و در نگارش 2 آن برطرف شده، به صورت خودکار با ارتقاء به آخرین نگارش برنامه، برطرف میشود.
سؤال: آیا اکنون میتوانید تشخیص دهید کاربر از آخرین نگارش محصول شما استفاده میکند؟ نگارش یک A، آخرین نگارش آن است و اما برنامه در نگارش 2.5 قرار دارد. کاربر هم مدتی است که برنامه را به روز نکردهاست.
یک سیستم از همکاری اجزای مختلف آن مفهوم پیدا میکند.
برای مطالعه بیشتر: «Best Practices for .NET Assembly Versioning». عبارت «ensuring all of the various assemblies in the solution share the same version» حداقل دوبار در آن تکرار شدهاست.