Typescript: प्रस्तावित ES रेस्ट/स्प्रेड प्रॉपर्टीज़ का समर्थन करें

को निर्मित 21 फ़र॰ 2015 · 96टिप्पणियाँ · स्रोत: microsoft/TypeScript

es7 प्रस्ताव : https://github.com/sebmarkbage/ecmascript-rest-spread

गुण फैलाओ

टाइपिंग

मेरी राय में इस पद्धति का लक्ष्य किसी वस्तु की नकल करने और कुछ प्रॉप्स को बदलने में सक्षम होना है, इसलिए मुझे लगता है कि इस मामले में डुप्लिकेट संपत्ति घोषणा की जांच नहीं करना विशेष रूप से महत्वपूर्ण है:

var obj = { x: 1, y: 2};
var obj1 = {...obj, z: 3, y: 4}; // not an error

मेरे पास मेरे छोटे jsx-typescript कांटे में एक समान सुविधा ( JSXSpreadAttribute ) के लिए एक बहुत ही बेवकूफ प्रकार की जांच एल्गोरिदम है : जब मैं फैलता ऑब्जेक्ट का सामना करता हूं तो मैं गुण तालिका में _spread ऑब्जेक्ट_ के गुणों की प्रतिलिपि बनाता हूं , और अगर मैं एक समान नाम के साथ एक घोषणा का सामना करता हूं, तो उन संपत्ति को ओवरराइड करें।

उत्सर्जक

jstransform उपयोग Object.assign , कोलाहल एक शिम परिचय:

var _extends = Object.assign || function (target) { for (var i = 1; i < arguments.length; i++) { var source = arguments[i]; for (var key in source) { if (Object.prototype.hasOwnProperty.call(source, key)) { target[key] = source[key]; } } } return target; };

हम या तो assign फ़ंक्शन की उपस्थिति को ObjectConstructor इंटरफ़ेस पर लागू कर सकते हैं, या एक समान फ़ंक्शन प्रदान कर सकते हैं (एक अलग नाम के साथ)।

मुझे लगता है कि इष्टतम समाधान es6 लक्ष्य (या यदि Object.assign परिभाषित किया गया है) में किसी भी सहायक को उत्सर्जित नहीं करना होगा, और es5 , es3 लिए एक सहायक फ़ंक्शन उत्सर्जित करना होगा

var obj = { x: 1, y: 2};
var obj1 = {...obj, z: 3};

/// ES6 emit
var obj = {x: 1, y: 2};
var obj1= Object.assign({}, obj, { z: 3 });

//ES3 emit
var __assign = function (target) { 
    for (var i = 1; i < arguments.length; i++) { 
        var source = arguments[i]; 
        for (var key in source) { 
            if (Object.prototype.hasOwnProperty.call(source, key)) { 
                target[key] = source[key];
            } 
        } 
    } 
    return target; 
};

var obj = {x: 1, y: 2};
var obj1= __assign({}, obj, { z: 3 });

बाकी गुण

टाइपिंग

साधारण वस्तु के लिए नया प्रकार असाइनमेंट का एक उपप्रकार है जिसमें ऐसे गुण नहीं होते हैं जिन्हें बाकी गुणों से पहले कैप्चर किया गया हो:

var obj = {x:1, y: 1, z: 1};
var {z, ...obj1} = obj;
obj1// {x: number; y:number};

यदि विनाशकारी असाइनमेंट में एक सूचकांक घोषणा है, तो परिणाम में एक समान सूचकांक घोषणा भी है:

var obj: { [string: string]: string };
var {[excludedId], ...obj1} = obj;
obj1// { [string: string]: string };

नई/कॉल घोषणाएं स्पष्ट रूप से कैप्चर नहीं की जाती हैं:

var obj: { (): void; property: string};
var { ...obj1} = obj;
obj1// { property: string };

उत्सर्जक

एक सहायक समारोह के बिना _rest properties_ उत्सर्जित करना संभव नहीं है, यह एक बेबेल से है:

var obj = {x:1, y: 1, z: 1};
var {z, ...obj1} = obj;

var __objectWithoutProperties = function(obj, keys) {
    var target = {};
    for (var i in obj) {
        if (keys.indexOf(i) >= 0) continue;
        if (!Object.prototype.hasOwnProperty.call(obj, i)) continue;
        target[i] = obj[i];
    }
    return target;
};

var obj = {x:1, y: 1, z: 1};
var z = obj.z;
var obj1 = __objectWithoutProperties(obj, ["z"]);

_संपादित करें: कुछ छोटे टाइपिंग/उत्सर्जक उदाहरण जोड़े गए_

Committed ES Next Fixed Suggestion

स्रोत

fdecampredon

👍284 ❤40 🎉33

सबसे उपयोगी टिप्पणी

मुझे यकीन नहीं है कि हम अंततः इसे कैसे शिप करेंगे, लेकिन मैंने ऑब्जेक्ट लिटरल और डिस्ट्रक्टिंग में रेस्ट/स्प्रेड पर काम शुरू किया। अभी योजना हमारे __assign पॉलीफ़िल का उपयोग उत्सर्जन के लिए करने की है।

sandersn 10 मई 2016

🎉45 ❤16 👍16 😄8

सभी 96 टिप्पणियाँ

हमें शायद कुछ उदाहरणों की आवश्यकता होगी कि इसे डाउनलेवल में कैसे उत्सर्जित किया जा सकता है (यदि यह दायरे में है)।

RyanCavanaugh 23 फ़र॰ 2015

@RyanCavanaugh , मैंने कुछ छोटे उत्सर्जक उदाहरण और टाइपिंग विचार जोड़े।
मैं उस पर काम करना चाहूंगा क्योंकि वैसे भी यह कमोबेश एक jsx फीचर है और मुझे इसे अपने कांटे में जोड़ना होगा, लेकिन अगर इसे टाइपस्क्रिप्ट कोर में जोड़ा जाए तो यह बेहतर ^^ है।

fdecampredon 23 फ़र॰ 2015

👍1

मैंने हाल ही में इस लेख के माध्यम से ES7 में इस सुविधा की खोज की है। मुझे कहना होगा, यह काफी आसान है!

इसे टाइपस्क्रिप्ट में देखना अच्छा लगेगा!

mnpenner 10 जुल॰ 2015

👍18

इस पर कोई अपडेट? इसे 1.6 में देखना अच्छा लगेगा क्योंकि यह प्रतिक्रिया के साथ उपयोग करते समय बहुत आसान होगा: मुस्कान:

prabirshrestha 11 जुल॰ 2015

रिकॉर्ड के लिए @prabirshrestha , वर्तमान में हमारे पास master पर प्रॉपर्टी स्प्रेड ऑपरेटर है।

DanielRosenwasser 11 जुल॰ 2015

@DanielRosenwasser क्या आप विस्तृत कर सकते हैं? क्या इसका मतलब यह है कि यह मास्टर पर --jsx ध्वज के साथ काम करता है? क्या इसमें बाकी संपत्तियां शामिल संपत्तियां फैलती हैं ?

mnpenner 11 जुल॰ 2015

क्षमा करें @mnpenner और @prabirshrestha , हाँ, मेरा मतलब master । @RyanCavanaugh इस बारे में

DanielRosenwasser 11 जुल॰ 2015

JSX स्प्रेड _attributes_ का समर्थन करता है, जैसे <TagName {...spreadedExpr} /> । समान टोकन साझा करने और मोटे तौर पर समकक्ष शब्दार्थ होने के अलावा ES6 स्प्रेड ऑपरेटर से कोई लेना-देना नहीं है।

RyanCavanaugh 13 जुल॰ 2015

मुझे Redux और React दोनों में बहुत दिलचस्पी है, इससे राज्य में हेरफेर बहुत आसान हो जाता है। इसे लागू होते देखना अच्छा लगेगा।

RichiCoder1 7 अग॰ 2015

👍17

रेस्ट/स्प्रेड अब स्टेज 2 के लिए स्वीकृत है https://github.com/tc39/tc39-notes/blob/master/es7/2015-07/july-30.md

Lenne231 17 अग॰ 2015

हम इसे संबोधित करने से पहले चरण 3 तक पहुंचने के प्रस्ताव की प्रतीक्षा करना चाहते हैं।

RyanCavanaugh 6 अक्तू॰ 2015

👎5 👍1

यह प्रतिक्रिया और रेडक्स में बहुत उपयोगी है, कृपया इसे जल्द से जल्द लागू करें, कृपया :-)

WanderWang 6 नव॰ 2015

👍33

यहां एक सहायक मॉड्यूल है जिसका उपयोग मैं इसके आसपास काम करने के लिए कर रहा हूं। यह आदर्श नहीं है क्योंकि आपको सभी चाबियों को दो बार निर्दिष्ट करना है, एक बार बाईं ओर और एक बार दाईं ओर स्ट्रिंग्स के रूप में, लेकिन मैं इसे करने के बेहतर तरीके के बारे में नहीं सोच सकता। किसी भी प्रतिक्रिया का स्वागत है, मुझे यकीन है कि किनारे का व्यवहार है जो मैंने याद किया है!

https://gist.github.com/tomduncalf/fbae862b123445c117cb

tomduncalf 13 नव॰ 2015

क्या यह कुछ ऐसा है जिसके लिए आप एक पैच स्वीकार करेंगे? (एक बार चरण 3 पर पहुंचने के बाद विलय करने के लिए)। और यदि हां, तो क्या इसका कोई संकेत है कि इसका समर्थन करने के लिए परिवर्तन कहां से शुरू किया जाए?

यह आखिरी ES7+ सुविधा है जिसका मेरी टीम भारी उपयोग करती है जो हमें टाइपस्क्रिप्ट पर स्विच करने से रोक रही है; यदि संभव हो तो निश्चित रूप से जल्दी करना पसंद करेंगे।

nevir 18 नव॰ 2015

👍3

हम यहां एक पीआर पर विचार करेंगे। एक नोट हालांकि, इस सुविधा के लिए टाइप सिस्टम को वायर करना कोई आसान काम नहीं है। यदि आप इसे समझने में रुचि रखते हैं तो मैं इसे वृद्धिशील रखूंगा, और पार्सिंग से शुरू करूंगा, फिर बाहर निकलें और फिर जांच टाइप करें। यदि आपके कोई प्रश्न हैं तो @sandersn आपकी सहायता करने में सक्षम होना चाहिए।

mhegazy 19 नव॰ 2015

Redux के साथ इसका उपयोग करने में रुचि रखने वालों के लिए बस एक नोट। मैं सहमत हूं कि अंकन सुविधाजनक है। लेकिन मैं वास्तव में updeep पुस्तकालय का लाभ उठाकर इसके बिना ठीक हो रहा हूं। मैंने इसके लिए कुछ बुनियादी टाइपिंग बनाई और यह बहुत अच्छी तरह से काम करता है। मेरे पास एक साधारण पुस्तकालय भी है जो updeep आधारित स्टोर और क्रियाओं को लागू करता है। अगर किसी को इसमें दिलचस्पी है तो बस मुझसे संपर्क करें।

किसी भी स्थिति में, :+1: TS में स्प्रेड ऑपरेटरों के लिए। :मुस्कुराओ:

xogeny 4 दिस॰ 2015

👍4

@xogeny मुझे उस पुस्तकालय को देखने में बहुत दिलचस्पी होगी। धन्यवाद

cur3n4 13 दिस॰ 2015

@ cur3n4 मेरे पास एक भंडार है जहां मैं इन विचारों के साथ खेल रहा हूं। यह काफी हद तक बदलता है (क्योंकि यह सब अभी भी विकसित हो रहा है)। मैं एक विशेष मॉड्यूल का जिसने शुरुआत में updeep लाभ उठाया और वह कार्यक्षमता अभी भी पुस्तकालय में है । लेकिन मैंने इसका उपयोग करना बंद कर दिया है क्योंकि मुझे आवश्यक प्रकार की बाधाओं को बनाए रखना मुश्किल लगा। मुझे संदेह है कि टाइपस्क्रिप्ट में जावा के super सामान्य प्रकार की बाधाओं के साथ कुछ था , updeep (और कई अन्य पुस्तकालय, जैसे lodash या ramda ) हो सकता है बहुत अधिक प्रकार को सुरक्षित बनाया।

लेकिन मुझे गलत मत समझो, मुझे अभी भी लगता है कि एक स्प्रेड ऑपरेटर वास्तव में उपयोगी होगा। यह वास्तव में आपको उस भाषा में चीजों को सुरक्षित और संक्षिप्त रूप से व्यक्त करने और करने की अनुमति देगा जो मुझे नहीं लगता कि वर्तमान प्रकार प्रणाली के साथ कैसे किया जाए (_यानी,_ आपको बाहरी पुस्तकालयों पर सही प्रकार की बाधाओं का वर्णन करने की इजाजत देता है)। फिलहाल, मैं सुरक्षा के लिए संक्षिप्तता का त्याग करता हूं (जबकि updeep दृष्टिकोण ने संक्षिप्तता के लिए सुरक्षा का त्याग किया)।

xogeny 13 दिस॰ 2015

पिछले कुछ महीनों के लिए बैबेल का उपयोग करने के बाद, मेरी परियोजना को टीएस में परिवर्तित कर दिया और इन सभी को फिर से करना पड़ा। इसे लागू होते देखना अच्छा लगेगा!

amcdnl 26 जन॰ 2016

👍4

:+1:

SergeyKorochansky 27 जन॰ 2016

यह देखना पसंद करेंगे।

dlebedynskyi 28 जन॰ 2016

danielfigueiredo 28 जन॰ 2016

सुविधा होनी चाहिए, कृपया लागू करें

mezzario 28 जन॰ 2016

👍1

lukephills 3 फ़र॰ 2016

Object.असाइन + JSX समर्थन की तुलना में +1 बहुत अच्छा सिंटैक्स है

baio 6 फ़र॰ 2016

+1 यह प्रॉप्स को पास करने के लिए प्रतिक्रिया विकास के लिए होना चाहिए ( var { checked, ...other } = this.props; । प्रतिक्रिया दस्तावेज़ देखें

zivni 9 फ़र॰ 2016

👍1

यह प्रतिक्रिया विकास के लिए होना चाहिए

आइए ईमानदार रहें, यह एक सुविधा है, न कि होनी चाहिए। प्रस्ताव TC39 के साथ स्टेज 2 पर है। टाइपस्क्रिप्ट टीम ने यह स्पष्ट कर दिया है, वे उन चीजों को लागू करने पर विचार नहीं करना चाहते हैं जो टाइपस्क्रिप्ट में उत्पन्न नहीं हुई हैं जब तक कि वे स्टेज 3 नहीं हैं। "+1" का स्थान TC39 के साथ है।

kitsonk 9 फ़र॰ 2016

👎21 👍7

@kitsonk - जब आप प्रतिक्रिया/आदि जैसे ढांचे विशेष रूप से अपने दस्तावेज़ों में इस प्रकार की चीजों को

amcdnl 9 फ़र॰ 2016

👍46 👎1

खैर, मुझे लगता है कि हम एक व्यापक विषय के बारे में बात कर रहे हैं। कोई भी ब्राउज़र विक्रेता ऐसी किसी भी चीज़ को लागू नहीं करेगा जो चरण 3 में नहीं है (जब तक कि वे इसे व्यक्तिगत रूप से पसंद नहीं करते)। TC39 वेब के अपने हिस्से के लिए कुछ स्तर का संगठन देने की कोशिश कर रहा है। टाइपस्क्रिप्ट ने पहले बंदूक कूदकर (मॉड्यूल, और उस अराजकता को देखें जो तब से हुई है) को काट लिया है। मैं इस बात का सम्मान करता हूं कि वे क्या और कब लागू करने के इच्छुक हैं, इसके आसपास कम से कम कुछ मार्गदर्शन और संरचना रखने की कोशिश कर रहे हैं। क्या कोई अन्य सुझाव है कि किस मानक का उपयोग किया जाना चाहिए? मुझे नहीं लगता "क्योंकि एक्स फ्रेमवर्क ने अपने दस्तावेज़ों में इसका उल्लेख किया है" एक अच्छा होगा।

प्रतिक्रिया/आदि जैसे ढांचे विशेष रूप से इस प्रकार की चीजों को अपने दस्तावेज़ों में बुलाते हैं

जिसे वे केवल एक प्रस्ताव के रूप में चिह्नित करते हैं और फिर आपको निर्देश देते हैं कि बैबेल 6 को उपयोग करने के लिए कॉन्फ़िगर करने के लिए हुप्स के माध्यम से कैसे कूदें। मैं इसके बजाय वाक्य-विन्यास प्रौद्योगिकियों के आधार पर ढांचे को दोष दूंगा जो केवल मसौदा विनिर्देश पर हैं। व्यक्तिगत रूप से, हम डोजो में, Object.observe जल गए और मैं डोजो में स्टेज 3 तक पहुंचने से पहले प्रौद्योगिकियों पर निर्भर होने की कोशिश करने के लिए फिर से मितभाषी हूं।

विशेष पथ टाइपस्क्रिप्ट के लिए उत्सर्जन पर सिंटैक्स को बदलने का समर्थन करने से कहीं अधिक है। इसके साथ पालन करने के लिए सभी प्रकार के अनुमान हैं। मैंने समझने के लिए ड्राफ्ट स्पेक को देखा है, लेकिन प्रतीक कहां जाते हैं? गैर-गणना योग्य गुण कहाँ जाते हैं? मुझे लगता है कि दोनों ही मामलों में वे ईथर में गायब हो जाते हैं, लेकिन सभी प्रकार के विभाजन और विलय होंगे जिन्हें इसके लिए पृष्ठभूमि में जाने की आवश्यकता होगी, इसलिए मैं पूरी तरह से समझ सकता हूं कि टाइपस्क्रिप्ट टीम कह रही है "ठीक है, चलो बंद करो इस पर जब तक टीसी39 ने वास्तव में इस पर टायरों को लात नहीं मारी है"।

kitsonk 9 फ़र॰ 2016

👍17

कुल मिलाकर मुझे लगता है कि TS आज काफी अच्छी तरह से चित्रित है। एक समय था (लगभग 1.4 ~ 1.5 मुझे लगता है) जहां मैं कुछ ईएस2015 सुविधाओं की कमी से निराश था, लेकिन आज तक टीएस ने मानक के साथ बहुत अच्छी तरह से पकड़ लिया है।

बेशक, कभी-कभी फीचर ईर्ष्या wrt अन्य भाषाएं होती हैं। उदाहरण के लिए, बैबेल "प्रायोगिक" सामग्री सहित किसी भी जेएस प्रस्ताव को बहुत अधिक प्रदान करता है। व्यक्तिगत रूप से, मैं इस मुद्दे और फंक्शन बाइंड ऑपरेटर की भी प्रतीक्षा कर रहा हूं।

लेकिन साथ ही हमें यह स्वीकार करना होगा कि TS टीम संगतता को बाबेल की तुलना में बहुत अधिक गंभीरता से लेती है। वे रिलीज़ के बीच आपके कोड के शब्दार्थ को बदलना नहीं चाहते हैं, या बस एक सुविधा को हटाना चाहते हैं, जो कि बैबेल करता है। कुछ (उद्यम?) परियोजनाओं के लिए जो महत्वपूर्ण है।

मैं यह भी समझ सकता हूं कि एमएस सुविधाओं में बहुत सारे संसाधनों का निवेश नहीं करना चाहता है जो गिराए जा सकते हैं, Object.observe फियास्को दिमाग में आता है। दरअसल, उन्होंने कहा कि वे इस पर एक पीआर पर विचार करेंगे उदाहरण के लिए: पलक:।

अतीत में कुछ सुविधाओं को प्रायोगिक कंपाइलर स्विच (जैसे async) के पीछे जल्दी जोड़ा गया था, जिसका मतलब था कि आपको ऑप्ट इन करना होगा और स्वीकार करना होगा कि फीचर बदल सकता है या भविष्य के रिलीज में हटा दिया जा सकता है। हो सकता है कि सबसे लोकप्रिय अनुरोधों के लिए फिर से किया जा सकता है?

jods4 10 फ़र॰ 2016

यहाँ बस एक त्वरित नोट। हम मुख्य रूप से पिछड़े संगतता चिंताओं के कारण चरण 0-1 प्रस्तावित ईएस सुविधाओं को अपनाने में धीमे रहे हैं। हम TC39 बैठकों में चर्चा का बारीकी से पालन करते हैं, और बैठकों में या बैठकों से पहले प्रस्ताव तैयारियों में सीधे भाग लेते हैं; और जब हम एक फीचर डालते हैं तो हम जानना चाहेंगे कि उन उपयोगकर्ताओं के लिए इसका क्या अर्थ है जो उन पर निर्भरता लेते हैं।
यदि आप TC39 प्रक्रिया दस्तावेज़ीकरण को देखते हैं तो चरण 1 पर एक सुविधा "प्रमुख" पोस्ट स्वीकृति परिवर्तनों की अपेक्षा कर सकती है। कक्षाओं, मॉड्यूल, पुनरावृत्तियों और लगभग सभी गैर-तुच्छ ES6 सुविधाओं के मामले में यह मामला था।
मेरी उपयोगकर्ता टोपी लगाना, वाक्य रचना में परिवर्तन को तोड़ना प्रतिक्रिया देने के लिए यांत्रिक हो सकता है, जबकि शब्दार्थ में परिवर्तन को पकड़ना और ठीक करना बेहद कठिन हो सकता है; इन सुविधाओं में से किसी का उपयोग करने वाली टीमों के लिए यह एक बड़ी लागत हो सकती है, और/या टूल के नए संस्करणों को अपनाने के लिए अवरोधक हो सकती है। और जब संभव हो हम इसे कम से कम करना चाहेंगे। यही कारण है कि हमने चरण 3 तक पहुंचने पर डिफ़ॉल्ट रूप से सुविधाओं को सक्षम करने के लिए एक नीति अपनाई है, और उससे पहले एक प्रयोगात्मक ध्वज के तहत (जैसे डेकोरेटर)।
ऐसा कहने के बाद, ऑब्जेक्ट प्रॉपर्टी स्प्रेड और बाकी हमारे रोडमैप पर हैं , और हम भविष्य में रिलीज में उनसे निपटने की योजना बनाते हैं।

mhegazy 10 फ़र॰ 2016

👍2

हो सकता है कि कुछ तृतीय पक्ष एक्सटेंशन इंजेक्ट करने के लिए कंपाइलर क्षमता में जोड़ने पर विचार किया जाए, जैसा कि बेबेल में किया गया है?

baio 10 फ़र॰ 2016

एक और विचार: प्रीप्रोसेसिंग टाइपस्क्रिप्ट स्रोतों (बेबेल के साथ) के समर्थन के बारे में क्या?

यदि हम Object.assign कॉल में फैली हुई वस्तु का विस्तार करने के लिए बेबेल (या जो भी पुस्तकालय) प्राप्त कर सकते हैं, तो यह काफी अच्छी तरह से काम कर सकता है? उम्मीद है कि यह बैबेल में लागू अन्य प्रयोगात्मक सुविधाओं के लिए भी सामान्यीकरण योग्य होगा।

nevir 10 फ़र॰ 2016

@kitsonk - व्यापक विषय बिल्कुल, खतरे की इच्छा

. टाइपस्क्रिप्ट ने पहले बंदूक कूदकर (मॉड्यूल, और उस अराजकता को देखें जो तब से हुई है) को काट लिया है।

वे चले गए और समुदाय से कुछ भी उपयोग नहीं कर रहे .NET को प्रतिबिंबित करते हुए अपना स्वयं का कार्यान्वयन किया, यह उनकी अपनी गलती है।

कुछ मार्गदर्शन और संरचना रखें कि वे क्या लागू करने के इच्छुक हैं और कब

वे सज्जाकार (चरण 1), वर्ग गुण (चरण 1), आदि लागू करते हैं।

मुझे नहीं लगता "क्योंकि एक्स फ्रेमवर्क ने अपने दस्तावेज़ों में इसका उल्लेख किया है" एक अच्छा होगा।

तुम्हारी मज़ाक की रात? प्रतिक्रिया सबसे लोकप्रिय ढांचा है और अभी कुछ समय के लिए इस तरह रहने का अनुमान है। समर्थन नहीं कर रहा है जो वास्तव में गोद लेने को चोट पहुंचाएगा।

मुझे लगता है कि टाइपस्क्रिप्ट में बैबेल के साथ बहुत अधिक पकड़ है और इसमें बहुत सारी चुनौतियाँ हैं जैसे: मौजूदा ऐप के साथ इसका उपयोग करना शुरू करना वास्तव में मुश्किल है, ए 2 के लिए बेबेल से टाइपस्क्रिप्ट में माइग्रेट करना एक दुःस्वप्न है!, डिकूप्ड प्लगइन्स की कमी काम करना w/नोड को बेहद कठिन बना देता है।

amcdnl 10 फ़र॰ 2016

👍7

तुम्हारी मज़ाक की रात? प्रतिक्रिया सबसे लोकप्रिय ढांचा है और अभी कुछ समय के लिए इस तरह रहने का अनुमान है। समर्थन नहीं कर रहा है जो वास्तव में गोद लेने को चोट पहुंचाएगा।

रिएक्ट के लिए मेरे मन में बहुत सम्मान है, लेकिन मैं मजाक नहीं कर रहा हूं। यह शहर का एकमात्र खेल नहीं है और यह निश्चित रूप से एक बड़े प्रचार वक्र पर है। 6 महीने पहले यह रिएक्ट + फ्लक्स था, अब रिएक्ट + रेडक्स दिन का स्वाद है। एक साल पहले, कोणीय और पॉलिमर। दो साल पहले यह बैकबोन और एम्बर था। छह साल पहले यह Dojo, MooTools, jQuery, gwt, ExtJS, आदि था ...

kitsonk 10 फ़र॰ 2016

👍12 👎4

यहां ढांचा युद्ध शुरू न करें: विस्मयादिबोधक:
{..., } सिंटैक्स बहुत सुंदर है, चाहे कोई भी ढांचा क्यों न हो

baio 11 फ़र॰ 2016

👍31

वे चले गए और समुदाय से कुछ भी उपयोग नहीं कर रहे .NET को प्रतिबिंबित करते हुए अपना स्वयं का कार्यान्वयन किया, यह उनकी अपनी गलती है।

@amcdnl आप वास्तव में क्या

aluanhaddad 14 फ़र॰ 2016

+1 इसके लिए टाइपस्क्रिप्ट नोड में शामिल किया जाना है, जेएस इसे प्रायोगिक रूप से समर्थन कर रहा है

afaayerhan 15 फ़र॰ 2016

लेट टाइपस्क्रिप्ट = {...टाइपस्क्रिप्ट, ऑब्जेक्ट_स्प्रेड}; // हाँ कृपया।

PhilipDavis 25 फ़र॰ 2016

😄26 👍9

इस पर कोई हलचल नहीं है, मुझे वास्तव में उम्मीद है कि यह जल्द ही चरण 3 तक पहुंच जाएगा। यदि संभव हो तो VSCode में हाइलाइटिंग सिंटैक्स त्रुटि को मारने जा रहे हैं

ajwhite 2 मार्च 2016

👍1

मुझे आश्चर्य है कि क्या साल्सा खेल में कुछ भी बदलता है?

मैं समझता हूं कि TS अस्थिर सुविधाओं को जल्दी लागू नहीं करना चाहता: सीमित संसाधन, संभावित ब्रेकिंग परिवर्तनों से हमें उपयोगकर्ताओं की रक्षा करना, आदि।

लेकिन अब जब साल्सा वीएस कोड डिफ़ॉल्ट जेएस इंजन है, तो नए जेएस सिंटैक्स (कम से कम सिर्फ सिंटैक्स, पूर्ण टीएस टाइपिंग नहीं) के लिए दबाव बढ़ने वाला है। खासतौर पर बाबेल की लोकप्रियता को देखते हुए।

क्या साल्सा टीएस की तुलना में व्यापक सिंटैक्स को तेजी से स्वीकार करने में सक्षम होने जा रहा है?

jods4 2 मार्च 2016

👍6

stepancar 10 मार्च 2016

👎21 👍7 😕4 😄1

क्या यह 2.0 के बजाय 2.1 में होगा? :रोना:
https://github.com/Microsoft/TypeScript/wiki/Roadmap#21

asvetliakov 11 मार्च 2016

😕13 👍2

यह देखते हुए कि 2.0 पहले से ही कितना बड़ा हो रहा है, मैं बहुत हैरान नहीं हूं।

RichiCoder1 11 मार्च 2016

हम रिलीज को 6-8 सप्ताह अलग रखने की कोशिश करते हैं; ताकि वह सीमित हो जो अंदर जा सकता है। हम इस समय कुछ एमिटर रिफैक्टरिंग कर रहे हैं, और पूरा होने के बाद इस सुविधा को जोड़ने में सक्षम होना चाहिए।

mhegazy 11 मार्च 2016

👍25

तो क्या यह तय है?

... प्रसार विशेषताओं के लिए स्टैंडअलोन सहायक कार्य
https://github.com/Microsoft/TypeScript/releases/tag/v1.8.10

चूंकि मुझे अभी भी "संपत्ति पुनर्गठन पैटर्न अपेक्षित" मिल रहा है

nerijusgood 28 अप्रैल 2016

बिल्कुल नहीं। यह फिक्स विशेष रूप से JSX स्प्रेड विशेषताओं के लिए है:

const props = { foo: "bar" };
return <SomeComponent {...props} />;

जो पहले से ही काम करता था, इससे पहले कि रिएक्ट v15 ने एक अनिर्दिष्ट आंतरिक फ़ंक्शन को हटा दिया, जिस पर टाइपस्क्रिप्ट का JSX कंपाइलर निर्भर था। उफ़

ऑब्जेक्ट स्प्रेड एक अलग प्रस्ताव है, एक समान रूप से समान वाक्यविन्यास के साथ (यह फेसबुक इंजीनियरों द्वारा भी प्रस्तावित किया गया हो सकता है और जेएसएक्स समकक्ष से प्रेरित हो सकता है, हालांकि मुझे निश्चित रूप से पता नहीं है)।

dallonf 28 अप्रैल 2016

तो चूंकि {...props} अभी तक काम नहीं करता है, आप टाइपस्क्रिप्ट का उपयोग करके कुछ इसी तरह कैसे प्राप्त करेंगे?

dgsunesen 29 अप्रैल 2016

तो चूंकि {...props} अभी तक काम नहीं करता है, आप टाइपस्क्रिप्ट का उपयोग करके कुछ इसी तरह कैसे प्राप्त करेंगे?

xtend उपयोग करें: https://www.npmjs.com/package/xtend इसमें बहुत अच्छी टाइपिंग है: https://github.com/typed-typings/npm-xtend ( @blakeembrey द्वारा:rose :) धन्यवाद चौराहे के प्रकार के लिए

basarat 29 अप्रैल 2016

👍2

या किसी पुस्तकालय का प्रयोग बिल्कुल भी न करें!

const newProps = Object.assign({} /*new object*/, props /* add all attributes of props */, {
   // add additional props
  bar: "baz"
});

यह थोड़ा वर्बोज़ है, लेकिन यह _is_ ES2015 का मूल निवासी है, इसलिए यदि आपके पास इसके लिए पहले से ही एक पॉलीफ़िल है, तो आप ठोस हैं।

dallonf 29 अप्रैल 2016

👍9

यह ऑपरेटर एक मुख्य कारण है कि हमने टाइपस्क्रिप्ट के बजाय किसी प्रोजेक्ट में बेबेल का उपयोग करने का निर्णय लिया है।

वस्तुओं को अपरिवर्तनीय रूप से संभालने के लिए खेल को पूरी तरह से बदल देता है।

SoonDead 4 मई 2016

👍42

विकल्प के रूप में क्या ऐसी कोई योजना है जो आपको कस्टम परिवर्तन को TSC में प्लग इन करने देती है जैसे आप बेबेल में कर सकते हैं? हो सकता है कि एक ही एपीआई के आधार पर भी, यह बहुत बढ़िया होगा और इस तरह की समस्याओं को हल करेगा।

Niondir 5 मई 2016

विकल्प के रूप में ऐसी कोई योजना है जो आपको कस्टम परिवर्तन को TSC में प्लग इन करने देती है जैसे आप बेबेल में कर सकते हैं

@Niondir हाँ। बस [Transforms] टैग खोजें। टाइपस्क्रिप्ट कंपाइलर में उचित एसिंक/प्रतीक्षा/जेनरेटर ट्रांसपिलेशन प्राप्त करने के लिए इनकी आवश्यकता होती है: गुलाब:

basarat 5 मई 2016

थोड़ी खोज के बाद, आप इसका संदर्भ दे रहे हैं? https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API

बहुत अच्छा लगता है। मुझे उस एपीआई के लिए ऑब्जेक्ट स्प्रेड से संबंधित कुछ भी नहीं मिला। शायद यह कंपाइलर एपीआई के आधार पर इस मुद्दे को हल करने के लिए एक अच्छी छोटी परियोजना होगी :)

Niondir 5 मई 2016

@Niondir मेरे मूल संदेश में बेहतर सहायता प्रदान नहीं करने के लिए खेद है। मैं https://github.com/Microsoft/TypeScript/issues/5595 < के बारे में बात कर रहा हूं जो ESNext सिंटैक्स के लिए प्लग करने योग्य emit अनुमति देगा। टाइपस्क्रिप्ट बैबल की तुलना में थोड़ा अधिक शामिल है क्योंकि इसमें आपके कोड की _semantic_ टाइप सिस्टम समझ होनी चाहिए, इसलिए ऑब्जेक्ट स्प्रेड कार्य को टाइपस्क्रिप्ट टीम से आने की आवश्यकता होगी।

प्लगइन आधारित एमिटर होने से यह आसान हो जाएगा। हां, आप कंपाइलर एपीआई (या संभावित रूप से fork कंपाइलर का उपयोग शुरुआत में तब तक करेंगे जब तक कि एक प्लगइन सिस्टम सार्वजनिक नहीं हो जाता + सिमेंटिक/स्कैनर लॉजिक के लिए)

basarat 5 मई 2016

👍2

यह किसी अन्य मुद्दे के लिए एक प्रश्न हो सकता है, लेकिन क्या "अनुमति-प्रयोगात्मक" विकल्प जोड़ना संभव नहीं होगा और क्या टाइपस्क्रिप्ट भविष्य की चीजों की अनुमति देता है? उदाहरण के लिए, स्प्रेड ऑपरेटर और आउटपुट को यथावत अनुमति दें। मैं इसे बाद में बेबेल के साथ संभाल सकता हूं।

जिन परियोजनाओं पर मैं काम कर रहा हूं, उनके लिए यह एक आवश्यक विशेषता है और मैं इस तरह की आवश्यक सामग्री के बिना माइग्रेट नहीं कर सकता। अगर मैं कर सकता तो यह बहुत अच्छा होगा।

brunolm 10 मई 2016

👍6

sandersn 10 मई 2016

🎉45 ❤16 👍16 😄8

यह सबसे अच्छी खबर है जो मैंने पिछले 3 महीनों में सुनी है!

asvetliakov 10 मई 2016

दुर्भाग्य से, यह पता चला है कि इसे जेनरिक के साथ काम करना एक _lot_ काम है। आपको इस तरह कोड का ठीक से समर्थन करना होगा:

function addId<T>(t: T): {...T, id: number} {
    return { ...t, id: 1 };
}

जैसा कि आप देख सकते हैं, addId एक नए प्रकार का प्रकार देता है, एक ऑब्जेक्ट प्रकार जिसमें एक स्प्रेड ऑपरेटर शामिल होता है।

कुछ चर्चा के बाद, हमने 2.1 तक देरी करने का फैसला किया और इसे फिर से देखें। हमें अभी 2.0 सुविधाओं को पूरा करने पर ध्यान केंद्रित करने की आवश्यकता है।

sandersn 16 मई 2016

👎15 👍11 ❤4

मेरी अज्ञानता को क्षमा करें ... लेकिन ऐसा लगता है कि addId उस स्थिति में T & { id: number } वापस करने में सक्षम हो? या क्या संघ के कुछ प्रकार हैं जो इसे इष्टतम समाधान होने से रोकते हैं?

dallonf 17 मई 2016

👍2

मुझे लगता है कि उसका मतलब है कि वास्तव में T जाँच की जानी चाहिए, क्योंकि आप T . को कुछ भी पास कर सकते हैं

addId<boolean>(true);
addId<number>(5);

बेबेल चुपचाप ऐसे बयानों की उपेक्षा करता है let a = { ...true } लेकिन मुझे लगता है कि वे मान्य नहीं होने चाहिए

asvetliakov 17 मई 2016

यह T & { id: number } क्योंकि यदि T में id संपत्ति है, तो यह ओवरराइड हो जाएगा।

दूसरी ओर, प्रतिच्छेदन, परिणामी प्रकार का id T के id प्रकार और number का प्रतिच्छेदन होगा।

तो @sandersn क्या कह रहा है कि आपको एक अलग प्रकार के ऑपरेटर की आवश्यकता है।

DanielRosenwasser 17 मई 2016

👍5

जबकि हम निश्चित रूप से यहां एक बेहतर टाइपिंग समाधान से लाभान्वित होंगे, Object.assign पहले से मौजूद है और आउटपुट प्रकार के रूप में चौराहों का उपयोग करते हैं। हम एक स्टॉप गैप उपाय के रूप में, बाकी ऑपरेटर ठीक वही क्यों नहीं कर सकते जो Object.assign करता है?

यह अनुपलब्ध सुविधा के बारे में बहुत सारी चिंताओं को कम करेगा और यह अवांछित व्यवहार नहीं लाएगा क्योंकि लोग पहले से ही इसके बजाय Object.assign उपयोग करते हैं।

JabX 20 मई 2016

👍53

वास्तव में बेहद हैरान था कि यह समर्थित नहीं था।

BLamy 24 मई 2016

👍35 👎1

जैसे ही हम इसे प्राप्त करते हैं, मेरियर। प्रतिक्रिया के साथ बढ़िया काम करेगा!

nschurmann 27 मई 2016

👍26

मुझे खुशी होगी भले ही इसे टाइप न किया गया हो

michaelmesser 21 जून 2016

👍21 👎2

@ 2426021684 यह उचित लग सकता है लेकिन इसके निहितार्थों पर विचार करें। यदि इसे टाइप नहीं किया गया है, यानी टाइप किया गया है तो any , सिंटैक्स का कोई भी उपयोग any भाव की पत्तियों तक फैल जाएगा।

aluanhaddad 22 जून 2016

👎6 😕1

@aluanhaddad यह Object.assign जैसा ही होगा जो कि हर किसी को उपयोग करने का समाधान है क्योंकि उनके पास कोई विकल्प नहीं है (ऊपर JabX पोस्ट देखें)

brunolm 22 जून 2016

👍10

कृपया निकट भविष्य में @JabX के सुझाव को लागू करने पर विचार करें। यह प्रस्ताव नाम के अलावा चरण 3 है, यह _निश्चित रूप से मानक का एक हिस्सा बनने जा रहा है, और इसमें बहुत स्पष्ट और सरल शब्दार्थ है। प्रॉपर्टी स्प्रेड के लिए वाक्यात्मक समर्थन + Object.assign की सरल टाइपिंग एक बहुत ही उपयोगी स्टॉपगैप होगा जब हम "सही" कार्यान्वयन की प्रतीक्षा करते हैं। परफेक्ट को अच्छाई का दुश्मन न बनने दें।

pelotom 23 जून 2016

👍42

रिएक्ट 15.2 के साथ बाकी गुण अत्यंत महत्वपूर्ण हैं जैसा कि यहां देखा जा सकता है https://facebook.github.io/react/warnings/unknown-prop.html

const divProps = Object.assign({}, props)
delete divProps.layout

बहुत बदसूरत है, खासकर अगर एक घटक पर सहारा की मात्रा अधिक है

Pajn 14 जुल॰ 2016

👍13

उन लोगों के लिए जो यहां अब और इंतजार नहीं कर सकते, एक समाधान है:

function steal(result: any, data: any): any {
    for (var key in data) {
        if (value.hasOwnProperty(key)) {
            result[key] = data[key];
        }
    }
    return result;
}

export class SameAs<a> {
    constructor(public result: a) { }
    public and<b>(value: b): SameAs<a & b> {
        return new SameAs<a & b>(steal(this.result, value));
    }
}
export function sameAs<a>(value: a): SameAs<a> {
    return new SameAs(steal({}, value));
}

// example of use:

const mixture = sameAs(one).and(anotherOne).and(yetAnotherOne).result; // <-- ta-da!

zpdDG4gta8XKpMCd 14 जुल॰ 2016

👍11 🎉1

इस पोस्ट पर ध्यान न दें, बेहतर क्रियान्वयन के लिए नीचे देखें

यहाँ मैं एक खराब (टाइपस्क्रिप्ट) कोडर के विनाशकारी संचालन के लिए आया हूँ:

declare interface ObjectConstructor {
  destruct<T extends Object>(data: T, props: any): T;
  destruct<T extends Object>(data: T, ...propNames: string[]): T;
}

function destruct<T extends Object>(data: T, ...removals: string[]) {
  const rest = <T>{};

  const keys = removals.length === 1 && typeof removals[0] === 'object' ?
    Object.getOwnPropertyNames(removals[0]) :
    <string[]>removals;

  Object
    .getOwnPropertyNames(data)
    .filter(x => keys.indexOf(x) < 0)
    .forEach(x => {
      (<any>rest)[x] = (<any>data)[x];
    });

  return rest;
}

Object.destruct = destruct;

// Usage example:

const srcObj = { A: 'a', B: 'b', C: 'c' };
// destruct using an object template
const onlyC = Object.destruct(srcObj, { A: null, B: null });
// destruct using property names
const onlyA = Object.destruct(srcObj, 'B', 'C');

ऑब्जेक्ट लेआउट का उपयोग करने का स्पष्ट लाभ यह है कि आप लेआउट टाइप कर सकते हैं और यदि आप कुछ भी रिफैक्टर करते हैं तो कम से कम टाइप संघर्ष प्राप्त करें।

अपडेट करें (इसे भी अनदेखा करें, और भी बेहतर के लिए नीचे देखें)

मैंने इसे फिर से काम किया है (वास्तविक दुनिया के माहौल में इसके साथ खिलवाड़ करने के बाद) और कार्यों के साथ काम करने में कुछ आसान आया।

function deconstruct<TResult, TData>(
  result: TResult,
  data: TData,
  onHit: (result: TResult, data: TData, x: string) => void,
  onMiss: (result: TResult, data: TData, x: string) => void,
  propNames: string[]
  ) {

  Object
    .getOwnPropertyNames(data)
    .forEach(x => {
      if (propNames.indexOf(x) < 0) {
        if (onMiss != null) {
          onMiss(result, data, x);
        }
      }
      else {
        if (onHit != null) {
          onHit(result, data, x);
        }
      }
    });

  return result;
}

// shallow clone data and create a destructuring array of objects
// i.e., const [ myProps, rest] = destruct(obj, 'propA', 'propB');
function destruct<T>(data: T, ...propNames: string[]) {
  return deconstruct(
    [ <T>{}, <T>{} ],
    data,
    (r, d, x) => (<any>r[0])[x] = (<any>d)[x],
    (r, d, x) => (<any>r[1])[x] = (<any>d)[x],
    propNames
  );
}

// shallow clone data and create a destructuring array of properties
// i.e., const [ propA, propB, rest] = destructProps(obj, 'propA', 'propB');
function destructProps(data: any, ...propNames: string[]) {
  return deconstruct(
    [ <any>{} ],
    data,
    (r, d, x) => r.splice(r.length - 1, 0, d[x]),
    (r, d, x) => r[r.length - 1][x] = d[x],
    propNames
  );
}

// shallow clone data and remove provided props
// i.e., const excluded = omit(obj, 'excludeA', 'excludeB');
function omit<T>(data: T, ...propNames: string[]) {
  return deconstruct(
    <T>{},
    data,
    null,
    (r, d, x) => (<any>r)[x] = (<any>d)[x],
    propNames
  );
}

इन कार्यों पर टाइप करने से काम करना बहुत आसान हो जाता है। मैं विशेष रूप से इनके साथ रिएक्ट में काम कर रहा हूं, इसलिए मेरे ज्ञात प्रॉप्स पर मजबूत टाइपिंग करना बहुत आसान है। इन कार्यों का उपयोग करके कोड का एक अतिरिक्त टुकड़ा है जो विशेष रूप से प्रतिक्रिया के लिए आसान है:

const [ props, restProps ] = destruct(omit(this.props, 'key', 'ref'), 'id', 'text');

इस मामले में, props को this.props तरह ही टाइप किया जाता है, लेकिन इसमें लाइन के नीचे स्थानांतरित करने के लिए कोई भी प्रॉप्स नहीं होता है (जो अब restProps में रहते हैं)

patsissons 4 अग॰ 2016

👎6

आईएमओ, इस समस्या के लिए गैर-टाइपसेफ वर्कअराउंड पोस्ट करने से बहुत कुछ हासिल नहीं हुआ है।

pelotom 4 अग॰ 2016

👍5

सहमत हूं, मैं अभी एक अधिक प्रकार के सुरक्षित संस्करण पर काम कर रहा हूं।

patsissons 4 अग॰ 2016

इस पर एक और वार:

मुख्य वस्तु विस्तार:

declare interface ObjectConstructor {
    rest<TData, TProps>(data: TData, propsCreator: (x: TData) => TProps, ...omits: string[]): { rest: TData, props: TProps };
}

function rest<TData, TProps>(data: TData, propsCreator: (x: TData) => TProps, ...omits: string[]) {
  const rest = <TData>{};
  const props = <TProps>propsCreator.apply(this, [ data ]);

  Object
    .getOwnPropertyNames(data)
    .filter(x => props.hasOwnProperty(x) === false && omits.indexOf(x) < 0)
    .forEach(x => {
      (<any>rest)[x] = (<any>data)[x];
    });

  return {
    rest,
    props,
  };
}

Object.rest = rest;

एक प्रतिक्रिया विशिष्ट विस्तार:

declare module React {
  interface Component<P, S> {
    restProps<T>(propsCreator: (x: P) => T, ...omits: string[]): { rest: P, props: T };
  }
}

function restProps<P, S, T>(propsCreator: (x: P) => T, ...omits: string[]) {
  return Object.rest((<React.Component<P, S>>this).props, propsCreator, ...omits.concat('key', 'ref'));
}

React.Component.prototype.restProps = restProps;

कुछ नमूना उपयोग:

const src = { A: 'a', B: 'b', C: 'c' };
const { rest, props } = Object.rest(src, x => {
    const props = { A, C } = x;
  return { A, C };
});

और प्रतिक्रिया विस्तार का उपयोग करने का एक नमूना:

const { rest, props } = this.restProps(x => {
  const { header, footer } = x;
  return { header, footer };
});

सभी टाइपिंग को संरक्षित किया जाना चाहिए। एकमात्र हिस्सा जो मुझे परेशान करता है वह है प्रॉप्स क्रिएटर क्योंकि इसके लिए दोहराव की आवश्यकता होती है। मुझे लगता है कि मैं इसे हैक कर सकता हूं और मान सकता हूं कि नष्ट की गई वस्तु _a पर रहती है लेकिन ऐसा लगता है कि _dangerous_...
_नोट _: _a एक व्यवहार्य हैक भी नहीं है, क्योंकि यह बराबर होगा x ।

यहाँ खेलने के लिए एक Fiddle है।

patsissons 4 अग॰ 2016

मैं सोच रहा हूं कि एक सरणी लौटने से अधिक समझ में आ सकता है, क्योंकि आप आवश्यकतानुसार आउटपुट का नाम बदल सकते हैं।

स्क्रैच कि, यह प्रॉप्स के लिए उचित टाइपिंग को रोकेगा।

patsissons 5 अग॰ 2016

चूंकि यहां ज्यादातर लोग प्रतिक्रिया के साथ इसका उपयोग करना चाहते हैं, इसलिए इसे केवल *.tsx फ़ाइलों के लिए तब तक लागू क्यों न करें जब तक कि यह चरण 3 तक न पहुंच जाए?

Redux reducers को *.tsx फ़ाइलों के रूप में भी लिखा जा सकता है, बसओब्जो टाइपकास्टिंग इंस्टेंस को टाइप के रूप में ओबीजे में परिवर्तित किया जाना चाहिए

ddaghan 22 सित॰ 2016

यह न केवल प्रतिक्रिया के लिए, बल्कि उदाहरण के लिए रेडक्स रेड्यूसर में बहुत उपयोगी है।

olegman 22 सित॰ 2016

मुझे लगता है कि इस पर टैग और लापता मील का पत्थर थोड़ा पुराना है। क्योंकि यह प्रतिबद्ध है और टाइपस्क्रिप्ट 2.1 के लिए (#10727) पर काम किया जा रहा है। इसलिए अब इसके मूल्य पर बहस करने की आवश्यकता नहीं है।

पिंग @mhegazy

kitsonk 22 सित॰ 2016

👍2

टैग अपडेट किया। मुझे यह स्पष्ट करना चाहिए कि जिस कारण से इसे अभी तक लागू नहीं किया गया है, वह मूल्य नहीं है, बल्कि सिस्टम कार्यान्वयन के प्रकार की जटिलता है। यह परिवर्तन स्वयं अपेक्षाकृत छोटा है, यानी {...x} में Object.assign({}, x) । मुद्दा यह है कि इन प्रकारों का परीक्षण कैसे किया जाता है और वे कैसे व्यवहार करते हैं। उदाहरण के लिए एक सामान्य प्रकार के पैरामीटर के लिए T {...T} को T लिए असाइन करने योग्य है, {x: number, ...T} बारे में क्या है, अगर T में विधियां हैं, तो क्या होगा, आदि.. https://github.com/Microsoft/TypeScript/issues/10727 आवश्यक प्रकार के सिस्टम परिवर्तनों की गहराई से व्याख्या प्रदान करता है।

mhegazy 22 सित॰ 2016

👍1

मैं पूरी तरह से सराहना करता हूं कि इस सुविधा के एक आदर्श उपचार के लिए आवश्यक प्रकार की प्रणाली वृद्धि मामूली नहीं है, और यह देखना बहुत अच्छा है कि उन्हें उत्साह से निपटाया जा रहा है! मैं बस यही दोहराता हूँ,

जब हम "सही" कार्यान्वयन की प्रतीक्षा करते हैं, तो संपत्ति के प्रसार के लिए वाक्यात्मक समर्थन + Object.assign की सरल टाइपिंग एक बहुत ही उपयोगी स्टॉपगैप होगी। परफेक्ट को अच्छाई का दुश्मन न बनने दें।

pelotom 22 सित॰ 2016

👍23 👎2

ऐसा लगता है कि प्रस्ताव चरण 3 पर पहुंच गया है: https://github.com/tc39/proposals

filipesilva 2 अक्तू॰ 2016

👍67 🎉17

@ddagan tsx के साथ आपका उदाहरण काम नहीं करेगा

bloadvenro 7 अक्तू॰ 2016

इस सुविधा के लिए कोई समय सीमा?

Zeragamba 5 नव॰ 2016

@ SpyMaster356 मैं इसे थोड़ी देर के लिए गुप्त कर रहा हूं और ऐसा लगता है कि यह करीब है। @sandersn पिछले कुछ हफ्तों से (कम से कम) इस पर गधा मार रहा है। मैं

आप यहां (https://github.com/Microsoft/TypeScript/pull/12028) और यहां (https://github.com/Microsoft/TypeScript/pull/11150) का अनुसरण कर सकते हैं।

dsifford 5 नव॰ 2016

👍29 🎉20 😄8 ❤7

किसी को रोडमैप अपडेट करना चाहिए

xooxdoo 12 नव॰ 2016

👍4

ऐसा लगता है कि इस सुविधा का उपयोग करने से अज्ञात प्रॉप्स के असाइनमेंट की अनुमति मिलती है:

interface State {
  a: string;
  b: number;
}

let state: State = { a: "a", b: 0 };

state = {...state, x: "x"}; // No error

मैं एक त्रुटि की उम्मीद कर रहा था कि x State की ज्ञात संपत्ति नहीं है। क्या यह सुविधा काम नहीं करती है?

उदाहरण के लिए, इस पीआर से पहले मेरा वर्तमान समाधान यह था:

state = update(state, { x: "x" }); // Error: Property 'x' is missing in type 'State'.

function update<S extends C, C>(state: S, changes: C): S {
  return Object.assign({}, state, changes);
}

क्या ऑब्जेक्ट स्प्रेड/आराम से इसे हासिल करना संभव है?

aaronbeall 7 दिस॰ 2016

ऑब्जेक्ट रेस्ट एंड स्प्रेड, ES प्रस्ताव के अनुसार, Object.assign समान व्यवहार करता है। संपत्ति का अंतिम उल्लेख "जीतता है"। कोई त्रुटि की सूचना नहीं है। आपके उदाहरण में, {...state, x:"X"} का प्रकार { a: string, b:number, x:string } ; और यह प्रकार State लिए असाइन करने योग्य है और इस प्रकार असाइनमेंट काम करता है। यह कहने जैसा ही है कि let state: State = { a: "a", b:0, x: "X" }; को भी अनुमति दी जाएगी।

mhegazy 7 दिस॰ 2016

लेकिन यही वह है जिसके बारे में मैं उलझन में हूं: let state: State = { a: "a", b:0, x: "X" } त्रुटि Object literal may only specify known properties, and 'x' does not exist in type 'State' देता है जो मैं चाहता हूं ... ऑब्जेक्ट शाब्दिक से बाहर आने पर यह एक वैध असाइनमेंट क्यों है फैल?

aaronbeall 7 दिस॰ 2016

👍2

क्षमा करें .. वस्तु शाब्दिक एक विशेष मामला है। मेरा उदाहरण गलत था। यहाँ एक बेहतर उदाहरण है:

let obj = { a: "a", b:0, x: "X" };
let state: State = obj; // OK

यहाँ मुद्दा अगर बल्कि व्यक्तिपरक है। जब संकलक let state:State = { a: "a", b:0, x: "X" } देखता है, तो संभावना है कि x एक टाइपो है, या तो एक पुरानी संपत्ति जिसे रिफैक्टरिंग के बाद छोड़ दिया गया था, या एक वैकल्पिक संपत्ति के लिए एक प्रकार, यही कारण है कि इसे एक के रूप में रिपोर्ट किया जाता है त्रुटि।

हालांकि, यदि आप कोई वस्तु फैलाते हैं, तो मान लें कि let myConfig : State= { a: 1, ...myOtherBigConfigBag} , यदि myOtherBigConfigBag में कुछ ऐसे गुण हैं जिनकी आपको परवाह नहीं है, तो आपको केवल a और b , यहां एक त्रुटि आपको इन दो इंटरफेस को सिंक में रखने के लिए मजबूर करेगी, या इन त्रुटियों को दूर करने के लिए डाली जाएगी।

ने कहा कि। हमें इस फैसले पर पुनर्विचार करना चाहिए। इसे ट्रैक करने के लिए https://github.com/Microsoft/TypeScript/issues/12717 दायर किया।

mhegazy 7 दिस॰ 2016

👍7

समझा। मुझे #12717 में आपका विचार पसंद आया, ठीक यही मैं सोच रहा था। मैं वास्तव में इस तरह के व्यवहार को स्प्रेड प्रॉप्स के लिए भी पसंद करूंगा लेकिन मैं आपकी बात देख सकता हूं कि यह बहुत ही व्यक्तिपरक है और कुछ सामान्य जेएस उपयोग के मामलों के लिए कष्टप्रद हो सकता है।

aaronbeall 8 दिस॰ 2016

@aaronbeall मैं सहमत हूं, यह सामान्य JS उपयोग के मामलों के लिए कष्टप्रद होगा ... अधिकांश समय, आप केवल यह सुनिश्चित करना चाहते हैं कि ऑब्जेक्ट में निर्दिष्ट इंटरफ़ेस का आकार है और सीधे स्प्रेड ऑब्जेक्ट का निरीक्षण नहीं करता है, वर्तमान कार्यान्वयन ठीक है IMO

bondz 8 दिस॰ 2016

नमस्कार दोस्तों, शानदार रिलीज के लिए बधाई! अब एक योग्य आराम का समय है ... चुड़ैल की बात करना मुझे बाकी ऑपरेटर के साथ कोई समस्या है :)

प्रतिक्रिया का उपयोग करके आपके पास टिपिक रूप से एक घटक होता है जैसे:

export interface MyLinkProps extends React.HTMLAttributes {
    myUrl: string
}

class MyLink{

    render(){
      const {myUrl, ...attrs } = this.props;
     return <a href={calculate(myUrl)} ...attrs>Click here</a>;
   }
}

मुद्दा यह है कि जब आप माउस से attrs पर होवर करते हैं तो आपको React.HtmlAttributes के बजाय सभी गुणों (सैकड़ों) की सूची मिलती है।

मुझे पता है कि टाइपस्क्रिप्ट संरचनात्मक रूप से टाइप किया गया है और वह सब, लेकिन बाकी चर के लिए एक स्पष्ट प्रकार असाइन करना संभव हो सकता है?

कुछ विकल्प:

    const {myUrl, ...attrs as React.HtmlAttributes } = this.props; //Is not really a casting

    const {myUrl, ...attrs : React.HtmlAttributes } = this.props; //conflicts with ES6?

    const attrs : React.HTMLAttributes; 
    const { myUrl, ...attrs } = this.props;  //re-declare the variable

olmobrutall 8 दिस॰ 2016

😄1

@bondz ठीक है, यह मेरी परियोजना में 100% उपयोगों में सच नहीं है। :) लेकिन किसी अन्य प्रोजेक्ट में यह बहुत कष्टप्रद हो सकता है। मेरे मामले में मैं रेडक्स और रिएक्ट का उपयोग कर रहा हूं और अपरिवर्तनीय स्थिति का भारी उपयोग कर रहा हूं, जिसका अर्थ है कि राज्य वस्तुओं को अद्यतन या बनाना है, मुझे सभी प्रोप को एक नई वस्तु शाब्दिक पर कॉपी करना होगा ... सभी मामलों में मुझे 100% प्रकार की सुरक्षा चाहिए कि मैं मैं लक्ष्य राज्य इंटरफ़ेस पर सही डेटा कॉपी करने का प्रयास कर रहा हूं। वर्तमान में मैं इस सुरक्षा को सुनिश्चित करने के लिए फ़ंक्शंस का उपयोग करता हूं, लेकिन मैं ऑब्जेक्ट स्प्रेड का उपयोग करना पसंद करूंगा क्योंकि इसका क्लीनर (पठनीय, अभिव्यंजक, मानक सिंटैक्स।) लेकिन किसी और की परियोजना में वे अलग व्यवहार चाहते हैं क्योंकि वे बहुत अधिक अप्रयुक्त या ढीली वस्तु का उपयोग कर रहे हैं। संरचनाएं, इसलिए मैं देखता हूं कि यह कैसे काफी व्यक्तिपरक है। मुझे लगता है कि #12717 सुझाव एक अच्छा मध्य मैदान है (और मौजूदा वस्तु शाब्दिक प्रकार की सुरक्षा के साथ अधिक संगत है।)

aaronbeall 8 दिस॰ 2016

👍2

https://github.com/Microsoft/TypeScript/issues/2103#issuecomment -145688774
हम इसे संबोधित करने से पहले चरण 3 तक पहुंचने के प्रस्ताव की प्रतीक्षा करना चाहते हैं।

ऐसा लगता है कि यह पहले से ही राज्य 3 है, इसका समर्थन करने की कोई योजना है?

बीटीडब्ल्यू, हम मुख्य रूप से ईएस विकास के लिए वीएससीओडी का उपयोग करते हैं, टीएस अभी तक नहीं :)

evisong 16 दिस॰ 2016

@evisong इस सुविधा को भेज दिया गया है और पहले से ही vsCode के नवीनतम संस्करण में उपलब्ध है। अपने vsCode को संस्करण 1.8 . में अपडेट करें

bondz 16 दिस॰ 2016

👍2

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Typescript: प्रस्तावित ES रेस्ट/स्प्रेड प्रॉपर्टीज़ का समर्थन करें

गुण फैलाओ

टाइपिंग

उत्सर्जक

बाकी गुण

टाइपिंग

उत्सर्जक

सबसे उपयोगी टिप्पणी

सभी 96 टिप्पणियाँ

इस पोस्ट पर ध्यान न दें, बेहतर क्रियान्वयन के लिए नीचे देखें

अपडेट करें (इसे भी अनदेखा करें, और भी बेहतर के लिए नीचे देखें)

संबंधित मुद्दों