@gustavderdrache @Ledragon ऊपर मैंने कुछ उत्कृष्ट कार्यों को ओउवर के दौर में समेकित किया है जो डी 3 परिभाषाओं का सेट है।

एक महत्वपूर्ण प्रश्न: क्या हम सभी परिभाषाओं को लगातार एक TS>=2.3 बाधा में अपग्रेड करना चाहते हैं और इस प्रक्रिया में जेनरिक के लिए डिफ़ॉल्ट असाइनमेंट का उपयोग करके कुछ फ़ंक्शन/विधि अधिभार को हटाना चाहते हैं?
मैंने देखा कि (अनजाने में) कुछ परिभाषाओं में पहले से ही परिभाषा शीर्षलेख में // TypeScript Version: 2.3 बाधा है। जैसे d3-geo , जो geoJson परिभाषाओं का उपयोग करता है। ये पहले से ही सामान्य डिफ़ॉल्ट का उपयोग करते हैं।

इस मामले पर आपके विचार स्वागत से अधिक होंगे।

इसे समझें आपको इसका अध्ययन करना होगा

यदि न्यूनतम TS 2.3 लागू किया जा रहा है, तो हमें $# any के बजाय object प्रकार का उपयोग करने में सक्षम होना चाहिए, जहां उपयुक्त हो। टीएस 2.2 के साथ आया था। अगर मैं सही ढंग से याद करूं, तो ऑब्जेक्ट इंटरपोलेटर और डी 3-संग्रह में कुछ अवसर थे।

पहले विचार:

• आपके सामने आई आउट-ऑफ-मेमोरी बग के कारण, क्या हमें 2.4 को हर जगह लागू नहीं करना चाहिए?
• मेरे पास strictNullChecks और strictFunctionTypes के साथ एक शाखा है । मैं इसे अपडेट करूंगा और एक पीआर जमा करूंगा। मुझे लगा कि मैंने किया है, लेकिन ऐसा नहीं लगता

इस पर मेरी राय लेने से पहले मुझे डिफ़ॉल्ट जेनरिक के बारे में सीखना होगा: p

टीएस 2.3 के साथ हम अप्रैल 2017 में एक रिलीज को पीछे से देख रहे हैं।
टीएस 2.4 जून 2017 को जारी किया गया था।

तो बड़ा सवाल यह है: क्या हम कम से कम 2.4 (2.3 के बजाय) को मजबूर करते हुए बड़े या नगण्य/स्थापित आधार के किसी भी हिस्से में समस्याएँ पैदा कर रहे हैं?

मुझे लगता है कि अतिरिक्त चुनौतियों में से एक यह है कि हमारे पास संभावित रूप से तोड़ने वाले परिवर्तनों को ध्वजांकित करने के लिए चेंजलॉग नहीं है कि डी 3 परिभाषाओं का उपभोग कैसे किया जाता है। और स्पष्ट डिस्कनेक्ट, कि परिभाषाओं के मामूली संस्करण रिलीज में एक ब्रेकिंग परिवर्तन हो सकता है, क्योंकि वे अंतर्निहित डी 3 रिलीज चक्र के साथ गठबंधन कर रहे हैं।

@gustavderdrache नए न्यूनतम के रूप में TS 2.4 पर आपका क्या विचार है?

जैसा कि पीआर # 23654 में देखा गया है, हम टीएस 2.4 में जाने पर जल्दी से कैस्केड करते दिखाई देते हैं (भले ही यह डीटी के लिए किसी भी टीएस 2.4 सुविधाओं जैसे स्ट्रिंग एनम का उपयोग किए बिना बाधा उत्पन्न कर रहा हो)।

नए पीआर #23724 के अनुसार स्पष्टता के लिए हम केवल टीएस 2.3 का उपयोग करके आगे बढ़ सकते हैं। अभी तक TS 2.4 के साथ आगे बढ़ने की आवश्यकता नहीं है।

@Ledragon यदि आप अपने स्थानीय d3-geo कांटा में पहले से लंबित पीआर खोलना चाहते हैं, तो हम ऊपर दिए गए बॉक्स को चेक करने के लिए काम कर सकते हैं।

मैं वास्तव में इसे स्थानीय रूप से परीक्षण नहीं कर सकता ... इसलिए मुझे लगता है कि मैं इसे जमा कर सकता हूं, लेकिन मुझे नहीं लगता कि यह ट्रैविस परीक्षण पास करेगा। मैं अभी आगे जाकर देखता हूँ

23794 सबमिट किया गया - मेरा सबसे गौरवपूर्ण काम नहीं, देखते हैं यह कैसा चलता है...

ठीक है, तो समस्या इस प्रकार है: d3-geo परीक्षण TS 2.3 में विफल हो जाते हैं, इसलिए मैंने संस्करण को 2.4 पर सेट करने का प्रयास किया। हालांकि, d3 वैश्विक TS 2.3 पर सेट है, इसलिए यह भी काम नहीं करता है। आगे बढ़ने के बारे में कोई सलाह?

मैं g3-geo PR को देखूंगा और उन पर ध्यान केंद्रित रखने के लिए कोई भी समीक्षा टिप्पणी करूंगा। मेरे पास d3- संग्रह के साथ OoM बग के विपरीत, हमारे पास के साथ काम करने के लिए एक उचित त्रुटि संदेश है

d3-contour को 1.2.0 . में अपडेट करने के लिए अभी #24118 सबमिट किया गया है
मैंने देखा कि d3-contour प्रकार पहले से ही TS2.3 में हैं, और strictNullChecks और strictFunctionTypes सत्य पर सेट हैं :-)

d3-contour के शीर्ष पर रहने के लिए धन्यवाद, मुझे ध्यान दिया कि किसी अजीब कारण से मेरे पास "देखने" पर रेपो नहीं था। उसे बदल दिया! :मुस्कुराओ:

जल्द ही पीआर देखेंगे।

मैं d3-अक्ष और d3-प्रारूप पर काम कर रहा हूँ। मैंने लगभग खत्म कर लिया है। लेकिन कुछ सवाल हैं...

d3-प्रारूप में मैं d3-सरणी की तुलना में समान Numeric इंटरफ़ेस का उपयोग करना चाहता हूं:

interface Numeric {
    valueOf(): number;
}

लेकिन ऐसा करते समय, d3 वैश्विक परिभाषाओं में, मुझे तार्किक रूप से त्रुटि है: Module 'd3-array' has already exported a member named 'Numeric'. क्या d3 पुस्तकालयों के लिए साझा प्रकार रखने की जगह है?

इसके अलावा कुछ डी 3 परिभाषाओं (इंटरपोलेट, स्केल, आकार) में आप संघ प्रकार number | { valueOf(): number } पा सकते हैं। क्या { valueOf(): number } पर्याप्त नहीं है?

@denisname d3-axis , d3-format और बाद में d3-array के लिए स्वयंसेवा करने के लिए धन्यवाद !!!

ऊपर आपके प्रश्नों के लिए:

(1) d3-xxx मॉड्यूल के लिए परिभाषाएँ लिखने के लिए एक मौलिक नियम के रूप में, परिभाषाओं को कभी भी उन निर्भरता का परिचय नहीं देना चाहिए जो अंतर्निहित संबंधित D3 मॉड्यूल के बीच मौजूद नहीं हैं। उदाहरण के d3-axis की d3-array पर कोई निर्भरता नहीं है, इसलिए, d3-axis की परिभाषा index.ts फ़ाइल को d3-axis d3-array आयात नहीं करना चाहिए। यह जेएस स्रोतों के अनुरूप ढीला युग्मन सुनिश्चित करता है। इसलिए संदेह के मामले में अंतर्निहित डी3 मॉड्यूल के $ dependencies संपत्ति की जांच करें package.json _नोट: आप निश्चित रूप से d3-xxx-test.ts फ़ाइल में किसी भी पैकेज से आयात कर सकते हैं, यह और भी अच्छा है अभ्यास हमने "एकीकरण" परीक्षण के लिए कई पैकेजों में किया। यानी दो पैकेजों के बीच कोई औपचारिक निर्भरता नहीं हो सकती है, लेकिन एक के सदस्य "स्वाभाविक रूप से" दूसरे के लिए इनपुट का उपयोग करते हैं। उदाहरण के लिए हम d3-selection का उपयोग d3-selection d3-chord एक परीक्षण में कर रहे हैं ताकि यह सुनिश्चित किया जा सके कि बिना किसी समस्या के चयन विशेषता सेटर में एक तार पथ पारित किया जा सके।_

(2) आप सही हैं, कि Numeric इंटरफ़ेस को किसी अन्य D3 मॉड्यूल में फिर से घोषित नहीं किया जा सकता है, जो नियम (1) के अनुपालन में d3-array से आयात नहीं कर सकता है।

(3) क्या { valueOf(): number } पर्याप्त नहीं है? तकनीकी रूप से, हाँ। व्यावहारिक रूप से, चौराहे का प्रकार, कुछ अतिरेक होने के बावजूद, बहुत सारे मानव उपयोगकर्ताओं के लिए घोषणात्मक रूप से स्पष्ट है। यानी यह दर्शाता है कि मानसिक कलाबाजी के बिना पहली नज़र में number एक वैध प्रकार है। :आँख मारना:

d3-रंग के बारे में, prototype सभी पर टिप्पणी क्यों की गई है? इस कमिटमेंट में @tomwanzek ने किया है।

प्रोटोटाइप वापस सेट होने के साथ, हम टाइपगार्ड फ़ंक्शन की आवश्यकता के बिना सीधे instanceof का उपयोग कर सकते हैं:

let cRGB: d3.RGBColor;
let cHSL: d3.HSLColor;

const c: d3.RGBColor | d3.HSLColor = d3.color("steelblue");

if (c instanceof d3.rgb) {
    cRGB = c;
} else {
    cHSL = c;
}

@denisname मैं एक इंटरफ़ेस में प्रकाशित एपीआई के हिस्से के रूप में prototype को परिभाषित करने में संकोच कर रहा हूं, यह बहुत हैकी लगता है।

आज के टाइप गार्ड स्पेक से मैं जो समझता हूं उसके लिए। इसे अब एक वैध _construction_ माना जाता है। सूची आइटम देखें:

x instanceof C फ़ॉर्म का एक प्रकार का गार्ड, जहां x कोई भी प्रकार का नहीं है, C वैश्विक प्रकार 'फ़ंक्शन' के उप-प्रकार का है, और C में एक संपत्ति है जिसका नाम है 'प्रोटोटाइप' [...]

मैं strictNullChecks के d3-color $ संस्करण का प्रस्ताव देना चाहता हूं। जो सिर्फ एक लाइन चेंज है। यह prototype भी जोड़ने का अवसर होगा।

मेरे अपने परीक्षण से, आपको प्रकार को ठीक से संकीर्ण करने के लिए prototype संपत्ति या new(): T के लिए instanceof $ की घोषणा की आवश्यकता है। मैंने v3 टाइपिंग में new(): Color भिन्नता का उपयोग किया है, और यह उपयोगी हो सकता है यदि वह मुहावरा अभी भी D3v4 और इसके बाद के संस्करण द्वारा समर्थित है।

जैसा कि कोई भी ठीक लगता है, मुझे लगता है कि हम निरंतरता के लिए v3 सम्मेलन का पालन कर सकते हैं। बढ़िया काम, दोनों।

@gustavderdrache

d3 v3 में यह क्यों काम करता है, इसकी मेरी समझ यह है कि new() का रिटर्न प्रकार हमेशा prototype प्रकार जैसा ही होता है। लेकिन d3 v4 में हमारे पास भी है:

export const color: ColorFactory;
export interface ColorFactory extends Function {
    (cssColorSpecifier: string): RGBColor | HSLColor;
    prototype: Color; // and not RGBColor | HSLColor !
}

वास्तव में, d3.lab(0,0,0) instanceof d3.color सच है। इसलिए, यदि हम इस इंटरफ़ेस को इसमें बदलते हैं:

export const color: ColorFactory;
export interface ColorFactory extends Function {
    (cssColorSpecifier: string): RGBColor | HSLColor;
    new (cssColorSpecifier: string): RGBColor | HSLColor;
}

हमारे पास prototype के लिए ColorFactory प्रकार Color नहीं है। और निम्न कोड संकलित करने में विफल रहता है, जबकि इसे नहीं करना चाहिए।

declare let l: d3.LabColor | null;
declare let c: d3.Color;
declare let nil: null;

if (l instanceof d3.color) {
    c = l; // l is not inferred as `d3.LabColor`...
} else {
    nil = l; // fail, l is a `d3.LabColor | null` should be a `null`
}

आप की राय क्या है? क्या इसे new के साथ काम करने का कोई तरीका है? धन्यवाद।

ऐसा लगता है कि कुछ परीक्षण के आधार पर prototype की संपत्ति color() Color चाहिए न कि RGBColor | HSLColor :

> d3.color.prototype === d3.rgb.prototype
false
> d3.rgb.prototype instanceof d3.color
true

color() फ़ंक्शन RGB या HSL रंग लौटाता है, लेकिन इसका प्रोटोटाइप अन्य रंग रिक्त स्थान का एक सुपरटाइप है।

@denisname @Ledragon @gustavderdrache चूंकि आप सभी इस धागे पर हैं, बस एक संक्षिप्त FYI के रूप में: मैं उन खुली वस्तुओं को पकड़ने का इरादा रखता हूं जिनके बारे में आप इस सप्ताह के अंत में जानते हैं।

ठीक है, d3-geo दरवाजे से बाहर है (धन्यवाद @ledragon) और मैंने फिर से खोलने के संबंध में d3-format और d3-axis के लिए @denisname के दुर्भाग्य से बंद पीआर पर टिप्पणी की।

एक सामान्य नोट के रूप में, मैं अनुशंसा करता हूं कि @denisname परिभाषाओं के लिए एक और रखरखाव के रूप में जोड़ा जाए, वे काम करते हैं।

मैं अगले d3-color पर एक नज़र डाल सकता हूं, और 1.1.0 के अपडेट के साथ इसमें शामिल हो सकता हूं। क्या हमें इस अपग्रेड के लिए एक अलग मुद्दा खोलना चाहिए?

इसके अलावा, @denisname बोर्ड पर आपका स्वागत है!

@ लेड्रैगन धन्यवाद।

मेरे पास d3-color के लिए एक अपडेट तैयार है (अभी तक कोई lhc और gray नहीं)। मैं बस एक छोटी सी समस्या से फंस गया हूँ।

@gustavderdrache ने कहा:

रंग () फ़ंक्शन RGB या HSL रंग लौटाता है, लेकिन इसका प्रोटोटाइप अन्य रंग रिक्त स्थान का एक सुपरटाइप है।

वास्तव में और यह आसानी से _typed_ हो सकता है, मेरी टिप्पणी में पहला इंटरफ़ेस देखें। लेकिन @tomwanzek ने केवल new() का उपयोग करने और prototype से बचने का प्रस्ताव दिया। मुझे लगता है कि इस विशेष मामले में यह संभव नहीं है। नहीं?...

इसके साथ कुछ और खेलने के बाद, मुझे समस्या दिखाई दे रही है। आप new(): Color को ColorConstructor इंटरफ़ेस में सेट कर सकते हैं, लेकिन यह वास्तव में फ़ंक्शन के रिटर्न मान को कवर नहीं करता है:

declare namespace d3 {
  interface Color {
    // I forgot what was on the Color interface
    // This property exists just to make Color incompatible with {}
    __isColor: never;
    toString(): string;
  }

  interface RGBColor extends Color {
    r: number;
    g: number;
    b: number;
  }

  interface HSLColor extends Color {
    h: number;
    s: number;
    l: number;
  }

  interface LABColor extends Color {
    l: number;
    a: number;
    b: number;
  }

  interface ColorConstructor {
    (specifier: string): RGBColor | HSLColor;
    new(specifier: string): Color; // <- TS uses this for narrowing with instanceof
  }

  const color: ColorConstructor;
}

declare let l: d3.LABColor | null;
declare let c: d3.Color;
declare let nil: null;

if (l instanceof d3.color) {
  // Succeeds with l: d3.LABColor
  c = l;
} else {
  // Succeeds with l: null
  nil = l;
}

निष्कर्ष में: मुझे लगता है कि हमें prototype संपत्ति का पर्दाफाश करना होगा, क्योंकि यह वास्तव में कन्स्ट्रक्टर और instanceof परीक्षण दोनों के सही व्यवहार को कवर करने का एकमात्र तरीका है:

  interface ColorConstructor {
    (specifier: string): RGBColor | HSLColor;
    new(specifier: string): RGBColor | HSLColor;

    readonly prototype: Color; 
  }

क्षमा करें, इस पर वापस आने में देरी के लिए। prototype के साथ जाने के लिए स्वतंत्र महसूस करें, दिन में वापस, instanceof को भी संबोधित करना मेरा पहला आवेग था। यह सिर्फ "महसूस किया" हैकी, लेकिन जैसा कि इसे एक स्वीकार्य अभ्यास माना जाता है, और यदि new() का उपयोग करने के साथ निरंतरता एक विकल्प नहीं है जैसा कि D3v3 में है ... चलो क्या काम करता है!

@tomwanzek क्या आप ट्रैकिंग टेबल अपडेट कर सकते हैं।

पुस्तकालयों के लिए strictNullChecks strictFunctionTypes और TS 2.3 कॉलम में एक सेट किया जाना चाहिए d3-axis , d3-color , d3-dispatch , d3-format , d3-polygon और d3-hsv ।

साथ ही d3-dispatch , d3-polygon और d3-hsv $ के लिए कॉलम JSDoc में एक सेट किया जाना चाहिए।

धन्यवाद

d3-geo इंटरफ़ेस GeoIdentityTranform में एक टाइपो है। यह GeoIdentityTransform ( s के साथ) होना चाहिए। क्या मैं इसे ठीक कर सकता हूँ? पिछड़ी संगतता के बारे में कोई चिंता?

@denisname d3-geo s GeoIdentityTranform के लिए, मुझे लगता है कि हम निम्नलिखित कार्य कर सकते हैं:

• गलत वर्तनी वाले इंटरफ़ेस का नाम बदलें (शानदार पकड़!) ( geoIdentity() के रिटर्न प्रकार के रूप में इसके उपयोग सहित)
• कुछ समय के लिए जोड़ें

/**
 * <strong i="13">@deprecated</strong> Misspelled name. Use GeoIdentityTransform.
 */
export type GeoIdentityTranform = GeoIdentityTransform;

• बाद में सुविधाजनक चरण में गलत वर्तनी वाले प्रकार को पूरी तरह से हटा दें।

@denisname @gustavderdrache @ledragon पिछले कुछ समय में कड़ी मेहनत के लिए धन्यवाद। मैंने ट्रैकिंग टेबल को अपडेट किया है, पहले से ही बहुत सुंदर लग रहा है! 'क्योंकि एक सुंदर ट्रैकिंग टेबल वह है जिसे हम यहां लक्षित कर रहे हैं: मुस्कान:

'क्योंकि एक सुंदर ट्रैकिंग तालिका वह है जिसे हम यहां लक्षित कर रहे हैं

बिल्कुल! बेहतर प्रकार की परिभाषाएँ केवल एक सुखद दुष्प्रभाव हैं।

क्या आप में से कोई तकनीकी ऋण को पूरा करने के लिए अभी विशिष्ट परिभाषाओं पर काम कर रहा है? जबकि d3-सरणी प्रक्रिया में है। मैं strictFunctionTypes को d3-transition में d3-selection के साथ समता में लाने के लिए निपटूंगा। बस #25805 के विलय का इंतजार है।

एटीएम नहीं। आप सभी को बताएंगे कि मैं कब और कब करूंगा

5.2.0 वैश्विक बंडल पर मुहर लगाने में सक्षम होने के लिए #25582 पर काम करना

मेरे पास d3-hierarchy तैयार (सख्त और jsDoc) के लिए एक अपडेट है।
d3-dsv और d3-fetch (ts 2.3) पर भी काम कर रहा है।

@denisname @tomwanzek @gustavderdrache
क्या हमें इस पर ध्यान देना चाहिए, या d3 को नवीनतम संस्करण में अपडेट करना चाहिए? अब हम वैश्विक पैकेज पर 5 छोटे संस्करण पीछे हैं (हालांकि सभी उप-पैकेज 5.2.0 के लिए तैयार हैं जो मुझे लगता है)। क्या मैं वैश्विक पैकेज स्थिति को ट्रैक करने के लिए एक अलग मुद्दा खोलूंगा?

@ लेड्रैगन मैं आज रात खुले पीआरएस के साथ पकड़ लूंगा और मुद्रा के लिए सभी डी 3 मॉड्यूल परिभाषाओं का विश्लेषण करूंगा। यदि कोई अंतराल है, तो मैं उन्हें सममूल्य पर लाने के लिए एक ट्रैकिंग समस्या बनाऊंगा। जहां तक ​​प्राथमिकताओं का सवाल है, मैं इस बात से सहमत हूं कि तकनीकी ऋण कटौती पर मुद्रा को प्राथमिकता दी जानी चाहिए।

इस धागे को प्रदूषित करने के लिए क्षमा करें, मैं अब एक नई परियोजना के लिए D3.js में वापस आ रहा हूं .. और मैं सोच रहा था कि क्या इनलाइन टाइपस्क्रिप्ट एनोटेशन को D3 के लिए माना जाता था?

/** <strong i="6">@type</strong> {SyncBailHook<Compilation>} */
shouldEmit: new SyncBailHook(["compilation"]),

वेबपैक में, उन्होंने टाइपस्क्रिप्ट कंपाइलर के साथ जावास्क्रिप्ट की जांच के लिए इसका उपयोग करना शुरू कर दिया। बड़ा प्लस टाइपिंग परिभाषाएं वास्तविक कोड के ठीक बगल में रहती हैं।
https://github.com/webpack/webpack/blob/master/lib/Compiler.js#L51

हाय @ फिल-एलजीआर
d3 इश्यू ट्रैकर पर बहुत पहले चर्चा नहीं हुई थी, और यह प्राथमिकता सूची के शीर्ष पर नहीं लग रहा था (यानी माइक बोस्टॉक ने टाइपिंग के बजाय पुस्तकालय को विकसित करने पर ध्यान केंद्रित करना पसंद किया)। मुझे धागे का लिंक नहीं मिल रहा है। हो सकता है कि इस नई जानकारी के लिए धन्यवाद फिर से सवाल उठाया जा सकता है, लेकिन मुझे नहीं लगता कि ऐसा होने की संभावना है

@tomwanzek क्या आप ट्रैकिंग टेबल अपडेट कर सकते हैं।

पुस्तकालयों के लिए strictNullChecks strictFunctionTypes और TS 2.3 कॉलम में एक सेट किया जाना चाहिए d3-array , d3-array , d3-dsv , d3-fetch , d3-hexbin , d3-hierarchy , d3-interpolate , d3-quadtree , d3-queue , d3-request , d3-timer और d3-voronoi ।

साथ ही कॉलम JSDoc में d3-color , d3-hexbin , d3-hierarchy , d3-interpolate और d3-quadtree के लिए एक सेट किया जाना चाहिए।

धन्यवाद