TypeScript 3.0! نعم ، لقد خرج ، ولديه الكثير من الابتكارات. تحت الخفض ، ستجد وصفاً مفصلاً لجميع أحدث الابتكارات ، بما في ذلك وضع البناء ، ونوع جديد غير معروف ، وتغييرات مهمة في واجهة برمجة التطبيقات ، وتحسينات الأداء ، وأكثر من ذلك بكثير. انضم الآن!
إصدار TypeScript 3.0! بدأ إنجاز جديد على طريق تطوير TypeScript ، وهو مساعد لجميع مستخدمي JavaScript.
إذا لم تكن على دراية بـ TypeScript ، فليس الوقت متأخرًا للتعرف عليه الآن! TypeScript هو امتداد JavaScript مصمم للاستخدام في الإصدار الحديث لهذه اللغة من الأنواع الثابتة. يقرأ برنامج التحويل البرمجي TypeScript رمز TypeScript الذي يحتوي ، على وجه الخصوص ، على إعلانات النوع ونوع التعليقات التوضيحية ، وينتج كود JavaScript نظيف وسهل القراءة يتم فيه تحويل هذه البنى وحذفها. يتم تشغيل الكود الناتج في أي بيئة وقت تشغيل تتوافق مع معيار ECMAScript ، على سبيل المثال ، في متصفحك المفضل أو على منصة خادم Node.js.
يعني استخدام مثل هذه البيئة أنه سيتم تحليل الشفرة بحثًا عن الأخطاء أو الأخطاء المطبعية قبل إطلاقها من قبل المستخدمين ، ولكن مزاياها لا تقتصر على ذلك. مع كل هذه المعلومات ونتائج التحليل ، يعزز TimeScript قابلية الاستخدام من خلال توفير إكمال التعليمات البرمجية وأدوات التنقل مثل البحث عن جميع المراجع والذهاب إلى التعريف وإعادة التسمية في المحرر المفضل لديك. .
لبدء اللغة والحصول على مزيد من المعلومات ، اتبع
الرابط . إذا كنت ترغب في تجربة TypeScript 3.0 الآن ، يمكنك تنزيله من
NuGet أو عبر npm عن طريق الكتابة
npm install -g typescript
بالإضافة إلى ذلك ، يتوفر الدعم في المحررين التاليين:
يتم تحديث
المحررين الآخرين وفقًا للجدول الزمني الخاص بهم ، ولكن قريبًا سيكون لديهم جميعًا دعم TypeScript ممتازًا.
نظرة عامة على الإصدار 3.0
بعد إصدار TypeScript 2.0 ، قدمنا نظرة عامة موجزة عن مساهمة الإصدارات السابقة في حالتها الحالية. بين إصدارات TypeScript 1.0 و 2.0 ، تتضمن اللغة أنواع النقابات ، وحراس النوع ، ودعم معيار ECMAScript الحديث ، والأسماء المستعارة للنوع ، ودعم JSX ، والحرفي والمتعدد الأشكال في
this الأنواع. إذا قمت بتضمين أنواع TypeScript 2.0 التي لم يتم تمكينها بالصفر ، والتحكم في تدفق التدفق ، ودعم النقابات ذات
.d.ts ، وهذه الأنواع ، ونموذج مبسط لاستقبال ملفات
.d.ts ، يمكننا القول أن هذه الفترة حددت الأساسيات تمامًا عمل TypeScript.
إذن ما الذي تم فعله منذ ذلك الحين؟ ما الذي قادنا إلى TypeScript 3.0 ، بالإضافة إلى الميزات الجديدة لمعيار ECMAScript ، مثل الوظائف
async / في
await الوظائف غير المتزامنة والمولدات وعامل الراحة / الانتشار؟
أصبح TypeScript 2.1 الإصدار الأساسي ، الذي قدم نموذجًا ثابتًا للخطأ في جافا سكريبت. طلب المفتاح (
keyof ) ، والوصول إلى الفهرس (
T[K] ) وأنواع الكائنات المعينة (
{ [K in keyof T]: } T[K]} ) - هذه قائمة بالأدوات التي تم استخدامها لنمذجة أكثر فاعلية ، ومكتبات Ember ، لوداش وآخرون.
قدمت إصدارات TypeScript 2.2 و 2.3 دعمًا لقوالب فئة mixin ، ونوع
object (الذي يمثل كائنًا ليس بدائيًا) ، والقيم الافتراضية للأنواع العامة. تم استخدام هذه الميزات في عدد من المشاريع ، مثل Angular Material و Polymer. بالإضافة إلى ذلك ، قدم TypeScript 2.3 القدرة على ضبط
this الأنواع بدقة ، مما سمح للغة بالعمل بشكل جيد مع المكتبات مثل Vue ، وتمت
checkJs علامة
checkJs للسماح بفحص الأنواع في ملفات JavaScript.
يواصل TypeScript 2.4 و 2.6 قصة زيادة خطورة فحص نوع الوظيفة ، المرتبط ببعض أقدم المراجعات لنظام الكتابة لدينا. تم تقديم علامة
--strictFunctionTypes ، مما اضطر تناقض المعلمات. في الإصدار 2.7 ، استمر الاتجاه نحو الدقة وتم التعبير عنه في التحقق من الصحة في الفصول باستخدام علامة -
--strictPropertyInitialization .
يقدم TypeScript 2.8 الأنواع الشرطية ، وهي أداة قوية للتعبير بشكل ثابت عن القرارات القائمة على النوع ، والإصدار 2.9 يعمم عامل keyof ويبسط الاستيراد للأنواع.
وهذا ينقلنا إلى TypeScript 3.0! على الرغم من العدد الصحيح الجديد في الرقم ، لم يتغير إلا القليل في الإصدار 3.0 (مما يعني تحديثًا سهلًا جدًا). يقدم طريقة جديدة مرنة وقابلة للتطوير لهيكلة المشاريع ، ودعم جديد قوي للعمل مع قوائم المعلمات ، وأنواع جديدة لتوفير فحوص صريحة ، ودعم JSX محسّن ، وتشخيص أكثر سهولة للأخطاء ، وأكثر من ذلك بكثير.
ما الجديد
- روابط المشروع
--build وضع --build- إدارة هيكل الناتج
- الخطط المستقبلية
- استرجاع وتوزيع قوائم المعلمات باستخدام الصفوف
- ميزات نوع Tuple الجديدة
- اكتب
unknown - تحسين تشخيص الأخطاء وبيئة المستخدم
- نطاقات الخطأ المرتبطة
- تحسين التشخيص ومعالجة الأخطاء
- دعم خاصية
defaultProps في defaultProps - التوجيهات
/// <reference lib="..." /> - تحسين سرعة المحرر
- إعادة هيكلة بيانات الاستيراد المسماة
- نهاية علامة النهاية وإطار المخطط التفصيلي
- إصلاحات سريعة للشفرة التي لا يمكن الوصول إليها والعلامات غير المستخدمة
- تغييرات حرجة
unknown هو اسم نوع محجوز- التغييرات الحرجة في واجهة برمجة التطبيقات
روابط المشروع
في كثير من الأحيان ، لإنشاء مكتبة أو تطبيق ، تحتاج إلى اتباع عدة خطوات. افترض أن قاعدة التعليمات البرمجية تحتوي على
src test . افترض أن لديك مجلد
client حيث يتم تخزين رمز جزء العميل من التطبيق ، ومجلد خادم يحتوي على رمز جزء الخادم على النظام الأساسي Node.js ، وكل واحد منهم يأخذ جزءًا من الرمز من المجلد
shared . ربما أنك تستخدم ما يسمى "مستودع واحد" ولديك العديد من المشاريع التي تعتمد بشكل معقد على بعضها البعض.
واحدة من أهم الميزات التي عملنا عليها عند إصدار TypeScript 3.0 كانت تسمى "روابط المشروع" وهي مصممة لتبسيط العمل مع مثل هذه البرامج النصية.
بفضل روابط المشروع ، قد تعتمد بعض مشاريع TypeScript على أخرى. على وجه الخصوص ،
tsconfig.json لملفات
tsconfig.json بالإشارة إلى ملفات
tsconfig.json الأخرى. يعمل تحديد هذه التبعيات على تسهيل تقسيم التعليمات البرمجية إلى مشروعات أصغر ، لأن مترجم TypeScript (وأدواته) يحصل على فرصة لفهم ترتيب التجميع وهيكل المخرجات. وهذا يعني أن التجميع أسرع ويتم تنفيذه بشكل تدريجي (على مراحل) ، ويدعم التنقل الشفاف والتحرير وإعادة الهيكلة للمشاريع المختلفة. نظرًا لأن TypeScript 3.0 يضع الأساس للمشروع ويوفر واجهة برمجة تطبيقات ، يجب أن تكون أي أداة بناء قادرة على توفير ذلك.
كيف تبدو؟
في ما يلي ملف
tsconfig.json يحتوي على روابط إلى المشاريع كمثال بسيط.
// ./src/bar/tsconfig.json { "compilerOptions": { // Needed for project references. "composite": true, "declaration": true, // Other options... "outDir": "../../lib/bar", "strict": true, "module": "esnext", "moduleResolution": "node", }, "references": [ { "path": "../foo" } ] }
لها مجالان جديدان:
composite references .
references حقل
references ببساطة إلى ملفات
tsconfig.json الأخرى (أو المجلدات التي تحتوي عليها). كل رابط هنا هو ببساطة كائن يحتوي على حقل
path ("المسار") ويخبر مترجم TypeScript أنه لبناء هذا المشروع ، يجب عليك أولاً إنشاء مشروع آخر يشير إليه.
يبدو أن المجال
composite له نفس الأهمية. يضمن الحقل
composite تمكين معلمات معينة تسمح لأي مشروع يعتمد على ذلك بالإشارة إليه وإدراجه في البنيات الإضافية. تعد القدرة على البناء بذكاء وتزايد أمرًا مهمًا ، نظرًا لأن أحد الأسباب الرئيسية وراء التخلي عن المشروع هو سرعة البناء.
على سبيل المثال ، إذا كان مشروع
front-end يعتمد على المشروع
shared ،
shared على الأساس ، فإن واجهات برمجة التطبيقات الخاصة بنا ذات الصلة بروابط المشروع ستساعد في تحديد التغييرات الأساسية ، ولكنها تجمع فقط المشتركة مرة أخرى إذا تغيرت الأنواع التي أنتجها المشروع
core (أي ملفات
.d.ts ). وهذا يعني أن التغيير الجوهري لا يستلزم إعادة تجميع عالمية لجميع المشاريع. لهذا السبب ، يؤدي تعيين العلامة
composite أيضًا إلى وضع علامة التعريف.
- وضع البناء
سيقدم TypeScript 3.0 مجموعة من واجهات برمجة التطبيقات (API) لمراجع المشروع بحيث يمكن للأدوات الأخرى توفير طريقة الإنشاء الإضافية السريعة هذه. على وجه الخصوص ، يستخدم البرنامج المساعد gulp-typescripts APIs بالفعل! وبالتالي ، سيتم دمج الروابط اللاحقة للمشروعات مع أوركسترا التجميع الذي تختاره.
ومع ذلك ، بالنسبة للعديد من التطبيقات والمكتبات البسيطة ، يُنصح بعدم استخدام أدوات خارجية. هذا هو السبب في أن الأمر
--build يعين الآن علامة جديدة -
--build .
tsc --build (أو الاسم المستعار ،
tsc -b ) مجموعة من المشاريع
tsc --build ، بالإضافة إلى إنشاء المشاريع التابعة. عند استخدام وضع البناء الجديد ، أولاً ، يجب تعيين علامة
--build ، ويمكن دمجه مع بعض العلامات الأخرى:
--verbose : يعرض كل خطوة تتطلبها عملية البناء.--dry : --dry بدون إنشاء ملفات الإخراج (مفيد بالاقتران مع خيار - --verbose ).–clean : –clean لحذف ملفات الإخراج المطابقة للمدخلات المحددة.--force : --force كاملاً وغير تدريجي للمشروع.
إدارة هيكل الناتج
تتمثل إحدى المزايا الدقيقة والمفيدة للغاية لمراجع المشروع في القدرة المنطقية على تعيين ملفات الإدخال إلى ملفات الإخراج المقابلة.
إذا حاولت في أي وقت فصل أجزاء العميل والخادم من التطبيق ، فقد تواجه مشاكل في إدارة بنية الإخراج.
على سبيل المثال ، إذا كان كلاً من العميل / index.ts والخادم / index.ts يشير إلى Shared / index.ts للمشاريع التالية:
... ثم عندما نحاول بناء مشاريع العميل والخادم ، نحصل على ...
... لا ...
لاحظ أنه بعد الإنشاء ، تلقينا نسخًا من المجلد المشترك في كل من العميل والخادم. لقد أمضينا وقتًا إضافيًا في بناء التجميع المشترك مرتين وأضفنا مستوى تداخل غير مرغوب فيه إلى lib / client / client و lib / server / server.
تكمن المشكلة في أن TypeScript يبحث بفارغ الصبر عن ملفات .ts ويحاول تضمينها في هذه المجموعة. من الناحية المثالية ، يجب أن يكون TypeScript قد فهم أن هذه الملفات لا يجب أن تشارك في التجميع في نفس التجميع ، وبدلاً من ذلك انتقل إلى ملفات .d.ts للحصول على معلومات النوع.
ينتج عن إنشاء ملف tsconfig.json لهذه المشاركة هذه النتيجة بالضبط. يشير إلى مترجم TypeScript:
- أنه يجب بناء المشروع المشترك بشكل مستقل
- وأنه عند الاستيراد من ../shared يجب أن نبحث عن ملفات .d.ts في دليل الإخراج الخاص بها.
هذا يتجنب تشغيل تجميع مزدوج ، بالإضافة إلى تضمين كل المحتوى المشترك عن طريق الخطأ.
الخطط المستقبلية
للحصول على فهم أعمق لروابط التصميم وإمكانيات استخدامها ، اقرأ عنها بمزيد من التفاصيل في
تعقب هذا الإصدار . في المستقبل القريب ، سنقوم بإعداد وثائق حول روابط المشروع ووضع البناء.
نحن نسعى جاهدين حتى يتمكن مؤلفو أدوات البرمجة الأخرى من الحفاظ على مراجع المشاريع والاستمرار في تحسين بيئة التحرير فيما يتعلق بهذه الوظيفة. نحن نعتزم التأكد من أن العمل مع روابط المشروع يعمل بسلاسة مثل تطوير التعليمات البرمجية مع ملف tsconfig.json واحد. إذا بدأت في النهاية في استخدام روابط المشروع ، سنكون ممتنين لأية ملاحظات.
استرجاع وتوزيع قوائم المعلمات باستخدام الصفوف
غالبًا ما نأخذ هذا الأمر على أنه أمر مسلم به ، لكن جافا سكريبت تسمح لنا بالنظر في قوائم المعلمات كقيم من الدرجة الأولى - باستخدام إما الوسائط أو معلمات نوع الراحة (على سبيل المثال ... بقية).
function call(fn, ...args) { return fn(...args); }
لاحظ أن الاستدعاء يعمل للوظائف مع أي عدد من المعلمات. على عكس اللغات الأخرى ، لا تجبرنا جافا سكريبت على تحديد call0 ، call1 ، call2 ، إلخ على النحو التالي:
function call0(fn) { return fn(); } function call1(fn, param1) { return fn(param1); } function call2(fn, param1, param2) { return fn(param1, param2); } function call3(fn, param1, param2, param3) { return fn(param1, param2, param3); }
لسوء الحظ ، لبعض الوقت ، لم تكن هناك طريقة جيدة للتعبير عن هذا في TypeScript دون الإعلان عن عدد محدود من التحميل الزائد:
// TODO (billg): 5 overloads should *probably* be enough for anybody? function call<T1, T2, T3, T4, R>(fn: (param1: T1, param2: T2, param3: T3, param4: T4) => R, param1: T1, param2: T2, param3: T3, param4: T4): R function call<T1, T2, T3, R>(fn: (param1: T1, param2: T2, param3: T3) => R, param1: T1, param2: T2, param3: T3): R function call<T1, T2, R>(fn: (param1: T1, param2: T2) => R, param1: T1, param2: T2): R function call<T1, R>(fn: (param1: T1) => R, param1: T1): R; function call<R>(fn: () => R, param1: T1): R; function call(fn: (...args: any[]) => any, ...args: any[]) { return fn(...args); }
عفوا! وفاة أخرى مع ألف حمولة زائدة! أو على الأقل العديد من الأحمال الزائدة التي يحتاجها المستخدمون.
يسمح لك TypeScript 3.0 بمحاكاة مثل هذه السيناريوهات بشكل أفضل ، حيث يمكن الآن أن تكون معلمات نوع الباقي عالمية ، ويتم تعريف نوعها على أنها مجموعة. بدلاً من التصريح بكل من هذه الأحمال الزائدة ، نقول أن معلمة الباقي ... args من دالة fn يجب أن تكون معلمة نوع توسع الصفيف ، ثم إعادة استخدامه لمعلمة ... args التي تمر بها وظيفة الاستدعاء:
function call<TS extends any[], R>(fn: (...args: TS) => R, ...args: TS): R { return fn(...args); }
عندما نستدعي وظيفة الاستدعاء ، يحاول TypeScript استخراج قائمة من المعلمات مما نمرره إلى fn وتحويلها إلى مجموعة:
function foo(x: number, y: string): string { return (x + y).toLowerCase(); } // The `TS` type parameter is inferred as `[number, string]` call(foo, 100, "hello");
عندما يعرّف TypeScript TS على أنه [number، string] ، وننتهي من إعادة استخدام TS على معلمة بقية دالة الاستدعاء ، يبدو مثيل الدالة كما يلي:
function call(fn: (...args: [number, string]) => string, ...args: [number, string]): string
وفي TypeScript 3.0 ، عند استخدام tuple in rest ، يتم تصغير المعلمة إلى باقي قائمة المعلمات! ينقص المثال أعلاه المعلمات البسيطة بدون tuples:
function call(fn: (arg1: number, arg2: string) => string, arg1: number, arg2: string): string
لذلك ، بالإضافة إلى اكتشاف أخطاء تحويل النوع عند تمرير وسيطات غير صالحة:
function call<TS extends any[], R>(fn: (...args: TS) => R, ...args: TS): R { return fn(...args); } call((x: number, y: string) => y, "hello", "world"); // ~~~~~~~ // Error! `string` isn't assignable to `number`!
... واكتب التعريف من الحجج الأخرى:
call((x, y) => { /* .... */ }, "hello", 100); // ^ ^ // `x` and `y` have their types inferred as `string` and `number` respectively.
... يمكننا أيضًا رؤية أنواع الصفوف التي تحددها هذه الوظائف من الخارج:
function tuple<TS extends any[]>(...xs: TS): TS { return xs; } let x = tuple(1, 2, "hello"); // has type `[number, number, string]`
ولكن انتبه إلى تحذير واحد. للقيام بكل هذا العمل ، كان علينا توسيع قدرات الصفوف ...
ميزات نوع Tuple الجديدة
من أجل وضع نموذج لقائمة المعلمات كمجموعة (كما ناقشنا للتو) ، كان علينا إعادة التفكير في أنواع المجموعة قليلاً. قبل إصدار TypeScript 3.0 ، كان أفضل ما سمح بتصميمه باستخدام الصفوف هو ترتيب مجموعة المعلمات وطولها.
ومع ذلك ، فإن قوائم المعلمات ليست قوائم نوع مرتبة فقط. على سبيل المثال ، قد تكون المعلمات في النهاية اختيارية:
// Both `y` and `z` are optional here. function foo(x: boolean, y = 100, z?: string) { // ... } foo(true); foo(true, undefined, "hello"); foo(true, 200);
يمكن أن تكون المعلمة الأخيرة معلمة راحة.
// `rest` accepts any number of strings - even none! function foo(...rest: string[]) { // ... } foo(); foo("hello"); foo("hello", "world");
وأخيرًا ، هناك خاصية واحدة مثيرة للاهتمام لقوائم المعلمات - يمكن أن تكون فارغة:
// Accepts no parameters. function foo() { // ... } foo();
لذلك ، لكي تتوافق الصفوف مع قوائم المعلمات ، كنا بحاجة لمحاكاة كل من هذه السيناريوهات.
أولاً ، في نهاية الصف ، قد تكون هناك عناصر اختيارية:
/** * 2D, or potentially 3D, coordinate. */ type Coordinate = [number, number, number?];
ينشئ نوع الإحداثي مجموعة ذات خاصية اختيارية تسمى 2 - قد لا يتم تحديد عنصر مع الفهرس 2! من المثير للاهتمام ، بما أن الصفوف تستخدم نوعًا حرفيًا رقميًا لخاصية الطول ، فإن خاصية الطول للصفقة Coodinate هي من النوع 2 | 3.
ثانيًا ، قد يكون العنصر الباقي موجودًا الآن في نهاية الصف.
type OneNumberAndSomeStrings = [number, ...string[]];
بفضل العناصر المتبقية ، يُظهر الصفوف سلوكًا مثيرًا للاهتمام للغاية "غير محدود من النهاية". يتطلب المثال أعلاه من النوع OneNumberAndSomeStrings نوع خاصيته الأولى ليكون رقمًا ، ويسمح بخاصية واحدة أو أكثر من سلسلة النوع. تؤدي فهرسة هذا النوع من الصفوف مع رقم عشوائي إلى إرجاع سلسلة النوع | رقم ، لأن قيمة الفهرس غير معروفة. وبالمثل ، نظرًا لأن طول الصف غير معروف ، فإن قيمة خاصية الطول هي ببساطة رقم.
وتجدر الإشارة إلى أنه في حالة عدم وجود عناصر أخرى ، فإن العنصر المتبقي في المجموعة مطابق لنفسه:
type Foo = [...number[]]; // Equivalent to `number[]`.
أخيرًا ، يمكن أن تكون الصفوف فارغة الآن! على الرغم من أن هذا ليس مفيدًا جدًا عند استخدامه خارج قوائم المعلمات ، يمكن تعريف نوع مجموعة فارغ على أنه []:
type EmptyTuple = [];
كما قد تتوقع ، فإن الصفوف الفارغة لها خاصية طول 0 ، والفهرسة بالرقم ترجع النوع أبداً.
تحسين تشخيص الأخطاء وبيئة المستخدم
بمرور الوقت ، نتلقى المزيد والمزيد من الطلبات من أعضاء مجتمعنا فيما يتعلق بتحسين رسائل الخطأ. على الرغم من أن هذا العمل بعيد عن الاكتمال ، فقد سمعنا منك وأدخلنا عددًا من التحسينات على إصدار TypeScript 3.0.
نطاقات الخطأ المرتبطة
جزئيًا ، الهدف من رسالة الخطأ الجيدة هو توضيح المستخدم كيفية تصحيحها ، أو ، أولاً وقبل كل شيء ، توضيح سبب ظهور هذه الرسالة. في معظم الحالات ، يحتوي على الكثير من المعلومات أو يشير إلى عدة أسباب لحدوثه. من تحليل لهذه الأسباب ، يمكننا أن نستنتج أن الأخطاء تنتج عن أجزاء مختلفة من التعليمات البرمجية.
نطاقات الأخطاء المرتبطة هي طريقة جديدة لتوفير هذه المعلومات للمستخدمين. في TypeScript 3.0 ، يمكن أن تنشئ رسائل الخطأ رسائل في مكان آخر في التعليمات البرمجية حتى يتمكن المستخدمون من معرفة سبب الخطأ وتأثيره.
بمعنى ما ، لا يمكن لرسائل الخطأ ذات الصلة أن تقدم للمستخدم شرحًا فحسب ، بل تشير أيضًا إلى المسار إلى المكان الذي حدث فيه كل شيء بشكل خاطئ.
ستظهر هذه الفواصل الزمنية أيضًا في وضع المحطة الطرفية عند تشغيل الأمر tsc مع تمكين الوضع --pretty ، على الرغم من أننا ما زلنا نعمل على تحسين واجهة المستخدم والنظر في ملاحظاتك!
تحسين التشخيص ومعالجة الأخطاء
في التحضير لإصدار TypeScript 2.9 ، بدأنا
في إيلاء المزيد من الاهتمام لرسائل الخطأ ، وفي الإصدار 3.0 حاولنا حقًا حل المهام الرئيسية التي ستسمح لنا بإجراء تشخيص ذكي وواضح ودقيق للأخطاء. وهذا يشمل ، على وجه الخصوص ، اختيار الأنواع المناسبة في حالة وجود تناقضات في أنواع الاقتران والخروج مباشرة إلى مصدر الخطأ لأنواع معينة من الرسائل.
نعتقد أن جهودنا قد تم تبريرها ، ونتيجة لذلك ستتلقى رسائل خطأ أقصر وأكثر وضوحًا.
اكتب غير معروف
النوع any هو أي نوع في TypeScript مناسب لأي شيء. نظرًا لأنه يغطي أنواع جميع القيم الممكنة ، فإنه لا يجبرنا على إجراء أي فحوصات قبل أن نحاول الاتصال أو إنشاء أو الوصول إلى خصائصهم. كما يسمح لك بتعيين قيم من نوع أي لمتغيرات تتوقع قيمًا من أي نوع آخر.
هذه الميزة مفيدة بشكل عام ، ولكن لا يمكنها توفير صرامة كافية.
let foo: any = 10; // All of these will throw errors, but TypeScript // won't complain since `foo` has the type `any`. foo.x.prop; foo.y.prop; foo.z.prop; foo(); new foo(); upperCase(foo); foo `hello world!`; function upperCase(x: string) { return x.toUpperCase(); }
في بعض الأحيان ، في TypeScript ، تريد وصف نوع غير مناسب لأي شيء. هذا مفيد لواجهة برمجة التطبيقات التي تريد الإشارة: "يمكن أن تكون أي قيمة ، لذلك تحتاج إلى إجراء بعض التحقق قبل استخدامه". ويضطر المستخدمون إلى تحليل قيم الإرجاع لأسباب أمنية.
يقدم TypeScript 3.0 نوعًا جديدًا يسمى غير معروف ، وهو يفعل ذلك تمامًا. any, unknown , , any, unknown . unknown, .
unknown any, foo :
let foo: unknown = 10; // Since `foo` has type `unknown`, TypeScript // errors on each of these locations. foo.x.prop; foo.y.prop; foo.z.prop; foo(); new foo(); upperCase(foo); foo `hello world!`; function upperCase(x: string) { return x.toUpperCase(); }
, , , .
let foo: unknown = 10; function hasXYZ(obj: any): obj is { x: any, y: any, z: any } { return !!obj && typeof obj === "object" && "x" in obj && "y" in obj && "z" in obj } // Using a user-defined type guard... if (hasXYZ(foo)) { // ...we're allowed to access certain properties again. foo.x.prop; foo.y.prop; foo.z.prop; } // We can also just convince TypeScript we know what we're doing // by using a type assertion. upperCase(foo as string); function upperCase(x: string) { return x.toUpperCase(); }
: , , , {} | null | undefined, unknown , :
type Arrayify<T> = T extends any ? Array<T> : never; type A = Arrayify<{} | null | undefined>; // null[] | undefined[] | {}[] type B = Arrayify<unknown>; // unknown[]
defaultProps JSX
: .d.ts React , , .- TypeScript/JavaScript , , . , . , .
function loudlyGreet(name = "world") { // Thanks to the default initializer, `name` will always have type `string` internally. // We don't have to check for `undefined` here. console.log("HELLO", name.toUpperCase()); } // Externally, `name` is optional, and we can potentially pass `undefined` or omit it entirely. loudlyGreet(); loudlyGreet(undefined);
React (props). React , defaultProps, props.
// Some non-TypeScript JSX file import * as React from "react"; import * as ReactDOM from "react-dom"; export class Greet extends React.Component { render() { const { name } = this.props; return <div>Hello ${name.toUpperCase()}!</div>; } static defaultProps = { name: "world", }; } // Notice no `name` attribute was specified! // vvvvvvvvv const result = ReactDOM.renderToString(<Greet />); console.log(result);
, <Greet /> name. Greet, name «world», : Hello world!.
, TypeScript , defaultProps - JSX. render:
export interface Props { name?: string } export class Greet extends React.Component<Props> { render() { const { name } = this.props;
, .
TypeScript 3.0 JSX, LibraryManagedAttributes. , , TypeScript, JSX. , , React defaultProps , , propTypes.
export interface Props { name: string } export class Greet extends React.Component<Props> { render() { const { name } = this.props; return <div>Hello ${name.toUpperCase()}!</div>; } static defaultProps = { name: "world"} }
, . defaultProps, Partial , - (stateless function components, SFC), defaultProps Partial , . defaultProps (. ) SFC ES2015:
function Greet({ name = "world" }: Props) { return <div>Hello ${name.toUpperCase()}!</div>; }
, . TypeScript, .d.ts DefinitelyTyped , , @types/react . DefinitelyTyped, .
/// <reference lib="..." />
, , , (polyfills) — , API , ( .d.ts), API. , TypeScript lib.d.ts , --lib --target. , core-js lib.es2015.d.ts.
TypeScript 3.0 , API, , : /// <reference lib="..." />.
, Promise ES2015
, TypeScript 3.0 , lib.es2015.promise.d.ts, , Promise .
, , TypeScript , . TypeScript JavaScript , Visual Studio, Visual Studio Code TypeScript. , , , Go to Definition (« ») . TypeScript 3.0 .
, , .
import * as dependency from "./dependency"; // look at all this repetition! dependency.foo(); dependency.bar(); dependency.baz();
, , , , .
import { foo, bar, baz } from "./dependency";
, , . TypeScript 3.0 , .
TypeScript , JSX:
TypeScript — , .
,
API .
, TypeScript 3 , . , API .
unknown —
unknown — , , , .
API
- LanguageService#getSourceFile , . . #24540 .
- TypeChecker#getSymbolDisplayBuilder . . #25331 . emitter ( ) node builder.
- escapeIdentifier unescapeIdentifier . API , . , , . escapeLeadingUnderscores unescapeLeadingUnderscores, , ( «» __String string ).
- TypeChecker#getSuggestionForNonexistentProperty, TypeChecker#getSuggestionForNonexistentSymbol TypeChecker#getSuggestionForNonexistentModule , API. . #25520 .
الآفاق
TypeScript . , , , DefinitelyTyped , . , .
, TypeScript ( , ). , , JavaScript. , TypeScript, .
, , , , ,
Twitter . .
, TypeScript, ! . , , TypeScript , .
!
TypeScript