لذلك في المثال الأول ، قد نبعثها كما يلي:

x && xy && xyz && xyzfoo

ولكن بعد ذلك علينا أن نجعل كل من x و y و z و foo بطريقة ما قيمة واحدة على الأكثر.

أنت أيضًا لا تستطيع فعل && في كثير من الحالات لأن المصداقية تصبح مشكلة إلى حد ما بالنسبة للأولويات.

علي سبيل المثال:

"     "?.trim()?.indexOf("hello")

يعطي "" .

لذلك أنت بحاجة إلى إجراء بعض المقارنات الصريحة مع null باستخدام == للحالة العامة ، إلا إذا استفدنا من نظام الكتابة (والذي سيكون رائعًا إلى حد ما إذا رأينا نفعل).

يمكن أن نصدر دالة ربط أحادية (ليست جميلة بالنسبة لإخراج JS) ، أو نستخدم بعض التحويل على عوامل ثلاثية (أقرب إلى مكافئ JS النموذجي). من الواضح أنني منحاز قليلاً تجاه الأخير.

كانت هناك مناقشات قليلة في esdiscuss حول ذلك:

• http://esdiscuss.org/topic/the-existential-operator
• http://esdiscuss.org/topic/specifying-the-existential-operator-using-abrupt-completion

: +1:

من الناحية المثالية ، سيكون لدينا ES7 (أو ES8 أو ES9 أو ...) ننفذ هذا أولاً لأنه ربما يكون هناك بعض الخلاف حول الدلالات الدقيقة حول ما إذا كان سيتم استخدام 0 / "" أم لا

: +1: أود أن أرى TypeScript يحصل على هذا أولاً دون الحاجة إلى انتظار ESxx.

حقيقة أن مشغلي السلامة الصفرية البسيطة والمفيدة بجنون مثل "؟" و "؟؟ هذا أمر بسيط وواضح لدرجة أن عدم دمجه سيكون جنونًا بصراحة. هناك سبب لدعم معظم اللغات الحديثة لهذه: أنها لا غنى عنها.

أدرك أن هذا سيكون انحرافًا عن المواصفات الحالية (نظرًا لأن المواصفات الحالية قصيرة النظر جدًا بحيث يتم حذف ذلك). لكنها مفيدة للغاية لدرجة أنني أعتقد أن هذا الانحراف الفردي سيكون له ما يبرره. لن تتأثر الغالبية العظمى (VAST) من مطوري TS بالتغييرات الطفيفة في التنفيذ ، إذا أو عندما يتم إضافتها أخيرًا إلى مواصفات ES. تستحق الفوائد الضخمة التي سيقدمها هذا التأثير المستقبلي المحتمل لجزء ضئيل من المطورين. وبالنظر إلى عملية المواصفات ES البطيئة المضحكة ، فإن هذا لن يكون مهمًا على الإطلاق لعدة سنوات (على الأقل).

أتفق تمامًا مع brain428

@ brian428 تكمن المشكلة هنا في أن هذا المشغل ربما تم تنفيذه في ES7 ، لذا إذا كانت الكتابة المطبوعة بمواصفات تنتهي في نهاية المطاف بمختلف ES7 ، فلن يكون أحد سعيدًا.

تكمن المشكلة هنا في أن هذا المشغل ربما تم تنفيذه في ES7 ، لذا إذا اتجهت الكتابة المطبوعة بمواصفات ينتهي بها الأمر إلى اختلاف عن آخر ES7 ، فلن يكون أحد سعيدًا.

أعتقد أن أسلوب TypeScript أكثر إيجابية في تنفيذ الميزات التي من المحتمل _ (أو قد لا) تحويلها إلى إصدار ES مستقبلي ، لأنه سيكون اختبارًا مفيدًا للتأثير على اتجاه ES.

فيما يلي مثال على مناقشة ES التي تأثرت بـ TypeScript :

يعد خيار TypeScript ... للإعلان والتهيئة عبر بادئة خاصة على إحدى معلمات المنشئ مفيدًا للعديد من المطورين

علاوة على ذلك ، من الممكن بالتأكيد لـ ES أن يتبنى ميزة موجودة بالفعل في TypeScript ، ولكن بدلالات مختلفة (على سبيل المثال ، حول كيفية عمل الوحدات).

من الممكن بالتأكيد لـ ES أن يتبنى ميزة موجودة بالفعل في TypeScript ، ولكن بدلالات مختلفة

يجب أن أشير إلى أننا نعتبر على نطاق واسع أن هذا هو السيناريو الأسوأ. لقد أردنا حقًا إنهاء الوحدات النمطية في ES6 قبل الإعلان عن TypeScript 1.0 ، لكن تأخيرات جدول اللجنة حالت دون ذلك. هذا شيء يجب تجنبه ، وليس تكراره. نود حقًا الوصول إلى الميزات التي لديها فرصة بنسبة 0٪ تقريبًا لجعلها في ES7 + (على سبيل المثال ، كتابة التعليقات التوضيحية) ، أو لديها فرصة بنسبة 100٪ تقريبًا لإدخالها باستخدام دلالات محددة بسهولة (على سبيل المثال ، حيث كان السهم السمين اثنين سنين مضت). من المرجح أن يقع المشغلون الجدد في الوسط المحرج.

في أسوأ الحالات ، إذا كان ES7 مختلفًا ، فهل يمكن لعلم المترجم أن يدعم تنفيذ TS القديم ، وبالتالي يوفر فترة سماح؟ يجب أن يقدم هذا إلى جانب وثائق الترحيل الواضحة للمطورين طريقًا مباشرًا إلى أي معيار جديد.

في النهاية ، استخدام أي ميزة من هذا القبيل - على الرغم من كونها مفيدة بجنون - ليس ضروريًا من قبل المطورين. يجب أن تجعل TS الآثار المستقبلية المحتملة لاستخدامها واضحة تمامًا منذ اليوم الأول. لا تعجبك فكرة إعادة بناء مُدارة محتملة ، لا تستخدمها. ربما علامة مترجم الاشتراك لفرض هذه الرسالة؟

لا ينبغي أن يتصرف TS في رغبته في التأثير على ES ، ولكن في حالات منعزلة صغيرة مثل هذه ، سيكون من العار أن يخجل TS تمامًا.

ربما يمكننا وضع اقتراح مبتذل لهذا ومن ثم يكون لدينا تنفيذ مرجعي خلف علم الانسجام (أو شيء من هذا القبيل). بهذه الطريقة يمكننا دفع تطوير ES7 لهذه الميزة.

لمنع الآثار الجانبية بسبب عمليات البحث المتكررة ، سيضطر المترجم إما إلى إخراج المتغيرات المؤقتة:

($tmp0 = x, $tmp0 === void 0 ? void 0 : 
    ($tmp1=$tmp0.y,  $tmp1 === void 0 ? void 0 : 
        ($tmp2 = $tmp1.z,  $tmp2 === void 0 ? void 0 : $tmp2)))

أو استخدم غشاء حفظ على أساس Proxy .

من وجهة نظر قاطعة ، هذا هو ربما monad المطبق على البحث عن الممتلكات ، لذلك فهي ميزة طبيعية جدًا للغة حيث قد تعود جميع عمليات البحث عن الممتلكات غير محددة. سأفاجأ إذا تبنت ES7 أي دلالات غير تلك الموصوفة في الكود أعلاه.

حصلت قضية codeplex على عدد لا بأس به من الأصوات (61)

أنا حقًا في حاجة ماسة إلى هذا لتخفيف ألم استخدام atom للنسخة التي تُنظم على شكل ذرة .

إنه اصطلاحي للغاية في كود coffescript (على الرغم من أنني أود ألا يكون شائعًا مثل الحتمية أفضل من fudgy ? ). افتح أي ملف coffescript ، خاصة الملف الذي يعمل مع DOM مباشرة مثل space-pen (حيث يمكن تشغيل الوظائف بعد إتلاف العرض أو قبل إرفاق العرض) وستجد gazillion ? استخدامات. على سبيل المثال ، يحتوي هذا الملف على 16 https://github.com/atom-community/autocomplete-plus/blob/f17659ad4fecbd69855dfaf00c11856572ad26e7/lib/suggestion-list-element.coffee

مرة أخرى ، لا أحب أن أحتاج إلى هذا ، لكنه حالة JavaScript ، وأنا أفضل ? على مليون if( && fest ) { then }

لكنني حقًا أحتاجه حقًا للحفاظ على الكود الخاص بي قابلاً للقراءة. من الشائع أيضًا أن _Need_ هذا عندما تنتظر XHR حتى يكتمل ويدير الزاوي حلقة الهضم الخاصة به.

حسنًا ، لقد قرأت الموضوع وأرى لماذا ننتظر. أفهم _ تنهي_.

we'd have to somehow make x, y, z, and foo each evaluate at most once.

يقوم coffeescript ببعض التحسينات ، مثل تخزين نتائج الوصول الوسيطة :

typeof foo !== "undefined" && foo !== null ? (ref = foo.bar) != null ? ref.baz() : void 0 : void 0;

(أشعر بشدة أن الاختيار undefined غير ضروري للنسخة المطبوعة: حيث يجب أن يكون لدينا var init مطبعيًا)

+1

في أخبار اليوم ، تحصل Dart على دعم رسمي لها: https://github.com/gbracha/nullAwareOperators/blob/master/proposal.md

ميزة مهمة جدا.

من المحتمل أن تكون فكرة خارج الحائط ، ولكن يمكن تنفيذ برنامج الترميز لهذه الميزة بسهولة شديدة دون آثار جانبية إذا قرر الجميع أنه سيكون من المقبول التعامل مع الميزة مع الوصول إلى خاصية مفتاح:

if (aaa?.bbb?.ccc) {}

يمكن تجميع ل

if (__chain(aaa, "bbb", "ccc")) {}

يجب أن يتم إصدار وظيفة __chain بشكل مشابه لـ __extends . يمكن أن تتكرر الدالة __chain فقط من خلال المصفوفة arguments ، وتعيد null عندما لا يكون العضو القادم instanceof Object أو لا يحتوي على اسم العضو. يمكن معالجة استدعاءات الوظائف عن طريق تمرير مصفوفة كمعامل (واستخدام .apply() تحت الأغلفة) ، لذا ...

if (aaa?.bbb?.ccc?(1, 2, 3)) {}

يمكن تجميع ل

if (__chain(aaa, "bbb", "ccc", [1, 2, 3])) {}

هذا من شأنه أيضًا أن يحافظ على JS التي تم إنشاؤها اصطلاحيًا بشكل معقول ، حتى بالنسبة للسلاسل الطويلة.

من الواضح أنه بحاجة إلى تحسين ... لكن ربما يوجد شيء ما هنا؟

إذا قام aaa?.bbb?.ccc? بإرجاع قيمة a.b.c إذا كانت جميع العناصر موجودة وكانت وظيفة ، فلا يمكن إذًا

if (aaa?.bbb?.ccc?(1, 2, 3)) {}

تجميع ل

if (__chain(aaa, "bbb", "ccc")(1, 2, 3)) {}

؟

metaweta : الحل الخاص بك هو التحقق فقط من void 0 ... أليس هذا النوع من إلغاء الغرض من الميزة؟

ماذا عن هذا:

var result = one?.two?.three;

يولد:

var $a, $b, $c;
var result = $a = one, $b = $a ? $a.two : void 0, $b ? $b.three : void 0;

أنا متأكد من أن هذا يعالج جميع الحالات. قد تحتاج مكالمات الوظائف إلى شيك instanceof Function .

(الجانب السلبي البسيط هنا من المتغيرات المحلية غير المتوقعة التي يتم إصدارها ... يمكن تغليفها في IIFE ربما)

@ kevinb7 : ماذا يحدث إذا لم يكن ccc دالة؟ باستخدام الكود الذي وصفته ، سيضطر __chain دائمًا إلى إرجاع دالة صالحة ، أو سيتم إصدار خطأ TypeError.

@ Back-io عند عدم وجود خاصية ، يرجع البحث غير محدد === void 0. يفشل الحل الخاص بك في البحث عن خصائص القيم الخاطئة مثل سلسلة فارغة وصفر.

metaweta : لا ، ليس كذلك: http://jsfiddle.net/25LppbL6/

أيضًا ، أتخيل أن فريق TS ليس مجنونًا باستخدام مساواة فضفاضة نظرًا لحقيقة أن بعض الناس يحذرون من ذلك.

@ Back-io نعم هو كذلك: http://jsfiddle.net/25LppbL6/2/

@ Back-io بخصوص القيمة null ، لست متأكدًا من الدلالات المقصودة من a؟ .b. إذا كانت "إذا تم تعريف الخاصية b ، فاستخدمها" ، فهذا يعني أن الكود الخاص بي يكون صحيحًا تقريبًا. الطريقة الوحيدة للحصول على قيمة خالية هي إذا تم تعيينها لتكون خالية ، لأن عمليات البحث عن الخصائص غير الموجودة ترجع غير محددة. إنه لا يفشل في التقاط الحالة حيث توجد الخاصية ولكن تم تعيينه على undefined. لكي تكون صحيحًا تمامًا ، يجب التحقق من ذلك باستخدام Object.hasOwnProperty () بدلاً من المقارنة بالفراغ 0 === غير محدد.

إذا كانت الدلالات هي "إذا كانت الخاصية b صحيحة ، فاستخدمها" ، فإن الكود الخاص بك جيد ويتطابق إلى حد ما مع لغة JS.

أم ... ما لم أفقد شيئًا ... التغييرات التي أجريتها على الكمان تثبت أنني على صواب ... var result لا يزال undefined في جميع الحالات الثلاث. ولست متأكدًا من الحالة التي تحاول تقديمها من خلال توسيع النماذج الأولية ...

أنا متأكد تمامًا من أن سلوك هذه الميزة سيكون بمثابة ماس كهربائى بـ void 0 بدلاً من توليد خطأ. (تعجبني فكرتك أعلاه أنه يجب دائمًا إرجاع 0 باطل في حالة وجود عضو مفقود).

ما هو الناتج المقصود ''?.toString ؟

@ kevinb7 : ماذا يحدث إذا لم يكن ccc وظيفة؟ باستخدام الكود الذي وصفته ، سيتعين على __chain دائمًا إرجاع دالة صالحة ، أو سيتم إصدار خطأ TypeError.

نقطة جيدة.

metaweta : أتخيل أن معظم الناس يتوقعون إشارة إلى الوظيفة toString ، لذلك أرى أين وجهة نظرك ، إنها تتعطل إلى حد ما في الحالة التي تقوم فيها بالوصول إلى أعضاء النموذج الأولي لـ 0 ، false ، أو ''.

: +1:
أضاف Angular 2 عامل Elvis Operator إلى بنية القالب الخاصة بهم

metaweta :

ما هو الناتج المقصود من ""؟ .toString؟

إذا كنت تقصد ''?.toString() فسيكون:

if ('' != null) {
  ''.toString();
}

عينة

ربما يمكننا وضع اقتراح قروي لهذا

@ kevinb7 إنه موجود بالفعل: http://wiki.ecmascript.org/doku.php ؟

لقد أجريت بعض الاختبارات السريعة لتنفيذ هذا على PropertyAccessExpression كحالته الخاصة ولكن لم تنجح بشكل جيد لأننا نحتاج حقًا ?. لنكون رابطيًا صحيحًا (بدلاً من الارتباط الأيسر مثل . ) وإلا يصبح الباعث معقدًا بلا داعٍ.

هناك تعليق من BrendenEich هنا يعكس هذا أيضًا.

لقد أجريت بعض الاختبارات السريعة لتنفيذ ذلك على موقع PropertyAccessExpression باعتباره حالته الخاصة ولكن لم ينجح الأمر كما نحتاج حقًا؟ أن تكون ترابطيًا صحيحًا (بدلاً من الارتباط الأيسر مثل.) وإلا يصبح الباعث معقدًا بلا داع.

basarat هل يمكنك توضيح ذلك؟ مثال على الفرق بين الترابط الأيمن والرابط الأيسر ?. سيكون مفيدًا جدًا بالنسبة لي.

تضمين التغريدة

مثال على الفرق بين الحق النقابي واليسار النقابي ؟. سيكون من المفيد جدا بالنسبة لي.

يُترك . ترابطيًا لذا فإن التعبير foo?.bar?.baz يصبح في AST (إذا تعاملنا مع ?. بنفس الطريقة):

                    // foo.bar.baz = PropertyAccessExpression
                    //   .expr foo.bar =  PropertyAccessExpression
                    //     .expr foo = Identifier
                    //     .name bar = Identifier
                    //   .name baz = Identifier

انبعاث JavaScript المطلوب هو

foo != null ? (ref_1 = foo.bar) != null ? ref_1.baz() : void 0 : void 0;

من الأسهل القيام بذلك (خاصة _ بشكل متكرر_) إذا كان لدينا ما يلي في AST:

                    // foo.bar.baz = PropertySafeAccessExpression
                    //   .name foo =  Identifier
                    //   .expr bar.baz = PropertySafeAccessExpression
                    //      .expr bar = Identifier
                    //      .name baz = Identifier

فكر فقط في _كيف ستحول أول AST إلى JavaScript_ وستكون التعقيدات أكثر وضوحًا. أتمنى أن يساعد هذا:

zlumer ، لإضافة ما قالته @ basarat ، سأضع المثال 1 + 2 + 3 .

عند التحليل ، يتعين علينا تحديد أي من هذه العمليات سيحدث أولاً.

إذا كان + مترابطًا يسارًا ، فسيتم تفسير ذلك على أنه ((1 + 2) + 3) .

إذا كان + صحيحًا ، فسيتم تفسير ذلك على أنه (1 + (2 + 3)) .

قد تتساءل عما إذا كان هذا سيحدث فرقًا بالفعل. في JavaScript سيكون! خذ بعين الاعتبار المثال "hello" + 2 + 3 .

• الترابط الأيسر: (("hello" + 2) + 3) => ("hello2" + 3) => "hello23"
• الحق النقابي: ("hello" + (2 + 3)) => ("hello" + 5) => "hello5"

(بالنسبة للسجل ، يستخدم JavaScript / TypeScript الارتباط الأيسر لعامل التشغيل + .)

basarat ، فهمي لما قاله BrendanEich (ويمكنه أن يصححني إذا كنت مخطئًا - آسف على ping!) هو _not_ أن ?. هو رابط صحيح ، ولكن يمكن الوصول إلى خاصية الحالات الخاصة لـ CoffeeScript على على حق ?. أن يكون رابطًا صحيحًا. على سبيل المثال ، سيتم تحليلها

o.p?.q.r.s

كما

((o . p) ?. (q . (r . s))) # or something close to this

بدلا من

((((o . p) ?. q) . r) . s)

لأنه أسهل في الانبعاث.

تحتاج AST الخاصة بنا إلى تقديم تحليل دلالي عقلاني جيدًا ، لذلك يمكن أن تكون إجراءات الانبعاث الخاصة بنا أكثر تعقيدًا قليلاً لتلائم هذه الحاجة.

basaratDanielRosenwasser شكرا لك على الشرح. حتى الآن أفهم ذلك ، لكنني ما زلت غير متأكد من شيء واحد.
الرابط الأيسر ?. واضح جدًا ومتوقع:

foo?.bar?.baz

يصبح (تقريبًا):

var ref = ((ref = foo) == null) ? null : ((ref = ref.bar) == null) ? null : ref.baz;

لكنني لا أفهم على الإطلاق كيف يمكن أن يعمل الحق النقابي ?. . هل يمكنك إعطاء مثال؟

لكنني لا أفهم على الإطلاق كيف يمكن أن يكون الحق النقابي؟ الشغل. هل يمكنك إعطاء مثال من فضلك

zlumer سيترك سلوك وقت التشغيل ترابطيًا. كنت أتحدث للتو عن AST كما أوضح DanielRosenwasser أيضًا: is not that ?. is right-associative, but that CoffeeScript special cases property accesses on the right of the ?. to be right-associative .

تحتاج AST الخاصة بنا إلى تقديم تحليل دلالي عقلاني جيدًا ، لذلك يمكن أن تكون إجراءات الانبعاث الخاصة بنا أكثر تعقيدًا قليلاً لتلائم هذه الحاجة.

DanielRosenwasser شكرا على ردود الفعل: روز:

basarat شكرا لك فجأة أصبح كل شيء واضحا: مبتسم:

على غرار basarat 's Feb comment، I .... _sigh _...

ومع ذلك ، إذا فكرت في الأمر ، فستكون 99٪ من حالات الاستخدام لهذا الغرض هي التحقق من مؤشر فارغ إلى كائن. بصراحة ، من يفعل x?.b?.c عندما x هو number ؟ ليس هناك الكثير من حالات الاستخدام الواقعية للسلاسل الطويلة عندما لا نتحدث عن كائن (مع استثناء محتمل لـ string ). بالنسبة للسلاسل القصيرة ، أعتقد أنه يمكننا العيش x && x.b أو x === 0 ? null : x.b .

لذا ، هل يمكننا ، نوعًا ما ، أن نقول إن ?. يعمل فقط على أنواع الكائنات؟ أي نوع آخر يلقي خطأ في بناء الجملة. وتستدعي الدالة disallow في جانب السلسلة.

ثم يتم تحويل كل شيء إلى a && a.b && a.b.c .

schungx ماذا لو كان العضو في السلسلة من النوع "أي"؟ عدم السماح تمامًا؟ أو فقط دعها تمر وتتمنى الأفضل؟

حسنا اقتراحي؟ عدم السماح تمامًا. غير أنيق مثل الجحيم ، أعرف ... :-)

لكن منطقتي:

1. هذا عقرب قصير ، لذلك إذا كان شخص ما يستخدم any ، فقط استخدم اليد الطويلة.
2. إذا كان شخص ما يستخدم TypeScript ، فمن المرجح أنه يستخدمها لدعم الكتابة ، لذلك نأمل ألا يكون لديه العديد من any حوله!
3. يجب التعامل مع any بعناية. إن السماح باستخدام مثل هذه الأيدي القصيرة بنوع مرن مثل any يطلب بالفعل حدوث أخطاء. في رأيي ، يجب أن يكون any محدودًا قدر الإمكان. إنه نوع من مثل C (void *) - حقيقة حصولك على سلاح نووي لا تعني أنه يجب عليك تشغيله لمجرد أنك تستطيع!

سيكون هذا عامل رائع !! خاصة بالنسبة لـ ES6 / ES7 / TypeScript

var error = a.b.c.d; //this would fail with error if a, b or c are null or undefined.
var current = a && a.b && a.b.c && a.b.c.d; // the current messy way to handle this
var currentBrackets = a && a['b'] && a['b']['c'] && a['b']['c']['d']; //the current messy way to handle this
var typeScript = a?.b?.c?.d; // The typescript way of handling the above mess with no errors
var typeScriptBrackets = a?['b']?['c']?['d']; //The typescript of handling the above mess with no errors

ومع ذلك أقترح واحدة أكثر وضوحا - حتى لا تخلط؟ من أ؟ عبارات b: c مع عبارات a .b:

var doubleDots = a..b..c..d; //this would be ideal to understand that you assume that if any of a, b, c is null or undefined the result will be null or undefined.
var doubleDotsWithBrackets = a..['b']..['c']..['d'];

بالنسبة لتدوين القوسين ، أوصي بنقطتين بدلاً من نقطة واحدة لأنها تتوافق مع النقاط الأخرى عند استخدام غير الأقواس. ومن ثم فإن اسم الخاصية هو فقط ثابت أو ديناميكي عبر الأقواس.

نقطتان ، تعني ما إذا كان توقف المعالجة فارغًا أو غير محدد وتفترض أن نتيجة التعبير لاغية أو غير محددة. (حيث أن d ستكون فارغة أو غير محددة).

تجعل النقطتان الأمر أكثر وضوحًا ، وأكثر وضوحًا وأكثر اتساعًا في المساحة حتى تفهم ما يحدث.

هذا لا يعبث بالأرقام أيضًا - كما هو الحال ليس نفس الحالة على سبيل المثال

1..toString(); // works returning '1'
var x = {};
x.1 = {y: 'test' }; //fails currently
x[1] = {y: 'test' }; //works currently 
var current = x[1].y; //works
var missing= x[2].y; //throws exception
var assume= x && x[2] && x[2].y; // works but very messy

حول الأرقام خياران: مكالمتك أيهما يمكن اعتمادها ، لكني أوصي بالخيار الأول للتوافق مع القواعد الحالية!

1. يجب أن تفشل كما هي الآن ( x.1.y == runtime error )

var err = x..1..y; // should fail as well, since 1 is not a good property name, nor a number to call a method, since it's after x object.

1. يجب أن يعمل لأنه يفهم أنه ليس رقمًا يستدعي خاصية من Number.prototype

var err = x..1..y; // should work as well, resulting 'test' in this case
var err = x..2..y; // should work as well, resulting undefined in this case

بأسماء ديناميكية:

var correct1 = x..[1]..y; //would work returning 'test'
var correct2 = x..[2]..y; //would work returning undefined;

ما رأيكم يا اصدقائي؟

ستعمل بنية PS foo?.bar و foo?['bar'] أيضًا.

ومع ذلك ، فإن استخدام عامل التشغيل الحالي ? : و ?. قد يكون مربكًا للغاية في نفس السطر.

على سبيل المثال باستخدام ?. و ?['prop']

var a = { x: { y: 1 } };
var b = condition ? a?.x.?y : a?.y?.z;
var c = condition ? a?['x']?['y'] : a?['y']?['z'];

على عكس النقاط المزدوجة .. و ..['prop']

var a = { x: { y: 1 } };
var b = condition ? a..x..y : a..y..z;
var c = condition ? a..['x']..['y'] : a..['y']..['z'];

أيهما يبدو أكثر وضوحا بالنسبة لك؟

مثير جدا. : +1:

IMHO ، ستكون النقطتان أكثر إرباكًا. هناك لغات حيث تمثل النقطتان نطاقًا (على سبيل المثال 1..4 ) وقد تضيف TypeScript هذه الميزة في المستقبل.

تحتوي علامة الاستفهام أيضًا على المعنى الدلالي لعدم اليقين أو الشرطي ولا تنقل النقطتان نفس المعنى.

schungx عادل بما فيه الكفاية ، لكنه سيساعد الاحتمالات الغريبة مثل هذا: a?['b'] أو هذا a?() .

+1 ?

a?['b'] و a?() يتصرفون بشكل جيد في القهوة ، ويبدون جيدًا بالنسبة لي.

ولكن بعد ذلك مرة أخرى ، قد أكون مجرد عمياء.

+1 روبي نفذ للتو عامل التشغيل الوجودي https://twitter.com/mikepack_/status/657229703443451904. يحتاج الطبع إلى هذا أيضًا ، بغض النظر عن البنية المحددة.

هذا من شأنه أن يجعل الكود أنظف 👍

+1 تحتاج هذا!

من فضلك ، إيمينينت؟ عامل التشغيل ، كما يفعل C #

+1 لقد فاتني هذا لفترة طويلة

+1
من القبيح الكتابة: بعض المتغير && بعض المتغير. بعض الأعضاء
متى يمكنك أن تكتب: someVariable؟ .someMember

+1 ، سيكون هذا رائعًا .... (الميزة الأكثر طلبًا بالنسبة لي)

+1 ، إنها فكرة جيدة!
فقط ، إذا كان الكائن معقدًا ، فسيكون التعبير مليئًا بـ؟. بعد كل خاصية (var result = myValue؟ .a؟ .b؟ .c؟ .d؟ .e؛) عندما أحتاج إلى استلام قيمة من آخر خاصية (var نتيجة =؟ myValue.abcde؛).

+1 - يمكن القول أن هذه واحدة من أعظم ميزات CoffeeScript وهي إلى حد بعيد ميزة TypeScript الأكثر رواجًا لدى فريقي بعد تحويل الكثير من الكود الخاص بنا من CS إلى TS.

+1 مع ذلك ، هذا معقد جدًا:

var x = { y: { z: null, q: undefined } };
var z: x|y|z = x?.y?.z;

أحب هذا:

var x = { y: { z: null, q: undefined } };
var z: z|void = x?.y?.z;

نوع x?.y?.z هو دائمًا نوع الحقل z . بالطبع يجب أن يكون النوع لاغياً وقد تكون القيمة الفعلية لاغية. إذا كان غير فارغ ، فيجب أن يكون من نوع الحقل z .

+1 يتماشى هذا مع رؤية Typescript لتيسير تطوير مشاريع JS المعقدة واسعة النطاق.

أي تحديثات على هذا؟ هل هذه حالة تصويت المجتمع لهذه الميزة ليتم النظر فيها؟ أم تم النظر فيه ولكن هناك بعض التحديات الهندسية؟

لا توجد تحديثات حتى الآن لأن إدخال صياغة جديدة على مستوى التعبير أمر خطير بدون نوع من الاقتراح من لجنة ECMAScript.

راجع https://github.com/Microsoft/TypeScript/issues/16#issuecomment -57645069.

فيما يلي نقاش أكثر حداثة حول العوامل الوجودية (الكثير من الأفكار ، ولكن لا يبدو أن هناك الكثير من الإجراءات):

• عامل تشغيل وجودي / عامل انتشار فارغ

أين يجب أن أكتب "+1" للمساعدة في إحضاره إلى ES؟

تضمين التغريدة

إغلاق هذا الآن. نظرًا لعدم وجود أي شيء خاص بـ TypeScript يتطلب ذلك على مستوى التعبير ، يجب أن يحدث هذا النوع من التغيير الكبير في المشغل في لجنة المواصفات ES بدلاً من هنا.

قد تكون أسلاك التعثر العامة لإعادة تقييم هذا اقتراحًا ES ملموسًا يصل إلى المرحلة التالية ، أو إجماعًا عامًا من لجنة ES على أن هذه الميزة لن تحدث لفترة طويلة (حتى نتمكن من تحديد الدلالات الخاصة بنا وتكون معقولة متأكد من أنهم سوف "يفوزون").

تمتص الحياة

حذف قائمة بذاتها: +1: ث. الرجاء استخدام ميزة ردود فعل GitHub أو إرسال الزهور والحلوى إلى أقرب ممثل TC39.

بمجرد أن اعتدت على ذلك في فن القهوة والسويفت ، ليس هناك عودة. TS ميت بالنسبة لي كما هو الحال حاليًا.

algesten يمكنني الموافقة على swift إذا أخذنا في الاعتبار اللغة نفسها ، ولست متأكدًا من الدعم طويل المدى coffescript (أستخدم CoffeScript في مشاريع الإنتاج). قد نتفق على التأكد من اتجاهات تحليلات اللغة كما في يونيو 2016 مثل هذا حيث يمكننا أن نرى بوضوح ما يحدث لـ coffescript مؤخرًا ، بينما شهد TypeScript أسرع نمو في السنوات الماضية:

TypeScript: خارج Go أو Swift ، اللغة الأسرع نموًا التي لاحظناها في السنوات الأخيرة هي TypeScript. حققت مجموعة JavaScript superset و Angular 2 المدعومة من Microsoft مكاسب كبيرة للربع الثاني على التوالي ، حيث قفزت من المركز 31 إلى المركز 26. كان هذا أكبر تغيير منفرد في أي لغة من أفضل 30 لغة ، وثاني أكبر قفزة عامة (Standard ML ، 7 نقاط). في الواقع ، في المرتبة رقم 26 ، أصبحت TypeScript مرتبطة الآن بـ Erlang ، بقعة واحدة خلف Powershell وأربعة خلف CoffeeScript ، والتي تقع خارج Top 20. السؤال الذي يواجه اللغة ليس ما إذا كانت يمكن أن تنمو ، ولكن ما إذا كان لديها الزخم لاختراق أفضل 20 في الربعين أو الثلاثة أرباع القادمة ، متجاوزًا أمثال CoffeeScript و Lua في هذه العملية.

حتى عام 2014 ، كانت الاتجاهات coffescript أكثر من إيجابية كما يمكنك أن تنظر هنا ، وهذا هو الوقت الذي بدأ فيه التراجع.

مع التحقق من القيمة الفارغة الصارمة 2.0 (غير المحددة) الجديدة ، يعد هذا أمرًا ضروريًا ، وإلا فلن تتمكن من استخدام تسلسل الوظائف!

يجب أن يكون هذا في الإصدار التالي من ECMAScript. بالنظر إلى أن هذا سيكون مفيدًا في Vanilla JavaScript أكثر من TypeScript ، وبالنظر إلى أن التنفيذ سيكون بطبيعة الحال بمثابة فحص غير محدد أو فارغ بدلاً من التحقق الحقيقي ، يجب أن يكون تافهًا أن يضيف TC39.

سيكون التنفيذ البسيط والذي سيكون اصطلاحيًا في JavaScript ، هو ببساطة قصر الدائرة عند مواجهة إما null أو غير معرف ، وإرجاع غير محدد.

bterlson هل هذا منطقي؟ ما هي احتمالات قبول مثل هذا الاقتراح؟

واحدة من الفوائد العظيمة للنسخة المطبوعة هي "المستقبل يمنحك اليوم". هذه إحدى الميزات التي فوجئت بها غير موجودة بالفعل.

آمل أن تتم إضافته قريبًا بمجرد أن يكون تسلسل الوظائف هو المصطلح الشائع وأن التحقق من القيمة الفارغة الصارمة لم يعد يعمل إلا إذا كان؟. تمت إضافة عامل.

اختبار TS 2 الرائع جعله من الأشياء التي يجب أن يكون لديك!

من خلال قراءة هذا الموضوع ، تفاجأت نوعًا ما من عدم حصول ذلك على مزيد من الاهتمام من المشرفين.

في عالم مثالي ، يجب أن تقود TypeScript الطريق لـ ES وليس بشكل عكسي. على محمل الجد ، أين سيكون TypeScript الآن إذا كان فريق TS سينتظر دائمًا ESx لاقتراح ميزة أو بناء جملة وإنهائها؟

هذا النحو هو حقا "يجب أن يكون" ، كما أشار إليه آخرون. حتى أنها تلقت بعض الاقتراحات الجيدة في هذا الموضوع حتى الآن. أعتقد أن التنفيذ يجب أن يتوافق مع هذه التوقعات.

• بشكل عام ، يجب أن يكون التعبير a?.b صالحًا في وقت الترجمة إذا وفقط إذا كان a.b صالحًا.
• يجب أن تقيم كل تعبير في السلسلة مرة واحدة فقط.
• يجب أن تكون دائرة قصر.
• إذا وصل التنفيذ إلى تعبير متوسط null أو undefined ، فيجب أن تكون هذه القيمة هي القيمة المرجعة.

ما رأيك في الأجزاء التي يمكن أن تؤدي إلى خلافات عندما يحددها ES؟

بالنسبة إلى a?.b لا أرى أي تعارض مع التركيبة الحالية (والمستقبلية؟). إذا عثر المحلل اللغوي على الرمز المميز ?. ، فيمكنه معاملته على أنه "عامل تنقل آمن" (مع التوقعات كما هو موضح بواسطةcervengoc).

تنشأ تعارضات بناء الجملة فقط عند السماح بـ a?(b) و a?[b] ، حيث يمكن أيضًا تفسيرها على أنها بداية تعبير عامل تشغيل ?: ثلاثي. لكن بالنسبة للمبتدئين ، أعتقد أنه يمكن تنحيتها جانبًا ودعم بناء الجملة فقط a?.b سيجعل الكثير من المطورين سعداء بالفعل!

في عالم مثالي ، يجب أن تقود TypeScript الطريق لـ ES وليس بشكل عكسي.

من حيث بناء الجملة على مستوى التعبير ، نحن نختلف تمامًا. هناك لجنة تقود معيارًا لسبب ما - ليس بحيث يمكن للإجراءات الفردية التي يقوم بها لاعب واحد أن تقرر من جانب واحد مستقبل JavaScript.

هذا النحو هو حقا "يجب أن يكون" ، كما أشار إليه آخرون.

إذا كان هذا ضروريًا لـ TypeScript ، فهو ضروري أيضًا لـ JavaScript! مرة أخرى ، خذ مخاوفك إلى لجنة ECMAScript .

ما رأيك في الأجزاء التي يمكن أن تؤدي إلى خلافات عندما يحددها ES؟

على الأقل ، أعتقد أنه سيكون هناك خلاف حول ما إذا كان بناء الجملة قصير الدوائر إلى null أو undefined عند مواجهة هذه القيم ، أو دائمًا دوائر قصيرة إلى undefined . سيكون هناك أيضًا بعض الخلاف حول ما إذا كان شكل من أشكال بناء الجملة بين قوسين مدعومًا أم لا. هناك أيضًا سؤال حول ماهية سلوك a?.b.c . هناك أيضًا مسألة ?. مقابل .? مقابل a.b? . هناك سؤال حول تأثير هذا على عامل التشغيل delete .

يبلغ طول موضوع ES DIscuss في هذا الموضوع أكثر من 100 تعليق. لا يوجد نقص في الغموض! من السهل النظر إلى مثال واحد بمعزل عن الآخرين والاعتقاد بأنه لا يمكن أن يكون هناك الكثير من الحالات الجانبية. هناك. ربما لهذا السبب لم يدافع أحد عن هذا في TC39 حتى الآن و _ أيضًا_ لماذا لا نتسرع في إضافة ميزة بها الكثير من الغموض حول الطريقة التي يجب أن تتصرف بها.

أعتذر ، لم أقرأ الموضوع المذكور ، بالتأكيد سألقي نظرة عليه لأرى المزيد.

نحن نرى هذا بشكل مختلف بعض الشيء. حول اللجنة ، في رأيي الصادق ، يعد هذا أحد أكبر الأسباب التي تجعل جافا سكريبت لن تكون أبدًا _ جيدة_. فقط على سبيل المثال ، العديد من أنجح البرامج التي رأيتها (مثل Total Commander أو IrfanView) ناجحة لأنها صيانتها وصممت من قبل شخص واحد ، وليس من قبل لجنة * ". بالطبع هذا ليس بالكامل المثال الصحيح ، لكنني على يقين من أنه إذا كنت على سبيل المثال قد صممت وحدك ES6 بالكامل ، فسيكون العالم مكانًا أفضل الآن.

أيضًا ، الغموض الذي ذكرته موجود في 99٪ _نظري_ من الأشياء ونوعًا ما غير ذي صلة من جانب المطور. من الذي سيهتم بما يعود ، null أو undefined ؟ فقط اختر واحدة ، وسوف نستخدمها على هذا النحو.

بشكل عام ، أنت وتلك اللجنة في جانب مختلف عن معظمنا ، والأشياء من هذا الجانب عادة ما تكون أكثر تعقيدًا مما هي عليه بالفعل. وهذا يمكن أن يؤدي إلى بعض النتائج السلبية على أقل تقدير. لا تأخذ الأمر على محمل شخصي ، ولكن وفقًا لتجربتي بشكل عام ، من الأفضل أن يخرج بعض الأشخاص من غرفة الاجتماعات كثيرًا ويلقون نظرة على بعض الرموز.

بالطبع لا تهم ، لا تأخذ أي شيء على محمل شخصي ، لدي احترام كبير لك ولجميع فريق TS ، لأنك أحدثت ثورة في تطوير العديد من المطورين من جانب العميل ، بما في ذلك أنا ، وأشكرك على كل عملك. نحن فقط نشعر بخيبة أمل بعض الشيء بشأن هذا بالتحديد على ما أعتقد.

فكر أخير. لقد مررت عبر سلسلة ES المذكورة ، وهناك شيء واحد مؤكد تمامًا: إنهم يبالغون في تعقيده. يريدون تصميم شيء جيد لكل سيناريو.

أنا شخصيا سأكون راضيا تماما وسعداء بمشغل وصول عضو مشروط. لا تحتاج إلى استدعاء شرطي ، توقيع فهرس شرطي ، لا تحتاج إلى دعم كل سيناريو خيالي وهو كود JS صالح. هذا كل شئ. لكن بدلاً من ذلك ، من المحتمل أن يظلوا جالسين هناك ويناقشون كيفية القيام بكل شيء في وقت واحد ، وهي خطة رائعة ، لكن لن يكون لدينا أي شيء في نهاية اليوم.

بشكل عام ، أنت وتلك اللجنة في جانب مختلف عن معظمنا ، والأشياء من هذا الجانب عادة ما تكون أكثر تعقيدًا مما هي عليه بالفعل.

لا أعتقد أنك تعكس الوضع الحقيقي لـ Ryan أو TC39 بدقة. وضع رايان وفريق TypeScript أهداف تصميم واضحة جدًا لـ TypeScript. أحد الأهداف الأصلية والتي لا تزال حديثة للغاية هو أن TypeScript هو مجموعة شاملة من JavaScript. ليست اللغة التي يريدها الناس (مثل Dart و Haxe). عندما يتعلق الأمر بالصياغة اللغوية ، تعلم فريق TypeScript بالطريقة الصعبة تكلفة ابتكارها مسبقًا (مثل الوحدات النمطية). نحن نتجه بسرعة إلى تحدٍ مع أعضاء خاصين في الفصول الدراسية أيضًا ، حيث يكون بناء جملة ES المقترح غير متوافق تمامًا مع بناء الجملة الذي يستخدمه TypeScript. لماذا ا؟ لأن ما قد يبدو غير معقد على السطح من المستحيل تحقيقه نظرًا لتحديات وقت التشغيل للغة.

TC39 قد "حفظ" جافا سكريبت في رأيي. تم التخلي عن ES4 ، ليس لأنه يفتقر إلى الأفكار الجيدة والمبتكرة ، ولكن لأنه سيؤدي إلى كسر الإنترنت. حصل TC39 على شكله الصحيح ، فقد شاركوا وكانوا منفتحين تمامًا في مناقشاتهم وكيف يتخذون القرارات وقدموا لنا ES2015 ، والذي يشبه إلى حد كبير ES4 ، لكنه لم يكسر الإنترنت. إنه لأمر مدهش أن لدينا أوقات تشغيل JavaScript تعمل على تشغيل التعليمات البرمجية منذ 10 سنوات على ما يرام ، ولكنها تدعم العديد من التحسينات المهمة للغة. كان ES2016 الهدوء الذي يسبق العاصفة. ES2017 لديه قدر "معقول" من الوظائف والتغيير وعملية تحكم واضحة تقود الاتجاه الصحيح.

لذا من الواضح أن التواجد في "الجانب المختلف" من الأشياء قد نجح ، في رأيي. الذي يتفوق على نفعية ميزات "يجب أن يكون".

kitsonk لم أقصد "جانب مختلف" بشكل سلبي ، ولا سيما أنني لم أقصد التقليل من قيمة العمل الذي تم وضعه في TypeScript أو ES6. ما هو أكثر من ذلك ، أن أفضل شيء في TypeScript IMO هو أنه يحتوي بالفعل وله هدف تصميم واضح ، وهو محمي جيدًا من أن يصبح فسادًا مثل العديد من العناصر مفتوحة المصدر الأخرى.

أردت فقط أن أقول إن هذه الميزة بالذات هي مثال واضح على المكان الذي سينتهي فيه المطاف بمجموعة من العبقرية إلى الإفراط في التفكير والمبالغة في تعقيد الأشياء ، بدلاً من مجرد اتباع الطريقة السهلة البسيطة ، وقبول بعض القيود مثل عدم دعم الدعوات أو توقيعات الفهرس ، إلخ. حتى أن شخصًا ما في ذلك المنتدى اقترح استخدام هذا النحو في المهام ، وهو نوع من الجنون. ما زلت أعتقد أن هذه الظاهرة غير منتجة بهذا المعنى.

أتفهم أنه من جانبكم ، من المؤلم أن الأعضاء الخاصين على سبيل المثال أصبحوا غير متوافقين مع مفهوم ES6 النهائي. لكن من ناحية أخرى ، حصلنا عليها. قبل ES6. وهذه هي النقطة الأساسية من جانبنا. بشكل تقريبي ، نحن لا نهتم بكيفية إدارتك للشفرة المناسبة لها ، فنحن فقط نستخدمها بكل سرور. نفس الشيء مع الوحدات ، وكل شيء. لم نر (أو على الأقل أنا) تلك الآلام ما تتحدث عنه ، كنا دائمًا سعداء بالأعضاء أو الوحدات الخاصة.

هذه الميزة الخاصة موجودة في CoffeScript كما قرأت عنها. لماذا يتعين علينا نحن المطورين البسطاء دائمًا تقديم تنازلات عند اختيار منصة / مكتبة / مكون إضافي ، وما إلى ذلك؟ أعني دائما . هذا نوع من المزعج. هنا لدينا لغة رائعة ، ذات إمكانات كبيرة ، والتي تترك كل المشاركين الآخرين وراءهم (بما في ذلك ES!) ، والتي أحدثت ثورة في جزء كبير من التطوير من جانب العميل ، وعندما يتعلق الأمر بهذه الميزة "البسيطة" ( أعني جزء وصول الأعضاء على الأقل) ، نسمع أنه لن يتم تنفيذه حتى يلتزم ES بذلك.

أردت أن أقدم للناس تنبيهًا سريعًا بأن هذه الميزة قد انتقلت من المرحلة 0 إلى المرحلة 1 في اجتماع TC39 اليوم.

الالتزام ذي الصلة: https://github.com/tc39/proposals/commit/cb447642290a55398d483f5b55fb7f973273c75d
جدول أعمال الاجتماع: https://github.com/tc39/agendas/blob/master/2017/01.md

رائع! انه ضخم!

يستحق أيضًا ارتباطًا بـ https://github.com/claudepache/es-optional-chaining

بعض "المفاجآت" التي أراها هنا (لا أقول إنني لا أوافق ، فقط أشياء كان من الممكن أن نفعلها بشكل مختلف لو فعلنا ذلك سابقًا):

• لا يتم إنتاج $ # null 0 $ # $ من تعبير a?.b : عندما يكون a null ينتج هذا undefined بدلاً من ذلك
• ~ الانتشار في النقاط المتسلسلة: لن يتم طرح a?.b.c.d إذا كانت الخصائص b و c هي undefined ~ لا يستطيع Ryan القراءة
• ~ الانتشار في وجود الأقواس : حتى (a?.b).c لن يتم طرحه إذا كان b غير محدد ~ Ryan لا يمكنه القراءة
• ~ يحدث الانتشار حتى في استدعاءات الطريقة: سيعيد a?.b.c().d undefined إذا أرجع الاستدعاء c null ~ لا يستطيع رايان القراءة
• مشغل delete معتمد
• صيغة الأقواس مدعومة a?.[x]
• صيغة استدعاء الوظيفة مدعومة func?.(...args) ، حتى بالنسبة للمكالمات غير المتعلقة بالطريقة (!)

أتوقع رؤية التغيير في تلك المجالات من الآن وحتى المرحلة الثانية.

أعتقد أن القهوة حصلت عليها بشكل صحيح.

يرمي a؟ .bc إذا كان b غير محدد.

a؟ () و a؟ [0] كلاهما جيد.

• التكاثر في النقاط المتسلسلة: لن يتم إلقاء a؟ .bcd إذا كانت خصائص b و c غير محددة
• التكاثر في وجود الأقواس: حتى (أ؟. ب). ج لن يرمي إذا كان ب غير محدد
• يحدث الانتشار حتى في استدعاءات الأسلوب: a؟ .bc (). سيعود d غير معرف إذا أعاد استدعاء c فارغًا

هذه النقاط لا تبدو دقيقة بالنسبة لي. من الاقتراح:

a?.b.c().d      // undefined if a is null/undefined, a.b.c().d otherwise.
                // NB: If a is not null/undefined, and a.b is nevertheless undefined,
                //     short-circuiting does *not* apply

واو ، لقد أخطأت تمامًا في قراءة ذلك. أنت على حق. التحديث

algesten من الاقتراح الأصلي:

a?.()

b?.[0]

حلو. يمكن أن يكون عامل التشغيل نوعًا من ?. ثم.

هناك بعض المحادثات الإضافية التي تحدث هنا: https://github.com/estree/estree/issues/146

اقتباس يمكن تطبيقه جيدًا: «اجعل الأشياء البسيطة سهلة ، والأشياء الصعبة ممكنة ». وبالتالي ، ربما يتم دعم الحالات الأكثر شيوعًا بشكل جيد ، بينما يتم تخطي (على الأقل في البداية) الحالات المعقدة / النادرة ، بينما لا يزال يُسمح لها "يدويًا" باستخدام بنية أطول (موجودة).

جمعية البناء الخيرية

let a = b?.c?.d?.e;

ل:

let a;
try{
   a = b.c.d.e;
}catch(e){
   a = undefined;
}

cedvdb دلالات مختلفة تمامًا - الاستثناءات التي يتم طرحها في حروف الاستيعاب لا ينبغي أن تسبب الاندماج

تضمين التغريدة

هل هذا على الرادار للتنفيذ الآن ، أم أن فريق TS سينتظر اقتراح ES للمضي قدمًا؟

إنه على قائمتنا القصيرة. لا يزال لدينا بعض الأسئلة / المخاوف ولكن يجب أن ترى حركة في هذا الشأن في الشهر القادم.

لست متأكدًا من مصدر تعليق mhegazy - عدد الأسئلة المفتوحة في مقترح TC39 كبير جدًا بالنسبة لنا للقيام بعمل هادف هنا. على وجه التحديد ، يجب معالجة الأسئلة حول كيفية تفاعل null و undefined وأي بناء جملة مدعوم فعليًا أولاً. المرحلة 2 هي الحد الأدنى المطلق ونحن نفضل المرحلة 3 بالنظر إلى التأثير على سلوك وقت التشغيل.

هل هذا الرمز يعمل ببساطة؟

a == undefined ? expression : undefined

expression تعني ax ، يمكن أيضًا إنشاء a [x] ، a (x) ، delete هنا

ثم a?.b?.[c]?.(d) سيولد

a == undefined ? (a.b == undefined ? (a.b[c] == undefined ? a.b[c](d) : undefined) : undefined) : undefined

يبدو أنه سيمر عبر كل حكم RyanCavanaugh

إذا كرهت عامل التشغيل == ، فقد يكون أيضًا a === undefined || a === null

@ zh99998 أنت _have_ تكره == لأن '' و 0 متساويان أيضًا. يُقال تقريبًا أن سلوك وقت التشغيل يجب أن يكون نوعًا من الاختيار على (typeof value === 'object' || typeof value === 'function' || typeof value === 'symbol') && value !== null ، والذي أصبح الآن معقدًا نوعًا ما.

كما قال RyanCavanaugh ، من غير المرجح أن يتقدم حتى يتقدم اقتراح TC39 إلى المرحلة 2 أو 3 على الأقل.

أرى أن == يساوي null و undefined فقط
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Equality_comparisons_and_sameness

وتم اجتياز الاختبار في وحدة تحكم الكروم:

'' == undefined
false
0 == undefined
false

@ kitsonk undefined يجبر فقط على القيمة null والعكس صحيح. لا توجد قيمة أخرى تفرض على غير محدد أو لاغٍ.

يبدو أنك مرتبك مع القيم الزائفة. 0 و "" زائفان حقًا ، لكنهما لن يتم إكراههما على قيمة لاغية أو غير محددة.

== يعني الإكراه. null == 0 خطأ لأنه لا يوجد شيء ما عدا غير المعرف يمكنه الإكراه على قيمة خالية. الشيء نفسه ينطبق على undefined == 0 .

يمكن أن يكون مثال آخر

    if(!NaN) console.log("NaN is falsy") // NaN is falsy
    if(false == NaN) console.log("NaN coerces to false")
   else console.log("NaN doesn't coerce to false");// NaN doesn't coerce

يمكنك الحصول على الصورة.

أرى الكثير من المحاولات باستخدام عوامل التشغيل الثلاثية ، ولكن أي تنفيذ يشير إلى نفس الخاصية عدة مرات قد يؤدي إلى آثار جانبية غير متوقعة.

لحسن الحظ ، تحتوي JavaScript على IIFE ، لذا يمكنك تخزين نتيجة الموصل في معلمة دالة ، والرجوع إليها بقدر ما تريد وعدم تقييمها أبدًا أكثر من مرة. في المثال أدناه ، قمت بإنشاء coalesce lambda يمكن استدعاؤها عدة مرات بدلاً من التعبير الذي يحتوي على عوامل ?. .

الشيء الوحيد الذي يحتاج منفذو اللغة إلى الاهتمام به هو استدعاءات المصفوفات والوظائف في منتصف التعبير. أعتقد أن المترجم يمكنه التعامل مع اكتشاف تلك المواقف وإلحاق هذه التعبيرات ببساطة في نهاية استدعاء الاندماج.

const coalesce = (x: any, y: string) => x == null ? null : x[y];

const x = {
    y: {
        z: "Hello, World!!!"
    },
    f: () => "Foo!",
    a: ["Array!"]
};

// x?.y?.z
const value1 = coalesce(coalesce(x, 'y'), 'z');

// x?.f()
const value2 = coalesce(x, 'f')()

// x?.a[0]
const value3 = coalesce(x, 'a')[0]

لاحظ أنه ليست هناك حاجة لعموم فعلي يسمى "اندماج". يمكن تضمين هذا الرمز مباشرة في أي تعبير. قد يقلل من سخام إعطائه اسمًا ، على الرغم من ذلك.

أنا لست مهتمًا جدًا بالصياغة المستخدمة للمشغل أو إذا كان منفذي اللغة يريدون انتظار معيار. فقط اعتقدت أنني سأتباهى بمقاربة أخرى.

يؤدي هذا أيضًا إلى إظهار الحاجة إلى عامل تشغيل ?? . في C # ، يستبدل هذا أي تعبير null بكل ما هو على اليمين.

string x = null ?? "Hello";
````

In JavaScript, it is more idiomatic to use `||` to replace "falsey" values with the value on the right. 

```javascript
var x = null || "Hello";

لسوء الحظ ، تلتقط المصداقية عددًا كبيرًا جدًا من حالات الحافة ( 0 ، false ، إلخ). عند العمل مع عامل اندماج فارغ ( ?. ) ، عامل ، فأنت تريد شيئًا محددًا لـ null -ness.

const x = { y: "" };
const result1 = x?.y || "default";  // I'd expect "default"
const result2 = x?.y ?? "default";  // I'd expect "" 

jehugaleahsa ، في مثالك مع الاندماج يجب أن تكون هناك طريقة لمنع استدعاءات الوظائف ووصول الأعضاء إذا كان الشيك قبل إرجاعه فارغًا. في مثال x؟ .f () ، لا يجب استدعاء f إذا كانت x خالية.

bschlenk لا أعتقد أنني أوافق. أعتقد أنه يجب أن يفشل مع رسالة مثل null is not a function ، لكن هذا لا يعود لي على ما أعتقد.

تعتبر الزيادة الأخيرة في التعليقات التي توضح بالتفصيل الطرق الممكنة لتنفيذ المشغل أمرًا غريبًا بعض الشيء.
ربما يكون التنفيذ مشكلة محلولة.

إذا كنت مهتمًا ، فهناك مكتبة idx ، والتي تشبه إلى حد كبير سلوك عامل التشغيل ?. ، على الرغم من أنها تتجاهل أيضًا الكثير من التفاصيل الخاصة بالمشغل المخطط له. على أي حال ، قد تكون مواصفاتهم لمخرجات الترجمة ذات أهمية لأي شخص يتساءل عن الطرق التي يمكن بها تنفيذ هذه الأشياء.

يمكن أن ينتج TS شيئًا كهذا أو قد ينتج شيئًا مختلفًا تمامًا ، لكن لا أعتقد أن هذا ما ننتظره هنا. لقد قيل عدة مرات هنا أن TS لن تحصل على المشغل حتى يتحرك اقتراح ES في اتجاه واحد أو إلى آخر.

إنها الدلالات التي لا تزال بها بعض المجهول ، المدرجة هنا وهنا .

كن مطمئنًا أننا سننفذ هذا بشكل صحيح ولن نحتاج إلى 100 تعليق أخرى هنا لمعرفة ما يفعله || و ? ... : ... . كما لاحظ noppa ، نحن في انتظار الانتهاء من مواصفات ES.

تم دمج https://github.com/babel/babel/pull/5813 ( العلاقات العامة المصاحبة لبابل ) للتو في Babel preset-stage-1 . المواصفات لا تزال في المرحلة الأولى بالطبع ، لكن هذا سيساعد في دفعها إلى الأمام.

ربما أكون مخطئًا ، لكنني لم أر أي رابط واضح لاقتراح tc39 في هذا الموضوع ، لذا فهذه هي لقراء المستقبل: https://github.com/tc39/proposal-optional-chaining

سيكون تسلسل FYI الاختياري في TC39 الأسبوع المقبل https://github.com/tc39/agendas/blob/master/2017/07.md

jehugaleahsa أعتقد أنك على حق وسأقدم ?? في TC39 الأسبوع المقبل. يمكنك متابعة الاقتراح هنا: https://github.com/gisenberg/proposal-nullary-coalescing

أرى أن السلاسل الاختيارية تمت تغطيتها في TC39 ... ما هو الحكم؟
نأمل أن يكون هذا كافيًا للمضي قدمًا في كتابته المطبوعة 😉

markwhitfeld من ملخص الملاحظات :
مشغلو التسلسل الاختياريون: يظل في المرحلة 1 ، وسيعود لاحقًا بتعريفات أوضح للخيارات المتنوعة والإجابات على الملاحظات

الملاحظات الكاملة هنا: https://github.com/rwaldron/tc39-notes/blob/master/es8/2017-07/jul-27.md#13iia -optional-chaining-worker

لا تزال هناك أسئلة مفتوحة حول الكيفية التي يجب أن يتصرف بها عامل التشغيل ، لذا يبدو أنه لم يصل بعد إلى حالة يمكن إضافته إلى TypeScript.

من هذه الملاحظات ، يبدو أن اللجنة ليس لديها أي فكرة عن كيفية عمل الخيارات المقدمة ، كنت أعتقد أنهم أخذوها للتعرف على المقترحات التي كانوا يخططون لمناقشتها ، قبل مناقشتها. أعتقد أن الأمر سيستغرق وقتًا أطول حتى أتمكن من تمكين عمليات التحقق من القيمة الفارغة الصارمة.

آمل بشدة أن يتماشوا مع الخيار 2/4 (وهو الوضع الحالي للاقتراح على أي حال).

15 يوليو 2014-4 سبتمبر 2017 ، لا شيء حتى الآن

frankfvb من الواضح أنك لم تقرأ المشكلة.

كان هناك الكثير من المناقشات التي قادت الفريق الأساسي إلى الاعتقاد بأنه سيكون من غير الحكمة التنفيذ في هذه المرحلة حتى يتم إحراز مزيد من التقدم في اقتراح ECMAScript والذي سيؤثر بشكل مباشر على وظيفة هذه الميزة في TypeScript.

اعتبارًا من الاجتماع الأخير للجنة معايير ECMAScript ، يظل الاقتراح في المرحلة الأولى نظرًا لأنه يحتوي على بعض الأسئلة الأساسية للغاية حول كيفية تنفيذه. على الرغم من أن TypeScript ليست قاعدة صارمة وسريعة ، إلا أنها ستنفذ مقترحات المرحلة 3 فقط. ينفذ أحيانًا مقترحات المرحلة 2 إذا كانوا يعتقدون أنه ذو أهمية حاسمة ومن المحتمل أن يؤدي الاستخدام في TypeScript إلى تطور المعيار.

لست متأكدًا من كيف يمكن أن يكون أي شخص أكثر وضوحًا بشأن ذلك.

كما قلت سابقًا ، هذا مدرج في قائمتنا القصيرة. نحن ننتظر TC39 للتوصل إلى نوع من الإجماع حول دلالات المشغل. نكره طرحه ثم كسر المستخدمين.

ليس هذا هو الخيط لإعادة صياغة مناقشة TC39

إذا كنت تريد التفكير في الاقتراح ، فانتقل للتعليق عليه في المكان المناسب . لدي آراء أيضًا ولكن إسقاطها في هذا الموضوع لن يفيد في شيء.

لقد صنعت شيئًا بسيطًا يلبي احتياجاتي الحالية. سيعمل فقط على سلسلة حيث يكون كل رابط هو اسم خاصية ، لذا فإن الوصول إلى عنصر في مصفوفة (على سبيل المثال) غير مدعوم.

تنفيذ عامل Elvis Operator بسيط جدًا في TypeScript

أيضًا إذا كان لديك لوداش / شرطة سفلية ، فيمكنك بالفعل استخدام _.get(Book, 'author.name.firstName') الذي سيفعل ما يريده هذا

تحرير: يبدو أن هذه نصيحة سيئة بسبب مشكلات النوع مع طريقة _.get() . انظر التعليق أدناه

tolgaek ، _.get به كتابات سيئة ، حتى مع هذه الكتابة الأفضل (التي لم يتم دمجها بعد ، بسبب المؤلفين) يمكن أن يستنتج النص المطبوع بالتأكيد نوع النتيجة فقط إذا كان عمق العنصر هو 1 ، وفي جميع الحالات الأخرى يكون any ويجب التحقق منه في وقت التشغيل

من ناحية أخرى ، قد يكون النص المطبوع لمشغل elvis قادرًا على استنتاج نوع النتيجة في الكائنات بأي عمق ، وهذا هو السبب في أنني أتطلع إلى عامل elvis

أوه ، فهمت ، لم أكن أعرف أن هناك مشكلة في الكتابة. BjornMelgaard شكرا

mhegazy ألا يمكن تنفيذ هذه الميزة أولاً ووضع علامة عليها كميزة تجريبية؟ أعتقد أنه لا ينبغي أن يواجه الأشخاص مشكلة إذا تم تغيير المواصفات في الميزة التجريبية.

إلفيس غير مستمتع بالانتظار كل هذا الوقت.

لقد هبطت في Babel7. الطباعية ، نحن نسير ببطء .. رجاءً شخص ما افعل هذا.
:)

@ gs-akhan ، ينفذ المكون الإضافي Babel إصدارًا قديمًا من الاقتراح منذ بضعة أشهر. كانت هناك تغييرات على الاقتراح منذ ذلك الحين (بما في ذلك تغيير كبير في كيفية تحليل المشغل) ، ومن المحتمل أن يكون هناك المزيد من التغييرات قبل أن تصل الميزة إلى المرحلة 2 (ناهيك عن المرحلة 3) ، لذا فإن أي كود مكتوب باستخدام babel الحالي قد يتعطل المكون الإضافي عند تحرير الميزة الفعلية. ينفذ Babel عن قصد الميزات المقترحة قبل أن تكون مستقرة بحيث يمكن لمؤلفي المواصفات والأطراف المعنية الأخرى تجربة الميزة على النحو المقترح. لا يعني مجرد تطبيق Babel لإحدى الميزات أنه يمكن تنفيذها بطريقة لا تتطلب تغيير التغييرات في المستقبل.

alangpierce هذا منطقي. شكرا

لقد فهمت أن هذا عامل رائع حقًا ، لكن توفره قبل تسوية قواعده يعد بمثابة مسدس قدم ولن نقوم بذلك. لا يزال سلوك وقت التشغيل للمشغل في حالة تغير مستمر ؛ إذا كتبت رمزًا اليوم ، فقد يتوقف عن العمل غدًا بطرق ليست واضحة على الفور - ربما حوادث نادرة ، ربما تلف البيانات ، من يدري؟ القليل من الصبر الآن سيوفر عليك الكثير من الألم بعد بضعة أشهر على الطريق.

البدء في التفكير في أن هذه التذكرة يجب أن تكون مغلقة (غير مغلقة) حتى تصبح المواصفات جاهزة.

متى ستكون المواصفات جاهزة؟

oliverjanik يمكن العثور على مسودة المواصفات الحالية هنا . هناك بند في جدول الأعمال لدفع الاقتراح إلى المرحلة 2 في اجتماع TC39 القادم (9 / 26-9 / 28). سأقدم هذه الشرائح في ذلك الوقت. بالنسبة للأشخاص الذين يرغبون في المراجعة مبكرًا وتقديم التعليقات ، يرجى تقديم مشكلات بشأن إعادة الشراء للاقتراح .

شكرًا جزيلاً على gisenberg لتأييدنا هذه القضية! كنت أفكر في تجميع عرض شرائح ملخص للمساعدة في توضيح الخيارات حول المشغل التي يمكن استخدامها في اجتماع TC39 لتجنب الالتباس ، لكنك قمت بذلك بالفعل. عمل رائع!
ربما يكون هناك شيء واحد آخر يمكن أن يكون مفيدًا لمحادثة TC39 (ومجموعة الشرائح) وهو النظر إلى الدلالات وبناء الجملة الخاصة بالمشغل بلغات أخرى. على الرغم من أن اللغات الأخرى لا ينبغي بالضرورة أن تملي كيف يجب أن تعمل في جافا سكريبت ، سيكون من المفيد إبقاء المشغل مشابهًا لمشغل اللغات الأخرى لتجنب الالتباس.
حظ موفق في الاسبوع القادم !!!

آسف للخروج قليلاً عن الموضوع مرة أخرى ، لكنني اعتقدت أن بعض الأشخاص هنا قد يجدون أنه من المثير للاهتمام أنه في Flow من الممكن الآن إضافة تعريفات نوع العمل إلى حد ما لوظائف getter الآمنة مثل _.get .

مثال: flowtype.org/try

ليس أجمل جزء من الكود على الإطلاق ولا يميز بشكل صحيح بين القيمة الفارغة وغير المحددة ، ولكن بخلاف ذلك يبدو أنه يعمل بشكل جيد.

AFAIK الشيء الوحيد المفقود من TS لفعل الشيء نفسه هو شيء من هذا القبيل $NonMaybeType .
لا يعني ذلك أنه سيلغي الحاجة إلى هذا المشغل ، بالطبع ، لقد اعتقدت أن هذا أمر رائع.

لم يصل هذا إلى المرحلة 2 في آخر اجتماع لـ TC39 بسبب مخاوف بشأن الاتساق النحوي فيما يتعلق بالوصول إلى الأقواس مقابل النقطة مقابل الوصول إلى المكالمة والسلوك الدلالي (إمكانية التنبؤ حول الآثار الجانبية للتعبيرات على يمين undefined / null -التقييم المعامل) بالإضافة إلى الأسئلة المفتوحة حول نوع التعبيرات المسموح بعدم تشغيلها (على سبيل المثال ، x.?b() عندما x.b هو number )

(التصويت 🎉 على هذا التعليق لرمي الفاكهة الفاسدة)

شكرا لإعلامنا. يالها من خيبة أمل. ربما يجب تضييق النطاق بحيث يكون أبسط ولكن لا يزال مفيدًا؟

ربما يجب تضييق النطاق بحيث يكون أبسط ولكن لا يزال مفيدًا؟

هذا هو التحدي الذي يواجهه TC39 ، والذي ، بينما هو مبتذل ، يجب أن أعترف بأنني سعيد لأن الناس يمرون بهذا الأمر. من الصعب حقًا عليهم تقديم بناء جملة معقد إلى حد ما ، وفي الواقع ، في هذه الحالة ، يتسبب ضعف الكتابة للغة في حدوث قدر كبير من حالات الحافة التي يجب معالجتها ، أو تحصل على رمز يعمل 💥 وهو ليس ليست جيدة لأي شخص. لا أعتقد أنه إذا قمت بتقديم عامل مثل هذا ، يمكنك في الواقع تضييق نطاقه. سيكون من الأسهل على المنفذين تغطية 90٪ من الحالات ، لكنني لا أعتقد أن ¯\_(ツ)_/¯ هو رمز صالح لـ 10٪ المتبقية.

يا رفاق ، بعد أكثر من 3 سنوات ، أود أن أقول إن الوقت قد حان لأقول "اللعنة عليك" للجنة ونفعل ذلك بطريقتنا الخاصة ، كل ما هو اصطلاحي لـ TypeScript. لا يمكن أن تعمل هذه الميزة بشكل صحيح بدون الكتابة الثابتة على أي حال.

قم بتنفيذ TypeScript ببنية غير متوافقة بشكل صريح مع اقتراح TC39. بمجرد حصول ES على مشغل آمن للملاحة ، سيكون لدى TypeScript خياران: أحدهما يحتوي على دلالات غزيرة متوافقة مع ES ، والآخر مرتبط بنظام الكتابة. هذا يعني أنه لا يمكنك استخدام مشغل TS الآمن مع أي "نوع" ، وهذا جيد.

notsnotso Typescript ليس من المفترض أن تكسر JS ، هذا ما هو Coffeescript.

ربما يكون الحل الجيد هو:

• تنفيذ بسيط جدا؟ عامل للمطورين غير الصبورين ، كميزة تجريبية (مثل الديكور) ، مع تحذير - سوف يكسر الكود الخاص بك في المستقبل
• انتظر 3 سنوات أخرى حتى تتم كتابة ستاندارت ، وتنفيذها كميزة غير تجريبية. اكتب تعليمي ، ما يمكن كسره. حتى مع الكتابة الثابتة ، من الممكن كتابة تحذيرات عندما يقوم الأشخاص بتجميع الكود باستخدام تطبيق مشغل جديد.
  "افعل ذلك بطريقتنا الخاصة ، أيًا كان ما هو اصطلاحي لـ TypeScript" ليست حالة ، لأنه في غضون 3 سنوات سيواجه الناس مشكلة ، وأن ts elvis لا يعمل بنفس الطريقة كما في js.

أنا لست مندهشا من أن هذا لم يحدث ، لأكون صادقا. في بلدي الأصلي
بعد ، أشرت إلى الغموض المتعلق بالفهرسة واستدعاءات الوظائف وما إلى ذلك.
بصراحة ، كلما فكرت أكثر في ?. ، شعرت أنها ليست كذلك
تنتمي إلى JavaScript ، حيث إنها تحتوي على undefined .

أفضل استخدامًا للأغراض العامة لحل هذه المشكلة
و اكثر. اعتقد أحدهم أنني كان شيئًا مثل try/catch
التعبير ( let x = try a.b.c else 0 ) بالاشتراك مع عامل
تم التحقق من "nully" (على سبيل المثال ، x ؟؟ 1) بدلاً من "false" (على سبيل المثال ، x || 1).
لذلك ، يمكنك دمجها على النحو التالي: try a.b.c ?? 0 else 0 . إنه كلام ، نعم ،
لكنها تقول في الأساس: حاول تقييم abc وإذا كانت النتيجة null أو
undefined ، قم بإرجاع 0. إذا كان a أو b هو undefined وتم طرح استثناء ،
قبض عليه وإرجاع 0.

قد يكون البديل هو جعل بند else اختياريًا ، مع التقصير في
undefined . ثم يمكنك كتابة التعبير على النحو التالي: let x= (try a.b.c) ?? 0 . هذا مدمج للغاية ، ويتجنب الغموض ويوفر المزيد
حل للأغراض العامة يمكن أن يحل مشاكل أخرى.

أنا لا أقول أننا يجب أن ندفع من أجل هذا بدلاً من ذلك ؛ كل ما أقوله هناك
هي بدائل لـ ?. ويجب أن نستكشف خياراتنا حقًا حتى نقوم بذلك
ابحث عن لغة تتلاءم جيدًا مع لغة جافا سكريبت.

يوم الخميس ، 5 أكتوبر 2017 الساعة 7:51 صباحًا ، ديمتري رادكوفسكي إخطارات @github.com
كتب:

notsnotso لا يُفترض أن يكسر Typescript JS ، هذا ما
Coffeescript هو ل.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/Microsoft/TypeScript/issues/16#issuecomment-334441781 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ABTgPilbZfuKc2egdBrYfdTHHeDl3F6Sks5spMLLgaJpZM4CNapf
.

تضمين التغريدة ومع ذلك ، فإن ميزة TS المحددة لن تؤدي إلى كسر جافا سكريبت.

jehugaleahsa يعجبني اقتراحك ، وهو موجود بلغات أخرى. أعتقد أنه سيعمل بشكل جيد مع TS.

سأقول إنني لا أفهم حقًا الحاجة القوية للانتظار حتى يقبل ECMAScript عامل التشغيل. أضافت TypeScript فئات ووحدات و lambdas ، كل ذلك قبل وقت طويل من العثور على طريقهم إلى ECMAScript. في الواقع ، كان أحد الأهداف المعلنة لـ TypeScript هو / هو تجريب ميزات JS التجريبية. إن تقديم TypeScript لتطبيقه الخاص سيساعد بلا شك في إثراء هذه المناقشات في اللجنة.

لقد كنتم يا رفاق على استعداد لإجراء تغييرات عاجلة من قبل عندما تسير اللجنة في نهاية المطاف في اتجاه مختلف ، لا أفهم حقًا سبب اختلاف هذه الميزة.

تم تقديم async / await أيضًا إلى TypeScript في مرحلة مبكرة.

ومع ذلك ، فإن ميزة TS المحددة لن تؤدي إلى كسر جافا سكريبت.

لن يكون هناك شيء مثل "ميزة خاصة بـ TS" ، يرجى التحقق من أهداف تصميم TypeScript لمزيد من المعلومات.

_{يصل TypeScript قبل أن ينتقل ES إلى مسار مشرق ، وقد يكون هناك بعض المسارات الموجودة ،يتم الاحتفاظ بها فقط من أجل التوافق.}

أضافت TypeScript فئات ووحدات و lambdas ، كل ذلك قبل وقت طويل من العثور على طريقهم إلى ECMAScript.

والوحدات على وجه الخصوص هي كارثة ضخمة لا تزال لا تسبب نهاية للارتباك. هذا مثال استخدمه فريق TypeScript مرارًا وتكرارًا كمثال على _الخطأ_ والقفز في البندقية مبكرًا جدًا. لدينا أيضًا حقول خاصة تلوح في الأفق الآن ، والتي مرة أخرى ، كنت ممتنًا لـ private على مدار السنوات الخمس الماضية ، لكنها لن تسبب نهاية للارتباك.

مرة أخرى ، كان المصممون متاحين تحت العلم ، ولكن الآن بعد أن وصل المصممون بالفعل إلى المرحلة 3 ، سيتطلب الأمر إعادة تنفيذ وكسر رمز لـ TypeScript. هذا هو السبب في أن هذه الأشياء _ لا يمكن _ أن تؤخذ على الأرجح.

تم تقديم async / await أيضًا إلى TypeScript في مرحلة مبكرة.

بمجرد وصول اقتراح ECMAScript إلى المرحلة 3.

لا أحد يسيء التصرف ولكن إذا كان لا يمكن أن تذهب هذه المحادثة إلى أي مكان إلا في دوائر (ماذا لو كان هناك علم؟ نعم نحن على علم بالأعلام) أو خارج الموضوع (ماذا لو توقف TS عن كونه JS؟ لا بعد خمس سنوات لن نتغير عقلنا على ذلك) ، لسنا بحاجة إلى امتلاكه. لقد قلنا منذ حوالي 3 سنوات أننا سننفذ هذا بالضبط عندما تغلق لجنة ES معانيها.

مرة أخرى ، إعادة شراء الاقتراح هو https://github.com/tc39/proposal-optional-chaining ويمكنك متابعة تقدمه هناك. سنعمل دون اتصال بالإنترنت لمحاولة تحسين فرص الاقتراح في اجتماع TC39 التالي لأننا نريد حقًا أن يمر هذا أيضًا.

تحديث: وصلنا إلى المرحلة الثانية بعد ظهر اليوم في TC39 !!!

التسلسل الاختياري هو المرحلة 3

فتح هذا لفترة وجيزة لأغراض احتفالية فقط

الصيحة!

لا بريد مزعج ...

يمكنك إرسال رمز تعبيري يعبر عن مشاعرك

لا بريد مزعج ...

يمكنك إرسال رمز تعبيري يعبر عن مشاعرك

بالإضافة إلى ذلك ، من الممتع مشاهدة ارتفاع عدد الرموز التعبيرية بهذا الشكل. لم أر مطلقًا تعليقًا على مشكلة يكتسب الكثير من الشعبية بهذه السرعة!

لقد سجلت مقطع فيديو صغيرًا للتحديثات في الوقت الفعلي https://youtu.be/JLBrgPjeGhc

هل يمكن لأحد أن يلغي إشتراكي من هذا الشيء؟

DanielRosenwasser في حال لم تكن تمزح ، أو لأي شخص آخر يريد إلغاء الاشتراك ولا يعرف كيف ، فأنت تبحث عن هذا الزر في الشريط الجانبي الأيمن:

ناهيك عن وجود رابط في البريد الإلكتروني:

_{لقد كانت مزحة ، أنا أعمل على الاقتراح.}

RyanCavanaugh بعد فتح هذه المشكلة:

متحمس حقا لرؤية هذه الأرض أخيرا! 🎈 🎉

لا يمكن أن تنتظر الإصلاح السريع المطابق VSCode 😆

سأذهب إلى RyanCavanaugh لأنه ربما تم إلغاء اشتراكه في هذا الموضوع وأريد أن أكون وقحًا! (و DanielRosenwasser لمقياس جيد)

@ kitsonk لا تكن مؤخرة. الناس أحرار في إلغاء الاشتراك وعدم التعرض للمضايقة.

kitsonk ، لماذا يتم إلغاء اشتراك RyanCavanaugh أو DanielRosenwasser في هذا الموضوع؟ فتح رايان هذه المشكلة ورد دانيال بثلاثة تعليقات فوقك.

حتى لو تم إلغاء اشتراكهم ، فلا داعي للتسبب في المزيد من إرهاق الإشعارات من خلال إرسال بريد عشوائي إليهم.

يبدو أن GitHub مكان رهيب للفكاهة الساخرة ، يا ...

شكراً جزيلاً لأبطالنا في TC39 لمعرفة التفاصيل السيئة لميزة اللغة الجديدة هذه!

أعتقد أن kitsonk كان يمزح فقط ، تمامًا كما كنت أفعل. بينما نتعامل بسخافة قليلاً حول الإثارة ، يعد هذا تذكيرًا لطيفًا لإبقاء الأمور مدنية وفقًا لمدونة قواعد السلوك.

تضمين التغريدة
هل يمكنني أن أجرب هذا؟ أو rbuckton لديه فرع آخر موجود له 🙋🏻‍♂️

حسنًا ، لقد حصلت عليه https://github.com/microsoft/TypeScript/commits/optionalChainingStage1 🤦🏻‍♂️

نعم ، هذا قديم إلى حد ما ، للأسف.

لقد أدركت للتو أن هذه المشكلة تم فتحها منذ 5 سنوات. : مندهش:

تضمين التغريدة

نعم ، هذا قديم إلى حد ما ، للأسف.

هل يمكنني تجربة هذا؟

آسف jhprattMatthiasKunnen لقد نسيت أننا لا نشارك جميعًا نفس السياق على GitHub. لقد كنت أتجول هنا لفترة طويلة وقضيت وقتًا مع Ryan و Daniel IRL وشاركت لفترة وجيزة في الحدث الأخير الذي أدى إلى سوء فهم مزاحتي الداخلية. اعتذارات.

تظهر هذه المشكلة برمتها علمًا أثريًا مثيرًا للاهتمام لمبادئ تصميم TypeScript. أثارها رايان في وقت نظر فيه TypeScript _might_ بالفعل في بناء الجملة الذي سبق اعتباره جادًا في ECMAScript. لقد كان ذلك الوقت تقريبًا على الرغم من أن TypeScript داخليًا كانت تتعلم بعض الدروس من توقع بناء جملة ES2015 التي كان لها تأثيرات خطيرة على اللغة. قرر الفريق عدم النظر في التضمين حتى يتم تقديم مقترح TC39 للمرحلة 3.

بينما يمكن لـRyanCavanaugh معالجتها ، وأنا أعلم أنه كان قريبًا مما حدث مع الاقتراح ، أظن أنه من غير المحتمل أن يكون ما كان الفريق سينفذه مرة أخرى في عام 2014 متوافقًا بنسبة 100٪ مع اقتراح المرحلة 3 الحالي . لذا في حين أنه احتفال بالتأكيد ، فكن شاكرين أيضًا لأنه ليس لدينا 5 سنوات من كود TypeScript مع مشغل تنقل آمن لن يكون متسقًا تمامًا مع السلوك في الاقتراح.

🙏

هل هذه اللحظة لإزالة التسمية في انتظار TC39 ؟ 🤔

هل هذه اللحظة لإزالة التسمية في انتظار TC39 ؟ 🤔

وأضف ship-it

واوووو

أخيرا. كان يسأل حرفيًا حول التسلسل الاختياري y'day ، متسائلاً متى ستكون المرحلة 3 ، و bam! شكرا لكل من عمل على دفعها من خلال!

كيفية كتم هذا الموضوع؟ :)

opnksyn إذا كنت لا تهتم بإثارة الرسائل غير المرغوب فيها ، فهناك ميزة يتم إعلامك بها عند إغلاق هذه المشكلة. سيؤدي هذا إلى منع جميع التعليقات من الظهور في إشعارات مثل تلك التي كتبتها للتو 😄

أي حل ينبعث منها محدد بالفعل؟
قد يكون شيء من هذا القبيل مثيرًا للاهتمام:

function __chain<T extends object, U>(value: T|null|undefined, callback: (value: T) => U): U|undefined {
    if (value !== null && value !== undefined) {
        return callback(value);
    }

    return undefined;
}

type Foo = { x?: { y?: { z?: () => number } } }

const foo: Foo|null = { }

// foo?.x?.y?.z?()
const value = __chain(foo, _a => __chain(_a.x, _b => __chain(_b.y, _c => __chain(_c.z, _d => _d()))));

أفضل ما يفعله Babel لأنه يتجنب إنشاء نطاقات وظائف غير ضرورية:

var _foo, _foo$x, _foo$x$y, _foo$x$y$z;

// foo?.x?.y?.z?.()
(_foo = foo) === null || _foo === void 0 ? void 0
    : (_foo$x = _foo.x) === null || _foo$x === void 0 ? void 0
    : (_foo$x$y = _foo$x.y) === null || _foo$x$y === void 0 ? void 0
    : (_foo$x$y$z = _foo$x$y.z) === null || _foo$x$y$z === void 0 ? void 0
    : _foo$x$y$z.call(_foo$x$y);

أفضل ما يفعله Babel لأنه يتجنب إنشاء نطاقات وظائف غير ضرورية:

var _foo, _foo$x, _foo$x$y, _foo$x$y$z;

// foo?.x?.y?.z?.()
(_foo = foo) === null || _foo === void 0 ? void 0
  : (_foo$x = _foo.x) === null || _foo$x === void 0 ? void 0
  : (_foo$x$y = _foo$x.y) === null || _foo$x$y === void 0 ? void 0
  : (_foo$x$y$z = _foo$x$y.z) === null || _foo$x$y$z === void 0 ? void 0
  : _foo$x$y$z.call(_foo$x$y);

أوافق ، @ ExE-Boss. أشعر أن تجنب إنشاء نطاقات وظائف غير ضرورية أمر مثالي (حتى لو كان يجعل الكود المترجم قبيحًا بعض الشيء)

يجب أن يفوز الأداء والالتزام بمواصفات ES بالتأكيد على قابلية القراءة عندما نتحدث عن التعليمات البرمجية المجمعة.

هل هناك أي سبب لمقارنة الشفرة التي جمعتها Babel بكل من null و void 0 بثلاثية يساوي بدلاً من == null بسيط؟

هل هناك أي سبب لمقارنة الشفرة التي جمعتها Babel بكل من null و void 0 بثلاثية يساوي بدلاً من == null بسيط؟

proteria لقد ألقيت نظرة سريعة على رمز التسلسل الاختياري لـ __Babel__ ؛ يبدو أنك إذا قمت بتمرير الخيار loose وقمت بتعيينه على قيمة صادقة ، فلن ينتج عن ذلك فحوصات المساواة الصارمة

هذا بسبب document.all (أو لكي تكون متحذلقًا ، الفتحة الداخلية [[IsHTMLDDA]] ) ، وهو أمر غريب يحصل على معاملة خاصة في اللغة من أجل التوافق مع الإصدارات السابقة.

document.all == null // true
document.all === null || document.all === undefined // false

في اقتراح التسلسل الاختياري

document.all?.foo === document.all.foo

لكن document.all == null ? void 0 : document.all.foo سيعيد void 0 بشكل غير صحيح. في الوضع غير المحكم ، يتم رفض تفاصيل المواصفات هذه بسبب البساطة / الأداء / حجم الكود الذي تم إنشاؤه حيث لا يتعين على معظم الأشخاص التعامل مع document.all أي حال.

بالتأكيد يمكن أن تكون حالة document.all خاصة؟ لا ينبغي أن يتطلب الكثير من التعليمات البرمجية الإضافية ، فقط بضعة أسطر للتحقق من الكائن والممتلكات.

باستثناء أنه يمكن document.all لمتغير ، وتتبع مكان استخدامه يتطلب نظام كتابة ، وهذا هو سبب إخراج Babel افتراضيًا:

(_prop = prop) === null || _prop === void 0 ? void 0 : _prop./* do stuff */;

انا اعلم ذلك. ليس لدى Babel نظام كتابة ، كما هو الحال مع TypeScript. ربما لم يكن الأمر بهذه البساطة التي جعلتها يبدو ، لكني أتخيل أن هناك بالفعل رمزًا لمواقف معينة قادر على تتبع الاستخدام.

في الواقع ، لا تحتاج إلى نظام من النوع لتتبع متغيرات document.all ، حيث أن السلوك الخاص هو في الواقع على HTMLAllCollection ، وليس document.all .

لذلك يجب أن تكون قادرًا على إجراء شيك instanceof HTMLAllCollection ، وستكون ذهبيًا.

نعم ولكن ... لماذا تفعل instanceof بينما يمكنك فقط القيام === null || === void 0 ؟ بالتأكيد هذا أكثر بساطة.

بالتأكيد - كنت أشير فقط إلى أنك لست بحاجة إلى نظام كتابة لتتبع document.all :)

أنا شخصياً أميل إلى القول فقط كسرها ومعرفة من يشتكي ، لكن الأمر في المواصفات ، لذلك من الأسهل الالتزام بذلك.

noppa يمكن إجراؤه في وقت الترجمة. إذا كان foo instanceof HTMLAllCollection هو true $ ، فقم بإصدار foo === null || foo === void 0 ، ومن ناحية أخرى يمكننا _safely_ إصدار foo == null .

@ G-Rath سواء أحببتم ذلك أم لا ، فإن الإهمال لا يعني أنه لا ينبغي أن يعمل. يجب أن يظل TypeScript متوافقًا مع JavaScript.

jhpratt لكن هذا يتعارض حاليًا مع TypeScript Design Non Goals .

أيضًا ، لا يزال يتعين عليك القيام بـ foo === null || foo === void 0 لأي شيء يمكن HTMLAllCollection له ، على سبيل المثال. any أو object ، لذلك لا أعتقد أن الأمر يستحق ذلك حقًا.

أفترض أنك تشير إلى غير الهدف (5)

قم بإضافة معلومات نوع وقت التشغيل في البرامج أو الاعتماد عليها ، أو إرسال رمز مختلف بناءً على نتائج نظام النوع. بدلاً من ذلك ، شجع أنماط البرمجة التي لا تتطلب بيانات وصفية لوقت التشغيل.

على الرغم من أنني أوافق على أن هذا سيصدر بالتأكيد رمزًا مختلفًا بناءً على النوع ، إلا أنه فقط لتقليل حجم الكود. على الرغم من أنه كما أشرت ، فإن الأمر ليس بهذه البساطة مثل التحقق من HTMLAllCollection .

لكي نكون منصفين ، رفض TS _ مصغرًا محتملاً يستخدم معلومات النوع ، وهذا (نوعًا ما) مرتبط - السبب الرئيسي لإرسال == null هو تقليل حجم الكود بناءً على معلومات النوع.

إذا لم يتم تنفيذ هذا ، فسيكون رائعًا إذا أضاف فريق lang خيارًا إلى tsconfig مشابهًا لخيار Babel "فضفاض".

بعد التحقق بسرعة ، يقوم الموجه تلقائيًا بتحويل foo === null || foo === undefined إلى foo == null ، وهو ليس آمنًا بسبب هذه الحالة.

إذا لم يتم تنفيذ ذلك ، فسيكون من الرائع أن يضيف فريق lang خيارًا إلى tsconfig مشابهًا لخيار Babel "فضفاض".

فيما يتعلق بذلك ، يستخدم الكثير منا TypeScript لأدوات الإنشاء ولتطبيقات الأجهزة المحمولة ، ولا داعي للقلق بشأن قيود المتصفح!

في الواقع ، نحن نستخدم كل من TS و Babel معًا ، لذلك ربما يكون أحد هذه الخيارات هو المرور عبر المشغل إلى Babel / وقت التشغيل الأساسي!

تضمين التغريدة

في الواقع ، نحن نستخدم كل من TS و Babel معًا ، لذلك ربما يكون أحد هذه الخيارات هو المرور عبر المشغل إلى Babel / وقت التشغيل الأساسي!

أنا لا أفهم هذا التعليق. لا تحتاج إلى أي خيارات إضافية لعبور المشغل إلى Babel ؛ إذا كان لديك TypeScript معدًا لـ Babel ، فلديك بالفعل noEmit: true الذي يمر بالفعل _ كل شيء_ إلى Babel.

يفتقد تطبيق TypeScript الخاص بـ Zarel Babel إلى العديد من الميزات التي كانت قاعدة الكود الخاصة بنا تعتمد عليها بالفعل ، بما في ذلك مساحات الأسماء والتعدادات الثابتة. نحن نستخدم TSC مع تمكين الانبعاث ، ونطبق Babel كتحويل ثانٍ. (نحن نعمل على التخلص من مساحات الأسماء ، لكن من غير الواضح ما إذا كنا سنتمكن من التخلص من جميع الميزات غير المتطابقة)

يجب أن يبدأ الأشخاص الذين يأتون إلى هذا الموضوع في الإعلان المبكر عن المرحلة 3 وقراءة التعليقات التي تبدأ من هناك (إلقاء اللوم على GitHub لإخفاء الكثير من محتوى المستخدم بدون طريقة مباشرة لتحميل كل شيء)

ميزة رائعة - "التسلسل الاختياري" / "التنقل الآمن". خاصة في TypeScript ذات الوضع الصارم. من الرائع أن نسمع أن هذا سيتم تنفيذه قريبًا. ❤️

لقد أوصلني هذا إلى هنا وآمل أن يتم دعمه. مجرد حالة استخدام:

متوقع في TypeScript 3.7.

document.querySelector('html')?.setAttribute('lang', 'en');

ضد

حاليًا في TypeScript 3.5.

const htmlElement = document.querySelector('html');
if (htmlElement) {
  htmlElement.setAttribute('lang', 'en');
}

هل سيعمل هذا بدون أي أخطاء؟ أم أن هذا لا يزال TypeError: Cannot read property 'setAttribute' of null. ؟ ? op. يجب إلغاء سلاسل أخرى بعد null / undefined.

class Test {
  it() {
    console.log('One');
    document.querySelector('html')?.setAttribute('lang', 'en');
    console.log('Two');
  }
}
new Test().it();

أتوقع ما يلي:
إذا كان عنصر html غير موجود (فارغ). يجب أن تقوم وحدة التحكم بتسجيل One و Two ، ولم يتم استدعاء طريقة setAttribute . (لا اخطاء).
هل فهمت ذلك بشكل صحيح؟

domske FYI ، هذه ليست ميزة TS فقط ؛ إنها ميزة JS.

وفقًا لاقتراح TC39 ، سيكون بناء الجملة:

document.querySelector('html')?.setAttribute?.('lang', 'en');

بدأت المناقشة تدور بشكل دائري مرة أخرى ، لذا عدنا إلى حالة القفل.

أتوسل حقًا إلى أي شخص يغريه ترك تعليق في سلسلة GitHub الطويلة 100 + تعليق للالتزام حقًا بقراءة جميع التعليقات السابقة أولاً. من المحتمل أن يكون سؤالك والإجابة عليه موجودان هناك!