gustavderdracheLedragon Above لقد عززت بعض المهام المعلقة لتقريب عدد الأعمال التي تمثل مجموعة تعريفات D3.

سؤال رئيسي: هل نريد ترقية جميع التعريفات باستمرار إلى قيد TS> = 2.3 وفي هذه العملية إزالة بعض الوظائف / الطرق الزائدة باستخدام التخصيصات الافتراضية للأدوية؟
لقد لاحظت (عن غير قصد) أن بعض التعريفات تحتوي بالفعل على القيد // TypeScript Version: 2.3 في رأس التعريفات. على سبيل المثال ، d3-geo ، الذي يستخدم تعريفات geoJson . هذه بالفعل تستخدم الافتراضات العامة.

أفكارك حول هذا الموضوع ستكون أكثر من موضع ترحيب.

افهم هذا عليك دراسته

في حالة تنفيذ TS 2.3 كحد أدنى ، يجب أن نكون قادرين أيضًا على استخدام النوع object بدلاً من any ، حيثما كان ذلك مناسبًا. جاء مع TS 2.2. إذا كنت أتذكر بشكل صحيح ، كان هناك عدد قليل من الفرص مع محرف الكائنات وفي مجموعة d3.

الأفكار الأولى:

• نظرًا لخلل نفاد الذاكرة الذي واجهته ، ألا يجب علينا فرض 2.4 في كل مكان؟
• لدي فرع بـ strictNullChecks و strictFunctionTypes هنا . سوف أقوم بتحديثه وتقديم PR. ظننت أنني فعلت ذلك ، لكن لا يبدو الأمر كذلك

لا بد لي من التعرف على الأدوية الجنيسة الافتراضية قبل أن يكون لدي رأي في هذا: ص

مع TS 2.3 ، نتطلع إلى إصدار من الخلف في أبريل 2017.
تم إصدار TS 2.4 في يونيو 2017.

لذا فإن السؤال الكبير هو: هل نخلق مشكلات في جزء كبير أو مهمل / لا يوجد جزء من القاعدة المثبتة عند فرض 2.4 كحد أدنى (بدلاً من 2.3)؟

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

gustavderdrache ما رأيك في TS 2.4 كحد أدنى جديد؟

كما هو موضح في PR # 23654 ، يبدو أننا نتعاقب بسرعة عند الانتقال إلى TS 2.4 (حتى لو كان مجرد فرض قيود من أجل DT دون استخدام أي ميزات TS 2.4 مثل تعدادات السلسلة).

من أجل الوضوح وفقًا لـ PR # 23724 الجديد ، يمكننا المتابعة ببساطة باستخدام TS 2.3. لا حاجة للمضي قدمًا في TS 2.4 اعتبارًا من الآن.

Ledragon إذا كنت ترغب في فتح PR لديك بالفعل معلق في d3-geo fork المحلي الخاص بك ، فيمكننا العمل من خلال تحديد المربعات أعلاه.

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

23794 قدم - ليس عملي الذي أفتخر به ، فلنرى كيف ستسير الأمور ...

حسنًا ، المشكلة كما يلي: d3-geo فشلت الاختبارات في TS 2.3 ، لذلك حاولت ضبط الإصدار على 2.4. ومع ذلك ، تم تعيين d3 global على TS 2.3 ، لذلك لا يعمل ذلك أيضًا. هل من نصيحة عن كيفية التقدم؟

سألقي نظرة على العلاقات العامة في g3-geo وسأضع أي تعليقات مراجعة هناك للحفاظ على تركيزهم. على عكس خطأ OoM الذي واجهته مع مجموعة d3 ، لدينا رسالة خطأ مناسبة للعمل معها 😄

أرسل للتو # 24118 لتحديث d3-contour إلى 1.2.0
لقد لاحظت أن الأنواع d3-contour موجودة بالفعل في TS2.3 ، وتم تعيين strictNullChecks و strictFunctionTypes على true :-)

شكرًا للبقاء على قمة محيط d3 ، جعلني ألاحظ أنه لسبب غريب لم يكن لدي الريبو على "المشاهدة". غيرت ذلك! :ابتسامة:

سوف ننظر في العلاقات العامة قريبا.

أنا أعمل على محور d3 و d3-format. لقد انتهيت تقريبا. لكن لديك بعض الأسئلة ...

في تنسيق d3 ، أريد استخدام نفس واجهة Numeric نفسها الموجودة في مصفوفة d3:

interface Numeric {
    valueOf(): number;
}

ولكن عند القيام بذلك ، في التعريفات العالمية d3 ، لدي الخطأ المنطقي: Module 'd3-array' has already exported a member named 'Numeric'. هل يوجد مكان لوضع الأنواع المشتركة لمكتبات d3؟

أيضًا في بعض تعريفات d3 (إقحام ، مقياس ، شكل) يمكنك العثور على نوع الاتحاد number | { valueOf(): number } . هل { valueOf(): number } غير كافٍ؟

denisname نشكرك على التطوع من أجل d3-axis ، d3-format ولاحقًا d3-array !!!

على أسئلتك أعلاه:

(1) كقاعدة أساسية لكتابة التعريفات للوحدات النمطية d3-xxx ، يجب ألا تقدم التعريفات أبدًا تبعيات غير موجودة بين وحدات D3 الأساسية المقابلة. على سبيل المثال ، لا يعتمد d3-axis على d3-array ، لذلك ، يجب عدم استيراد تعريف ملف index.ts لـ d3-axis من d3-array . وهذا يضمن اقترانًا غير محكم يتوافق مع مصادر JS. لذلك في حالة الشك ، تحقق من خاصية dependencies للوحدة الأساسية D3 package.json _ ملاحظة: يمكنك بالطبع الاستيراد من أي حزمة في الملف d3-xxx-test.ts ، هذا جيد حتى ممارسة اتبعنا في عدد من الحزم لاختبار "التكامل". بمعنى أنه قد لا يكون هناك تبعية رسمية بين حزمتين ، لكن أعضاء أحدهما يستخدم "بشكل طبيعي" مدخلاً للآخر. على سبيل المثال ، نحن نستخدم d3-selection في اختبار في d3-chord للتأكد من إمكانية تمرير مسار الوتر إلى محدد سمات التحديد دون مشاكل.

(2) أنت محق في أنه لا يمكن إعادة الإعلان عن واجهة Numeric في أي وحدة D3 أخرى ، والتي لا يمكن استيرادها من d3-array وفقًا للقاعدة (1).

(3) هل { valueOf(): number } غير كافٍ؟ من الناحية الفنية ، نعم. من الناحية العملية ، فإن نوع التقاطع ، مع وجود بعض التكرار ، ربما يكون أوضح بشكل واضح لكثير من المستخدمين البشر. أي أنه يوضح أن number هو نوع صالح للوهلة الأولى بدون ألعاب بهلوانية عقلية. :غمزة:

حول d3-color ، لماذا تم التعليق على 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 ليس من النوع Any ، و C من نوع فرعي من النوع العام 'Function' ، و C له خاصية مسماة 'النموذج المبدئي' [...]

أود اقتراح إصدار strictNullChecks من d3-color . وهو مجرد تغيير سطر واحد. ستكون هذه فرصة لإضافة prototype أيضًا.

من الاختبار الخاص بي ، تحتاج إما إلى خاصية prototype أو إقرار new(): T لـ instanceof لتضييق النوع بشكل صحيح. لقد استخدمت الاختلاف new(): Color في كتابة v3 ، وقد يكون مفيدًا إذا كان هذا المصطلح لا يزال مدعومًا بواسطة D3v4 وما بعده.

نظرًا لأن أيًا منهما يبدو جيدًا ، أعتقد أننا قد نتبع اصطلاح v3 للاستمرارية. كلاهما عمل رائع.

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

ما أفهمه من سبب نجاحه في 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 ، لكن نموذجها الأولي هو نموذج فائق لمساحات الألوان الأخرى.

denisnameLedragongustavderdrache لأنك جميعًا في هذا الموضوع ، تمامًا كمعلومات موجزة: أعتزم اللحاق بالعناصر المفتوحة التي تعرفها في نهاية هذا الأسبوع.

حسنًا ، d3-geo خارج الباب (شكرًاledragon) وعلقت على العلاقات العامة المغلقة للأسف لـ denisname مقابل d3-format و d3-axis بخصوص إعادة الفتح.

كملاحظة عامة ، أوصي بإضافة denisname كمشرف آخر على التعريفات التي يعملون عليها.

قد ألقي نظرة على d3-color بعد ذلك ، وأنضم إليه بتحديث إلى 1.1.0 . هل يجب أن نفتح مشكلة منفصلة لهذه الترقية؟

أيضًا ، مرحبًا بكم على متن denisname !

Ledragon شكرا.

لدي تحديث جاهز لـ d3-color (لا يوجد lhc و gray حتى الآن). أنا عالق فقط بمشكلة واحدة صغيرة .

gustavderdrache قال:

ترجع الدالة color () ألوان RGB أو HSL ، لكن نموذجها الأولي هو نموذج فائق لمساحات الألوان الأخرى.

في الواقع ويمكن أن يكون هذا _type_ بسهولة ، انظر الواجهة الأولى في تعليقي . لكن 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 .

يجب أيضًا تعيين ✅ في العمود JSDoc لـ d3-dispatch و d3-polygon و d3-hsv .

شكرا

يوجد خطأ إملائي في واجهة $ 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 💯gustavderdracheledragon شكرًا على كل العمل الشاق خلال الفترة القليلة الماضية. لقد قمت بتحديث جدول التتبع ، يبدو أجمل بكثير بالفعل! لأن جدول التتبع الجميل هو ما نهدف إليه هنا: ابتسم:

لأن جدول التتبع الجميل هو ما نهدف إليه هنا

إطلاقا! تعد تعريفات النوع المحسّنة مجرد تأثير جانبي لطيف.

هل يعمل أي منكم على تعريفات محددة الآن لإتمام الدين الفني؟ أثناء تشغيل مجموعة d3 . سأقوم بمعالجة انتقال d3 strictFunctionTypes بعد ذلك لتحقيق التكافؤ مع اختيار d3 . فقط انتظر حتى يتم دمج # 25805.

ليس ماكينة صراف آلي. سأعلمكم جميعًا إذا ومتى أفعل

العمل على # 25582 لتكون قادرًا على ختم الحزمة 5.2.0 العالمية

لدي تحديث لـ d3-hierarchy جاهز (صارم و jsDoc).
يعمل أيضًا على d3-dsv و d3-fetch (ts 2.3).

تضمين التغريدة
هل يجب التركيز على هذا أم على تحديث d3 إلى أحدث إصدار؟ نحن الآن متأخرون عن 5 إصدارات ثانوية على الحزمة العالمية (على الرغم من أن جميع الحزم الفرعية جاهزة مقابل 5.2.0 ما أعتقد). هل يجب أن أقوم بفتح إصدار منفصل لتتبع حالة الطرد العالمي؟

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

آسف لتلويث هذا الموضوع ، سأعود الآن إلى D3.js لمشروع جديد .. وكنت أتساءل عما إذا كان هناك تعليق توضيحي من TypeScript مضمّن تم اعتباره لـ D3؟

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

في حزمة الويب ، بدأوا في استخدامه للتحقق من JavaScript مع مترجم TypeScript .. Big plus هي تعريفات الكتابة الموجودة بجوار الكود الفعلي مباشرةً.
https://github.com/webpack/webpack/blob/master/lib/Compiler.js#L51

مرحبًا @ phil-lgr
كان هناك نقاش حول أداة تعقب المشكلة 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 .

شكرا