@gustavderdrache @Ledragon Выше я объединил несколько невыполненных задач в раунд творчества, который представляет собой набор определений D3.

Ключевой вопрос: хотим ли мы последовательно обновить все определения до ограничения TS >=2.3 и в процессе удалить некоторые из перегруженных функций/методов, используя назначения по умолчанию для дженериков?
Я заметил, что (непреднамеренно) некоторые определения уже имеют ограничение // TypeScript Version: 2.3 в заголовке определений. Например, d3-geo , который использует определения geoJson . Они уже используют общие значения по умолчанию.

Ваши мысли по этому поводу будут более чем кстати.

Поймите это, вы должны изучить это

При реализации минимума TS 2.3 мы также должны иметь возможность использовать тип object вместо any , где это уместно. Пришел с ТС 2.2. Если я правильно помню, было несколько возможностей с объектными интерполяторами и в d3-коллекции.

Первые мысли:

• Из-за ошибки нехватки памяти, с которой вы столкнулись, не должны ли мы повсеместно применять 2.4?
• У меня есть ветка с strictNullChecks и strictFunctionTypes здесь . Я обновлю его и отправлю PR. Я думал, что сделал, но это не так

Я должен узнать о дженериках по умолчанию, прежде чем у меня будет мнение по этому поводу: p

Что касается 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 , мы можем поработать, чтобы отметить флажки выше.

На самом деле я не могу протестировать его локально... Поэтому я думаю, что могу отправить его, но я не думаю, что он пройдет тесты travis. Я просто пойду и посмотрю

23794 отправлено - не самая моя гордая работа, посмотрим, как пойдет...

Итак, проблема в следующем: тесты d3-geo не проходят в TS 2.3, поэтому я попытался установить версию 2.4. Однако для d3 global установлено значение TS 2.3, так что это тоже не работает. Любые советы о том, как действовать?

Я посмотрю на g3-geo PR и буду помещать туда любые обзорные комментарии, чтобы они были сосредоточены. В отличие от ошибки OoM, которая была у меня с d3-collection , у нас есть правильное сообщение об ошибке, с которым можно работать 😄

Только что отправлено #24118 для обновления d3-contour до 1.2.0
Я заметил, что типы d3-contour уже находятся в TS2.3 , а для strictNullChecks и strictFunctionTypes установлено значение true :-)

Спасибо, что остаетесь в курсе d3-contour , я заметил, что по какой-то странной причине у меня не было репозитория «Наблюдение». Изменил это! :улыбка:

Скоро посмотрю PR.

Я работаю с осью d3 и форматом d3. Я почти закончил. Но есть вопросы...

В формате 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 как часть опубликованного API в интерфейсе, это кажется слишком хакерским.

Насколько я понял из сегодняшней спецификации типа охранников . Теперь это считается допустимой _конструкцией_. См. элемент списка:

Защита типа вида x instanceof C , где x не относится к типу Any, C относится к подтипу глобального типа «Функция», а C имеет свойство с именем 'прототип' [...]

Я хотел бы предложить strictNullChecks версию d3-color . Это всего лишь изменение одной строки. Это также будет возможность добавить prototype .

Из моего собственного тестирования вам нужно либо свойство prototype , либо объявление new(): T для instanceof , чтобы правильно сузить тип. Я использовал вариацию new(): Color в типизациях v3, и может быть полезно, если эта идиома все еще поддерживается 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 , так как вы все присутствуете в этой ветке, короткое сообщение для вашего сведения: я намерен наверстать упущенное по открытым вопросам, о которых вы знаете, на этих выходных.

Хорошо, d3-geo вышел (спасибо @ledragon), и я прокомментировал, к сожалению, закрытый PR @denisname за d3-format и d3-axis относительно повторного открытия.

В качестве общего замечания, я бы порекомендовал добавить @denisname в качестве еще одного сопровождающего к определениям, над которыми они работают.

В следующий раз я мог бы взглянуть на d3-color и присоединиться к нему с обновлением до 1.1.0 . Должны ли мы открыть отдельную тему для этого обновления?

Кроме того, добро пожаловать на борт @denisname !

@Ледрагон Спасибо.

У меня есть готовое обновление для d3-color (пока нет lhc и gray ). Я просто застрял в одной маленькой проблеме.

@gustavderdrache сказал:

Функция color() возвращает цвета RGB или HSL, но ее прототип является супертипом других цветовых пространств.

Действительно, и это можно легко _типировать_, см. первый интерфейс в моем комментарии . Но @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 for d3-geo s GeoIdentityTranform , я думаю, мы могли бы сделать следующее:

• Переименуйте интерфейс с ошибкой (Отличный улов!) (включая его использование в качестве возвращаемого типа geoIdentity()
• А пока добавить

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

• На более позднем удобном этапе полностью удалите текст с ошибкой.

@denisname 💯 @gustavderdrache @ledragon Спасибо за всю тяжелую работу за последнее время. Обновил таблицу отслеживания, стало намного красивее! потому что мы стремимся к красивой таблице отслеживания :smile:

потому что мы стремимся к красивой таблице отслеживания

Абсолютно! Улучшенные определения типов — это просто приятный побочный эффект.

Кто-нибудь из вас работает над конкретными определениями прямо сейчас для завершения технического долга? Пока d3-массив находится в процессе. Я бы взялся за strictFunctionTypes в d3-transition рядом, чтобы привести его к паритету с d3-selection . Просто жду, когда # 25805 будет объединен.

Не банкомат. Дам вам знать, если и когда я это сделаю

Работаем над #25582, чтобы иметь возможность штамповать глобальный пакет 5.2.0.

У меня готово обновление для d3-hierarchy (strict и jsDoc).
Также работаю над d3-dsv и d3-fetch (ts 2.3).

@denisname @tomwanzek @gustavderdrache
Должны ли мы сосредоточиться на этом или на обновлении d3 до последней версии? Сейчас мы отстаем от глобального пакета на 5 младших версий (хотя все подпакеты готовы за 5.2.0 , я думаю). Мне открыть отдельную тему для отслеживания глобального статуса посылки?

@Ledragon Сегодня вечером я догоню открытые PR и проанализирую все определения модулей D3 на наличие валюты. Если есть какие-то лаги, я создам одну задачу отслеживания, чтобы привести их в норму. Что касается приоритетов, я согласен с тем, что валюта должна иметь приоритет над сокращением технического долга.

Извините, что засоряю эту ветку, сейчас я возвращаюсь к D3.js для нового проекта ... и мне было интересно, рассматривается ли возможность наличия встроенной аннотации TypeScript для D3?

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

В webpack они начали использовать его для проверки JavaScript с помощью компилятора TypeScript. Большой плюс в том, что определения типизации живут прямо рядом с фактическим кодом.
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 .

Спасибо