@gustavderdrache @Ledragon Arriba consolidé las pocas tareas pendientes para completar la obra que es el conjunto de definiciones D3.

Una pregunta clave: ¿Queremos actualizar todas las definiciones consistentemente a una restricción TS >=2.3 y en el proceso eliminar algunas de las sobrecargas de funciones/métodos usando asignaciones predeterminadas para genéricos?
Noté que (sin darme cuenta) algunas de las definiciones ya tienen la restricción // TypeScript Version: 2.3 en el encabezado de definiciones. Por ejemplo , d3-geo , que usa las definiciones geoJson . Estos ya utilizan valores predeterminados genéricos.

Sus opiniones sobre este asunto serían más que bienvenidas.

Entender esto hay que estudiarlo

Si implementamos un mínimo de TS 2.3, también deberíamos poder usar el tipo object en lugar de any , cuando corresponda. Vino con TS 2.2. Si no recuerdo mal, hubo un puñado de oportunidades con interpoladores de objetos y en la colección d3.

Primeros pensamientos:

• Debido al error de falta de memoria que encontró, ¿no deberíamos aplicar 2.4 en todas partes?
• Tengo una sucursal con strictNullChecks y strictFunctionTypes aquí . Lo actualizaré y enviaré un PR. Pensé que sí, pero no lo parece

Tengo que aprender sobre los genéricos predeterminados antes de tener una opinión sobre esto: p

Con TS 2.3 estamos viendo un lanzamiento de abril de 2017.
TS 2.4 se lanzó en junio de 2017.

Entonces, la gran pregunta es: ¿estamos creando problemas en una parte grande o insignificante/en ninguna parte de la base instalada al forzar un mínimo de 2.4 (en lugar de 2.3)?

Supongo que uno de los desafíos adicionales es que no tenemos un registro de cambios per se para marcar cambios potencialmente importantes en la forma en que se consumen las definiciones de D3. Y la desconexión obvia, que podría ocurrir un cambio importante en una versión menor de las definiciones, ya que están alineadas con el ciclo de publicación D3 subyacente.

@gustavderdrache ¿Cuál es su opinión sobre TS 2.4 como el nuevo mínimo?

Como se ve en PR #23654, parece que entramos en cascada rápidamente cuando vamos a TS 2.4 (incluso si solo impone la restricción por el bien de DT sin usar ninguna característica de TS 2.4 como enumeraciones de cadenas).

Para mayor claridad según el nuevo PR #23724, podemos proceder simplemente usando TS 2.3. No es necesario seguir adelante con TS 2.4 a partir de ahora.

@Ledragon Si desea abrir el PR que ya tenía pendiente en su bifurcación d3-geo local, entonces podemos trabajar para marcar las casillas anteriores.

De hecho, no puedo probarlo localmente... Así que creo que puedo enviarlo, pero no creo que pase las pruebas de Travis. Voy a seguir adelante y ver

23794 enviado - no es mi trabajo más orgulloso, veamos cómo va...

Bien, el problema es el siguiente: d3-geo las pruebas fallan en TS 2.3, así que intenté configurar la versión en 2.4. Sin embargo, d3 global está configurado en TS 2.3, por lo que tampoco funciona. ¿Algún consejo sobre cómo proceder?

Veré las relaciones públicas de g3-geo y pondré cualquier comentario de revisión allí para mantenerlos enfocados. A diferencia del error OoM que tuve con la colección d3 , tenemos un mensaje de error adecuado para trabajar 😄

Acabo de enviar #24118 para actualizar d3-contour a 1.2.0
Noté que los tipos d3-contour ya están en TS2.3 , y tienen strictNullChecks y strictFunctionTypes establecidos en verdadero :-)

Gracias por estar al tanto de d3-contour , me hizo notar que por alguna extraña razón no tenía el repositorio en "Mirando". ¡Cambió eso! :sonreír:

Veremos las relaciones públicas en breve.

Estoy trabajando en el eje d3 y el formato d3. Casi termino. Pero tengo algunas preguntas...

En formato d3 quiero usar la misma interfaz Numeric que en d3-array:

interface Numeric {
    valueOf(): number;
}

Pero al hacer esto, en las definiciones globales de d3, lógicamente tengo el error: Module 'd3-array' has already exported a member named 'Numeric'. ¿Hay algún lugar para poner tipos compartidos para las bibliotecas de d3?

También en algunas definiciones de d3 (interpolación, escala, forma) puede encontrar el tipo de unión number | { valueOf(): number } . ¿No es suficiente { valueOf(): number } ?

@denisname ¡ Gracias por ser voluntario para d3-axis , d3-format y más tarde d3-array !

A sus preguntas anteriores:

(1) Como regla fundamental para escribir las definiciones de los módulos d3-xxx , las definiciones nunca deben introducir dependencias que no existan entre los módulos D3 correspondientes subyacentes. Por ejemplo d3-axis no depende de d3-array , por lo tanto, el archivo de definición index.ts para d3-axis no debe importarse desde d3-array . Esto asegura un acoplamiento flojo correspondiente a las fuentes JS. Entonces, en caso de duda, verifique la propiedad dependencies de los package.json del módulo D3 subyacente _Nota: por supuesto, puede importar desde cualquier paquete en el archivo d3-xxx-test.ts , esto es incluso una buena práctica que seguimos en una serie de paquetes para pruebas de "integración". Es decir, puede que no haya una dependencia formal entre dos paquetes, pero los miembros de uno se usan "naturalmente" como entrada para el otro. Por ejemplo, estamos usando d3-selection en una prueba en d3-chord para garantizar que una ruta de acorde se pueda pasar a un definidor de atributos de selección sin problemas._

(2) Tiene razón, la interfaz Numeric no se puede volver a declarar en ningún otro módulo D3, que no puede importar desde d3-array de conformidad con la regla (1).

(3) ¿ { valueOf(): number } no es suficiente? Técnicamente, sí. En la práctica, el tipo de intersección, si bien tiene cierta redundancia, es declarativamente probablemente más claro para muchos usuarios humanos. Es decir, muestra que number es un tipo válido a primera vista sin acrobacias mentales. :guiño:

Acerca de d3-color, ¿por qué los prototype están todos comentados? Se ha hecho en este compromiso por @tomwanzek.

Con los prototipos retrocedidos, podríamos usar instanceof directamente, sin necesidad de una función typeguard:

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 Dudé en definir prototype como parte de la API publicada en una interfaz, se siente demasiado raro.

Por lo que entiendo de las especificaciones de guardias de tipo de hoy. Esto ahora se considera como una _construcción_ válida. Ver el elemento de la lista:

Una protección de tipo de la forma x instanceof C , donde x no es de tipo Cualquiera, C es de un subtipo del tipo global 'Función' y C tiene una propiedad denominada 'prototipo' [...]

Me gustaría proponer una versión strictNullChecks de d3-color . Que es solo un cambio de una línea. Esta sería una oportunidad para agregar prototype también.

Según mis propias pruebas, necesita la propiedad prototype o una declaración de $ new(): T para instanceof para restringir correctamente el tipo. Utilicé la variación new(): Color en las escrituras v3, y podría ser útil si esa expresión aún es compatible con D3v4 y superior.

Como cualquiera de los dos parece estar bien, creo que podríamos seguir la convención v3 para la continuidad. Gran trabajo, ambos.

@gustavderdrache

Mi comprensión de por qué funciona en d3 v3 es que el tipo de retorno de new() siempre es el mismo que el tipo prototype . Pero en d3 v4 también tenemos:

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

De hecho, d3.lab(0,0,0) instanceof d3.color es cierto. Por lo tanto, si cambiamos esta interfaz a:

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

No tenemos como prototype para ColorFactory el tipo Color . Y el siguiente código no se compila, mientras que no debería.

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

¿Cuál es tu opinión? ¿Hay alguna manera de hacer que funcione con new ? Gracias.

Parece que la propiedad prototype para color() debería ser Color y no RGBColor | HSLColor , según algunas pruebas:

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

La función color() devuelve colores RGB o HSL, pero su prototipo es un supertipo de los otros espacios de color.

@denisname @Ledragon @gustavderdrache ya que todos ustedes están en este hilo, solo como un breve FYI: tengo la intención de ponerme al día con los elementos abiertos que conocen este fin de semana.

Muy bien, d3-geo está fuera (gracias @ledragon) y comenté sobre el PR lamentablemente cerrado de @denisname por d3-format y d3-axis con respecto a la reapertura.

Como nota general, recomendaría que se agregue @denisname como otro mantenedor de las definiciones en las que trabajan.

Podría echarle un vistazo a d3-color a continuación y unirme a él con una actualización a 1.1.0 . ¿Deberíamos abrir un número separado para esta actualización?

Además, ¡bienvenido a bordo @denisname !

@Ledragon Gracias.

Tengo una actualización lista para d3-color (todavía no hay lhc ni gray ). Estoy atascado por un pequeño problema.

@gustavderdrache dijo:

La función color() devuelve colores RGB o HSL, pero su prototipo es un supertipo de los otros espacios de color.

De hecho, y esto se puede _escribir_ fácilmente, vea la primera interfaz en mi comentario . Pero @tomwanzek propuso usar solo new() y evitar prototype . Creo que en este caso particular no es posible. ¿No?...

Después de jugar con él un poco más, estoy viendo el problema. Puede configurar new(): Color en la interfaz ColorConstructor , pero en realidad no cubre el valor de retorno de la función:

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

En conclusión: creo que tenemos que exponer la propiedad prototype , porque realmente es la única forma de cubrir el comportamiento correcto tanto del constructor como de las pruebas instanceof :

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

    readonly prototype: Color; 
  }

Lo siento, por la demora en volver a esto. Siéntase libre de ir con prototype , en el pasado, fue mi primer impulso para abordar el instanceof también. Simplemente "se sintió" raro, pero como se considera una práctica aceptable, y si la continuidad con el uso new() como en D3v3 no es una opción... ¡Vamos con lo que funciona!

@tomwanzek , ¿podría actualizar la tabla de seguimiento?

Se debe establecer un ✅ en las columnas strictNullChecks strictFunctionTypes y TS 2.3 para bibliotecas d3-axis , d3-color , d3-dispatch , d3-format , d3-polygon y d3-hsv .

También se debe establecer un ✅ en la columna JSDoc para d3-dispatch , d3-polygon y d3-hsv .

Gracias

Hay un error tipográfico en la interfaz $ d3-geo GeoIdentityTranform . Debería ser GeoIdentityTransform (con s ). ¿Puedo corregirlo? ¿Alguna preocupación sobre la compatibilidad con versiones anteriores?

@denisname por d3-geo s GeoIdentityTranform , creo que podríamos hacer lo siguiente:

• Cambie el nombre de la interfaz mal escrita (¡Gran captura!) (incluido su uso como tipo de devolución de geoIdentity()
• Por el momento agregar

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

• En una etapa conveniente posterior, elimine por completo el tipo mal escrito.

@denisname 💯 @gustavderdrache @ledragon Gracias por todo el arduo trabajo durante el último tiempo. Actualicé la tabla de seguimiento, ¡ya se ve mucho más bonita! porque lo que buscamos aquí es una bonita tabla de seguimiento :smile:

porque una bonita tabla de seguimiento es lo que buscamos aquí

¡Absolutamente! Las definiciones de tipo mejoradas son solo un efecto secundario agradable.

¿Alguno de ustedes está trabajando en definiciones específicas en este momento para completar la deuda técnica? Mientras d3-array está en proceso. Abordaría el strictFunctionTypes en d3-transition a continuación para llevarlo a la paridad con d3-selection . A la espera de que se fusione #25805.

No cajero automático. Les dejaré saber si y cuando lo haga

Trabajando en #25582 para poder sellar el paquete global 5.2.0

Tengo lista una actualización para d3-hierarchy (strict y jsDoc).
También trabajando en d3-dsv y d3-fetch (ts 2.3).

@denisname @tomwanzek @gustavderdrache
¿Deberíamos centrarnos en esto o en actualizar d3 a la última versión? Ahora estamos 5 versiones menores atrasadas en el paquete global (aunque creo que todos los subpaquetes están listos para 5.2.0 ). ¿Debo abrir un problema separado para rastrear el estado global del paquete?

@Ledragon Me pondré al día con las relaciones públicas abiertas esta noche y analizaré todas las definiciones del módulo D3 para la moneda. Si hay retrasos, crearé un problema de seguimiento para que estén a la par. En cuanto a las prioridades, estoy de acuerdo en que la moneda debe tener prioridad sobre la reducción de la deuda técnica.

Perdón por contaminar este hilo, estoy volviendo a D3.js ahora para un nuevo proyecto ... y me preguntaba si se consideró tener una anotación TypeScript en línea para D3.

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

En webpack, comenzaron a usarlo para verificar JavaScript con el compilador de TypeScript. La gran ventaja es que las definiciones de escritura se encuentran junto al código real.
https://github.com/webpack/webpack/blob/master/lib/Compiler.js#L51

Hola @phil-lgr
Hubo una discusión sobre el rastreador de problemas d3 no hace mucho tiempo, y no parecía estar en la parte superior de la lista de prioridades (es decir, Mike Bostock prefirió centrarse en desarrollar la biblioteca en sí en lugar de escribir). Parece que no puedo encontrar un enlace al hilo. Tal vez la pregunta pueda volver a plantearse gracias a esta nueva información, pero no creo que sea probable que suceda.

@tomwanzek , ¿podría actualizar la tabla de seguimiento?

Se debe establecer un ✅ en las columnas strictNullChecks strictFunctionTypes y TS 2.3 para bibliotecas d3-array , d3-array , d3-dsv , d3-fetch , d3-hexbin , d3-hierarchy , d3-interpolate , d3-quadtree , d3-queue , d3-request , d3-timer y d3-voronoi .

También se debe establecer un ✅ en la columna JSDoc para d3-color , d3-hexbin , d3-hierarchy , d3-interpolate y d3-quadtree .

Gracias