@gustavderdrache @Ledragon Oben habe ich die wenigen ausstehenden Aufgaben zusammengefasst, um das Oeuvre abzurunden, nämlich die Menge der D3-Definitionen.

Eine Schlüsselfrage: Wollen wir alle Definitionen konsistent auf eine TS >=2.3-Einschränkung aktualisieren und dabei einige der Funktions-/Methodenüberladungen entfernen, indem wir Standardzuweisungen für Generika verwenden?
Mir ist aufgefallen, dass einige der Definitionen (versehentlich) bereits die Einschränkung // TypeScript Version: 2.3 im Definitionsheader haben. ZB d3-geo , das die geoJson -Definitionen verwendet. Diese verwenden bereits generische Vorgaben.

Ihre Meinung zu diesem Thema wäre mehr als willkommen.

Verstehe das, du musst es studieren

Wenn Sie mindestens TS 2.3 implementieren, sollten wir gegebenenfalls auch den Typ object anstelle von any verwenden können. Kam mit TS 2.2. Wenn ich mich richtig erinnere, gab es eine Handvoll Möglichkeiten mit Objektinterpolatoren und in der d3-Sammlung.

Erste Gedanken:

• Sollten wir aufgrund des Out-of-Memory-Fehlers, auf den Sie gestoßen sind, 2.4 nicht überall erzwingen?
• Ich habe hier einen Zweig mit strictNullChecks und strictFunctionTypes . Ich werde es aktualisieren und eine PR einreichen. Ich dachte, ich hätte es getan, aber es scheint nicht so zu sein

Ich muss mich über Standardgenerika informieren, bevor ich eine Meinung dazu habe :p

Mit TS 2.3 blicken wir auf eine Veröffentlichung von zurück im April 2017.
TS 2.4 wurde im Juni 2017 veröffentlicht.

Die große Frage ist also: Schaffen wir Probleme in einem großen oder vernachlässigbaren/keinen Teil der installierten Basis, wenn wir ein Minimum von 2.4 (statt 2.3) erzwingen?

Ich denke, eine der zusätzlichen Herausforderungen ist, dass wir per se kein Änderungsprotokoll haben, um potenziell bahnbrechende Änderungen an der Verwendung der D3-Definitionen zu kennzeichnen. Und die offensichtliche Diskrepanz, dass eine Breaking Change in einer Nebenversion der Definitionen auftreten könnte, da sie auf den zugrunde liegenden D3-Release-Zyklus ausgerichtet sind.

@gustavderdrache Was hältst du von TS 2.4 als neuem Minimum?

Wie in PR #23654 zu sehen ist, scheinen wir schnell zu kaskadieren, wenn wir zu TS 2.4 wechseln (selbst wenn es nur um der DT willen die Einschränkung auferlegt, ohne TS 2.4-Funktionen wie String-Enumerationen zu verwenden).

Zur Verdeutlichung gemäß der neuen PR #23724 können wir einfach mit TS 2.3 fortfahren. Ab sofort müssen Sie mit TS 2.4 nicht weitermachen.

@Ledragon Wenn Sie die PR öffnen möchten, die Sie bereits in Ihrem lokalen d3-geo- Fork hatten, können wir die Kästchen oben abhaken.

Ich kann es tatsächlich nicht lokal testen lassen ... Ich denke, ich kann es einreichen, aber ich glaube nicht, dass es die Travis-Tests bestehen wird. Ich werde einfach weitermachen und sehen

23794 eingereicht - nicht meine stolzeste Arbeit, mal sehen, wie es läuft ...

Okay, das Problem ist also folgendes: d3-geo -Tests schlagen in TS 2.3 fehl, also habe ich versucht, die Version auf 2.4 zu setzen. Allerdings ist d3 global auf TS 2.3 eingestellt, also geht das auch nicht. Irgendwelche Ratschläge zum weiteren Vorgehen?

Ich werde mir die PR von g3-geo ansehen und alle Bewertungskommentare dort platzieren, um sie auf dem Laufenden zu halten. Anders als bei dem OoM-Fehler, den ich mit d3-collection hatte, haben wir eine richtige Fehlermeldung, mit der wir arbeiten können 😄

Habe gerade #24118 eingereicht, um d3-contour auf 1.2.0 zu aktualisieren
Mir ist aufgefallen, dass d3-contour Typen bereits in TS2.3 sind und strictNullChecks und strictFunctionTypes auf true gesetzt sind :-)

Danke, dass Sie auf dem Laufenden über d3-contour geblieben sind. Ich habe bemerkt, dass ich aus irgendeinem Grund das Repo nicht auf "Watching" hatte. Habe das geändert! :Lächeln:

Werde mir die PR gleich anschauen.

Ich arbeite an der d3-Achse und dem d3-Format. Ich bin fast fertig. Habe aber ein paar Fragen...

Im d3-Format möchte ich dieselbe Numeric -Schnittstelle verwenden wie im d3-Array:

interface Numeric {
    valueOf(): number;
}

Aber wenn ich das tue, habe ich in den globalen d3-Definitionen logischerweise den Fehler: Module 'd3-array' has already exported a member named 'Numeric'. Gibt es einen Ort, an dem gemeinsam genutzte Typen für d3-Bibliotheken abgelegt werden können?

Auch in einigen d3-Definitionen (interpolate, scale, shape) findet man den union type number | { valueOf(): number } . Ist { valueOf(): number } nicht genug?

@denisname Vielen Dank für Ihre Freiwilligenarbeit für d3-axis , d3-format und später d3-array !!!

Zu deinen obigen Fragen:

(1) Als Grundregel für das Schreiben der Definitionen für d3-xxx -Module dürfen die Definitionen niemals Abhängigkeiten einführen, die nicht zwischen den zugrunde liegenden entsprechenden D3-Modulen bestehen. Beispiel: d3-axis hat keine Abhängigkeit von d3-array , daher darf die Definitionsdatei index.ts für d3-axis nicht aus d3-array importiert werden. Dies stellt eine lockere Kopplung entsprechend den JS-Quellen sicher. Überprüfen Sie also im Zweifelsfall die dependencies -Eigenschaft des zugrunde liegenden D3-Moduls package.json _Hinweis: Sie können natürlich aus jedem Paket in die d3-xxx-test.ts -Datei importieren, dies ist sogar eine gute Praxis, die wir in einer Reihe von Paketen für "Integrations"-Tests befolgt haben. Dh es darf keine formale Abhängigkeit zwischen zwei Paketen geben, aber Mitglieder des einen werden "natürlich" als Input für das andere verwendet. Beispielsweise verwenden wir d3-selection in einem Test in d3-chord , um sicherzustellen, dass ein Akkordpfad problemlos an einen Auswahlattribut-Setter übergeben werden kann._

(2) Sie haben Recht, dass die Schnittstelle Numeric in keinem anderen D3-Modul neu deklariert werden kann, das nicht gemäß Regel (1) aus d3-array importieren kann.

(3) Sind { valueOf(): number } nicht genug? Technisch ja. In der Praxis ist der Schnittpunkttyp, obwohl er eine gewisse Redundanz aufweist, für viele menschliche Benutzer deklarativ wahrscheinlich klarer. Dh es zeigt, dass number ohne Kopfakrobatik auf den ersten Blick ein gültiger Typ ist. :zwinkern:

Über d3-Farbe, warum sind die prototype alle auskommentiert? Dies wurde in diesem Commit von @tomwanzek durchgeführt.

Mit den zurückgesetzten Prototypen könnten wir instanceof direkt verwenden, ohne dass eine Typeguard-Funktion erforderlich wäre:

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 Ich habe gezögert, prototype als Teil der veröffentlichten API in einer Schnittstelle zu definieren, es fühlt sich zu hackig an.

Für das, was ich aus der heutigen Type Guards-Spezifikation verstehe. Dies wird jetzt als gültige _Konstruktion_ betrachtet. Siehe Listenelement:

Ein Typwächter der Form x instanceof C , wobei x nicht vom Typ Any ist, C ein Untertyp des globalen Typs 'Function' ist und C eine Eigenschaft namens hat 'Prototyp' [...]

Ich möchte eine strictNullChecks Version von d3-color vorschlagen. Das ist nur eine Zeilenänderung. Dies wäre eine Gelegenheit, auch prototype hinzuzufügen.

Nach meinen eigenen Tests benötigen Sie entweder die prototype -Eigenschaft oder eine new(): T -Deklaration für instanceof , um den Typ richtig einzugrenzen. Ich habe die new(): Color -Variante in den v3-Typisierungen verwendet, und es könnte nützlich sein, wenn diese Redewendung noch von D3v4 und höher unterstützt wird.

Da beide in Ordnung zu sein scheinen, denke ich, dass wir der v3-Konvention für Kontinuität folgen könnten. Tolle Arbeit, beides.

@gustavderdrache

Mein Verständnis dafür, warum es in d3 v3 funktioniert, ist, dass der Rückgabetyp von new() immer derselbe ist wie der Typ von $ prototype . Aber in d3 v4 haben wir auch:

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

In der Tat ist d3.lab(0,0,0) instanceof d3.color wahr. Wenn wir also diese Schnittstelle ändern in:

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

Wir haben nicht als prototype für ColorFactory den Typ Color . Und der folgende Code kann nicht kompiliert werden, obwohl er das nicht sollte.

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`
}

Was ist deine Meinung? Gibt es eine Möglichkeit, es mit new zum Laufen zu bringen? Danke.

Basierend auf einigen Tests sieht es so aus, als ob die Eigenschaft prototype für color() Color und nicht RGBColor | HSLColor sein sollte:

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

Die Funktion color() gibt RGB- oder HSL-Farben zurück, aber ihr Prototyp ist ein Supertyp der anderen Farbräume.

@denisname @Ledragon @gustavderdrache Da Sie alle in diesem Thread sind, nur als kurze Info: Ich beabsichtige, mich an diesem Wochenende über die offenen Punkte zu informieren, die Ihnen bekannt sind.

In Ordnung, d3-geo ist aus der Tür (danke @ledragon) und ich habe die leider geschlossene PR von @denisname für d3-format und d3-axis bezüglich der Wiedereröffnung kommentiert.

Als allgemeine Anmerkung würde ich empfehlen, @denisname als weiteren Betreuer zu den Definitionen hinzuzufügen, an denen sie arbeiten.

Ich könnte mir als nächstes d3-color ansehen und mit einem Update auf 1.1.0 dazukommen . Sollten wir für dieses Upgrade ein separates Problem eröffnen?

Willkommen an Bord @denisname !

@Ledragon Danke.

Ich habe ein Update für d3-color bereit (noch kein lhc und gray ). Ich hänge nur an einem kleinen Problem.

@gustavderdrache sagte:

Die Funktion color() gibt RGB- oder HSL-Farben zurück, aber ihr Prototyp ist ein Supertyp der anderen Farbräume.

In der Tat, und dies kann leicht _getippt_ werden, siehe die erste Schnittstelle in meinem Kommentar . Aber @tomwanzek schlug vor, nur new() zu verwenden und prototype zu vermeiden. Ich denke, dass dies in diesem speziellen Fall nicht möglich ist. Nein?...

Nachdem ich noch etwas damit herumgespielt habe, sehe ich das Problem. Sie können new(): Color in der Schnittstelle ColorConstructor setzen, aber es deckt nicht wirklich den Rückgabewert der Funktion ab:

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;
}

Abschließend: Ich denke, wir müssen die Eigenschaft prototype verfügbar machen, da dies wirklich die einzige Möglichkeit ist, das korrekte Verhalten sowohl des Konstruktors als auch des Testens instanceof abzudecken:

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

    readonly prototype: Color; 
  }

Sorry, für die Verspätung, darauf zurückzukommen. Fühlen Sie sich frei, mit prototype zu gehen, damals war es mein erster Impuls, auch das instanceof anzusprechen. Es fühlte sich einfach "hacky" an, aber da es als akzeptable Praxis angesehen wird, und wenn Kontinuität mit der Verwendung new() wie in D3v3 keine Option ist ... Lassen Sie uns mit dem weitermachen, was funktioniert!

@tomwanzek könnten Sie die Tracking-Tabelle aktualisieren.

In den Spalten strictNullChecks strictFunctionTypes und TS 2.3 sollte für die Bibliotheken d3-axis , d3-color , d3-dispatch , d3-format ein ✅ gesetzt werden d3-polygon und d3-hsv .

Außerdem sollte in Spalte JSDoc für d3-dispatch , d3-polygon und d3-hsv ein ✅ gesetzt werden.

Danke

Es gibt einen Tippfehler in der d3-geo Schnittstelle GeoIdentityTranform . Es sollte GeoIdentityTransform sein (mit einem s ). Darf ich es korrigieren? Haben Sie Bedenken hinsichtlich der Abwärtskompatibilität?

@denisname für d3-geo s GeoIdentityTranform , ich denke, wir könnten Folgendes tun:

• Benennen Sie die falsch geschriebene Schnittstelle um (Toller Fang!) (einschließlich ihrer Verwendung als Rückgabetyp von geoIdentity()
• Vorerst hinzufügen

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

• Entfernen Sie zu einem späteren Zeitpunkt den falsch geschriebenen Typ vollständig.

@denisname 💯 @gustavderdrache @ledragon Danke für all die harte Arbeit in der letzten kleinen Weile. Ich habe die Tracking-Tabelle aktualisiert, sieht schon so viel hübscher aus! Denn eine hübsche Tracking-Tabelle ist das, was wir hier anstreben :smile:

Denn eine hübsche Tracking-Tabelle ist das, was wir hier anstreben

Absolut! Die verbesserten Typdefinitionen sind nur ein angenehmer Nebeneffekt.

Arbeitet jemand von Ihnen gerade an konkreten Definitionen zur Vervollständigung der technischen Schulden? Während d3-Array in Bearbeitung ist. Ich würde als nächstes den strictFunctionTypes in d3-Übergang angehen, um ihn mit d3-Auswahl gleichzusetzen . Ich warte nur darauf, dass #25805 zusammengeführt wird.

Nicht jetzt. Werde euch alle wissen lassen, ob und wann ich es tue

Arbeiten an #25582, um das 5.2.0 Global Bundle stempeln zu können

Ich habe ein Update für d3-hierarchy bereit (strict und jsDoc).
Arbeitet auch an d3-dsv und d3-fetch (ts 2.3).

@denisname @tomwanzek @gustavderdrache
Sollten wir uns darauf konzentrieren oder auf die Aktualisierung von d3 auf die neueste Version? Wir sind jetzt 5 Nebenversionen hinter dem globalen Paket zurück (obwohl alle Unterpakete für 5.2.0 bereit sind, denke ich). Soll ich ein separates Problem eröffnen, um den globalen Paketstatus zu verfolgen?

@Ledragon Ich werde heute Abend die offenen PRs einholen und alle D3-Moduldefinitionen auf Währung analysieren. Wenn es Verzögerungen gibt, werde ich ein Tracking-Problem erstellen, um sie auf den neuesten Stand zu bringen. Was die Prioritäten betrifft, stimme ich zu, dass die Währung Vorrang vor dem technischen Schuldenabbau haben sollte.

Tut mir leid, diesen Thread zu verschmutzen, ich steige jetzt für ein neues Projekt wieder in D3.js ein. Und ich habe mich gefragt, ob eine Inline-TypeScript-Anmerkung für D3 in Betracht gezogen wurde?

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

Im Webpack begannen sie damit, JavaScript mit dem TypeScript-Compiler zu überprüfen. Ein großes Plus ist, dass die Typing-Definitionen direkt neben dem eigentlichen Code live sind.
https://github.com/webpack/webpack/blob/master/lib/Compiler.js#L51

Hallo @phil-lgr
Vor nicht allzu langer Zeit gab es eine Diskussion über den d3 Issue Tracker, und es schien nicht ganz oben auf der Prioritätenliste zu stehen (dh Mike Bostock zog es vor, sich auf die Entwicklung der Bibliothek selbst zu konzentrieren, anstatt auf Typisierungen). Irgendwie finde ich keinen Link zu dem Thread. Vielleicht kann die Frage dank dieser neuen Informationen erneut gestellt werden, aber ich halte es nicht für wahrscheinlich, dass dies geschieht

@tomwanzek könnten Sie die Tracking-Tabelle aktualisieren.

In den Spalten strictNullChecks strictFunctionTypes und TS 2.3 sollte für die Bibliotheken d3-array , d3-array , d3-dsv , d3-fetch ein ✅ gesetzt werden d3-hexbin , d3-hierarchy , d3-interpolate , d3-quadtree , d3-queue , d3-request , d3-timer und d3-voronoi .

Außerdem sollte in Spalte JSDoc für d3-color , d3-hexbin , d3-hierarchy , d3-interpolate und d3-quadtree ein ✅ gesetzt werden.

Danke