@gustavderdrache @Ledragon 위에서 D3 정의 세트인 작품을 마무리하기 위해 몇 가지 미해결 작업을 통합했습니다.

핵심 질문: 모든 정의를 TS >=2.3 제약 조건으로 일관되게 업그레이드하고 그 과정에서 제네릭에 대한 기본 할당을 사용하여 일부 기능/메서드 오버로드를 제거하시겠습니까?
(실수로) 일부 정의에는 이미 정의 헤더에 // TypeScript Version: 2.3 제약 조건이 있는 것으로 나타났습니다. 예: geoJson 정의를 사용하는 d3-geo . 이들은 이미 일반 기본값을 사용합니다.

이 문제에 대한 귀하의 생각은 무엇보다 환영할 것입니다.

이것을 이해하고 공부해야합니다

최소 TS 2.3을 구현하는 경우 적절한 경우 any 대신 object 유형을 사용할 수도 있습니다. TS 2.2와 함께 제공됩니다. 제 기억이 맞다면 개체 보간기와 d3-collection에 몇 가지 기회가 있었습니다.

첫 번째 생각:

• 메모리 부족 버그로 인해 모든 곳에서 2.4를 시행해야 하지 않습니까?
• 여기에 strictNullChecks 및 strictFunctionTypes 가 있는 지점이 있습니다 . 업데이트하여 PR을 제출하겠습니다. 하는 줄 알았는데 아닌 것 같다

이에 대한 의견이 있기 전에 기본 제네릭에 대해 배워야 합니다.p

TS 2.3과 함께 우리는 2017년 4월의 릴리스를 기다리고 있습니다.
TS 2.4는 2017년 6월에 릴리스되었습니다.

따라서 가장 큰 질문은 다음과 같습니다. 최소 2.4(2.3이 아닌)를 강제 적용할 때 설치 기반의 일부 또는 무시할 수 있는 부분에 문제가 발생합니까?

추가된 과제 중 하나는 D3 정의가 사용되는 방식에 대한 잠재적인 주요 변경 사항에 플래그를 지정하는 변경 로그 자체가 없다는 것입니다. 그리고 기본 D3 릴리스 주기와 정렬되어 있기 때문에 정의의 마이너 버전 릴리스에서 주요 변경 사항이 발생할 수 있다는 명백한 단절이 있습니다.

@gustavderdrache 새로운 최소 사양으로 TS 2.4에 대해 어떻게 생각하십니까?

PR #23654에서 볼 수 있듯이 TS 2.4로 이동할 때 빠르게 캐스케이드하는 것처럼 보입니다(문자열 열거형과 같은 TS 2.4 기능을 사용하지 않고 DT를 위해 제약 조건을 부과하는 경우에도).

새로운 PR #23724에 따라 명확성을 위해 TS 2.3을 사용하여 진행할 수 있습니다. 현재로서는 TS 2.4를 추진할 필요가 없습니다.

@Ledragon 로컬 d3-geo 포크에서 이미 보류 중인 PR을 열려면 위의 확인란을 선택하여 작업할 수 있습니다.

실제로 로컬에서 테스트를 할 수는 없습니다... 그래서 제출할 수 있을 것 같지만 트래비스 테스트를 통과할 것 같지는 않습니다. 그냥 가서 볼게

23794 제출됨 - 내 가장 자랑스러운 작업이 아닙니다. 어떻게 진행되는지 봅시다...

자, 문제는 다음과 같습니다. d3-geo 테스트는 TS 2.3에서 실패했습니다. 그래서 버전을 2.4로 설정해 보았습니다. 그러나 d3 global은 TS 2.3으로 설정되어 있어서 이것도 작동하지 않습니다. 진행 방법에 대한 조언이 있습니까?

나는 g3-geo PR을 살펴보고 그들이 집중할 수 있도록 리뷰 코멘트를 거기에 둘 것입니다. d3-collection 에서 가지고 있었던 OoM 버그와 달리, 우리는 작업할 적절한 오류 메시지가 있습니다 😄

d3-contour 를 1.2.0으로 업데이트하기 위해 #24118을 방금 제출했습니다.
d3-contour 유형이 이미 TS2.3 에 있고 strictNullChecks 및 strictFunctionTypes 가 true로 설정되어 있음을 알았습니다 :-)

d3-contour 위에 머물러 주셔서 감사합니다. 이상한 이유로 "Watching"에 대한 리포지토리가 없다는 것을 알게되었습니다. 변경했습니다! :웃다:

곧 PR을 볼 것입니다.

저는 d3축 및 d3 형식에서 작업하고 있습니다. 거의 끝났어요. 하지만 질문이 좀...

d3 형식에서는 d3 배열에서와 동일한 Numeric 인터페이스를 사용하고 싶습니다.

interface Numeric {
    valueOf(): number;
}

그러나 이것을 할 때 d3 전역 정의에서 논리적으로 오류가 발생합니다. Module 'd3-array' has already exported a member named 'Numeric'. d3 라이브러리에 대한 공유 유형을 넣을 장소가 있습니까?

또한 일부 d3 정의(interpolate, scale, shape)에서 통합 유형 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 에서 가져오지 않아야 합니다. 이것은 JS 소스에 해당하는 느슨한 결합을 보장합니다. 따라서 의심스러운 경우 기본 D3 모듈 package.json 의 dependencies 속성을 확인하십시오. _참고: 물론 d3-xxx-test.ts 파일의 모든 패키지에서 가져올 수 있습니다. 우리는 "통합" 테스트를 위해 여러 패키지에서 따랐습니다. 즉, 두 패키지 사이에 형식적인 종속성이 없을 수 있지만 하나의 멤버는 "자연스럽게" 다른 패키지에 대한 입력으로 사용됩니다. 예를 들어 코드 경로가 문제 없이 선택 속성 설정기로 전달될 수 있도록 d3-chord d3-selection 사용하고 있습니다._

(2) Numeric 인터페이스는 규칙 (1)에 따라 d3-array 에서 가져올 수 없는 다른 D3 모듈에서 다시 선언할 수 없습니다.

(3) { valueOf(): number } 가 부족합니까? 기술적으로 그렇습니다. 실제로, 교차 유형은 약간의 중복성이 있지만 많은 인간 사용자에게 선언적으로 더 명확할 것입니다. 즉, number 는 정신 곡예 없이 언뜻 보기에 유효한 유형임을 보여줍니다. :눈짓:

d3-color에 대해 prototype 가 모두 주석 처리된 이유는 무엇입니까? @tomwanzek가 이 커밋 에서 수행했습니다.

프로토타입을 다시 설정하면 typeguard 기능 없이 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 인터페이스에 게시된 API의 일부로 prototype 를 정의하는 것을 주저했습니다. 너무 해킹된 것 같습니다.

오늘의 type Guards spec 에서 내가 이해한 것은 . 이것은 이제 유효한 _건설_으로 간주됩니다. 목록 항목을 참조하십시오.

x instanceof C 형식의 유형 가드, 여기서 x는 Any 유형이 아니고, C 는 전역 유형 'Function'의 하위 유형이며, C 에는 다음과 같은 속성이 있습니다. '프로토타입' [...]

d3-color 의 strictNullChecks 버전을 제안하고 싶습니다. 단 한 줄의 변경 사항입니다. prototype 도 추가할 수 있는 기회입니다.

내 테스트에서 $# instanceof 에 대한 prototype 속성이나 new(): T 선언이 필요하여 유형을 적절하게 좁힐 수 있습니다. 나는 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;
}

ColorFactory 유형 Color 에는 $#$ prototype $#$ 가 없습니다. 그리고 다음 코드는 컴파일에 실패하지만 그렇게 해서는 안 됩니다.

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 와 함께 작동하도록 하는 방법이 있습니까? 감사 해요.

일부 테스트에 따르면 color() 에 대한 prototype 속성은 $#$ RGBColor | HSLColor Color $여야 합니다.

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

color() 함수는 RGB 또는 HSL 색상을 반환하지만 해당 프로토타입은 다른 색상 공간의 상위 유형입니다.

@denisname @Ledragon @gustavderdrache 여러분이 이 스레드에 모두 참여하고 있기 때문에 간략한 참고용으로: 이번 주말에 여러분이 알고 있는 공개 항목을 따라잡을 생각입니다.

자, d3-geo가 문 밖에 있습니다(@ledragon에게 감사드립니다). @denisname 의 불행히도 d3-format 및 d3-axis 에 대한 폐쇄된 PR에 대해 언급했습니다.

일반적으로 @denisname 을 정의에 대한 다른 유지 관리자로 추가하는 것이 좋습니다.

다음에 d3-color 를 살펴보고 1.1.0 으로 업데이트하여 합류할 수 있습니다. 이 업그레이드에 대해 별도의 문제를 열어야 합니까?

또한 @denisname 에 오신 것을 환영합니다!

@Ledragon 감사합니다.

d3-color 에 대한 업데이트가 준비되어 있습니다( lhc 및 gray 는 아직 없음). 나는 단지 하나의 작은 문제로 막혔습니다.

@gustavderdrache 는 다음과 같이 말했습니다.

color() 함수는 RGB 또는 HSL 색상을 반환하지만 해당 프로토타입은 다른 색상 공간의 상위 유형입니다.

실제로 이것은 쉽게 _typed_할 수 있습니다. 내 의견 의 첫 번째 인터페이스를 참조하십시오. 그러나 @tomwanzek 은 new() 만 사용하고 prototype 는 피하도록 제안 했습니다. 이 특별한 경우에는 불가능하다고 생각합니다. 아니요?...

좀 더 가지고 놀고 나면 문제가 보입니다. ColorConstructor 인터페이스에서 new(): Color 를 설정할 수 있지만 실제로는 함수의 반환 값을 다루지 않습니다.

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 도 다루려는 첫 번째 충동이었습니다. 그냥 "느낌"이 났지만 허용 가능한 관행으로 간주되고 D3v3에서와 같이 new() 를 계속 사용하는 것이 옵션이 아닌 경우...효과가 있는 것으로 가자!

@tomwanzek 에서 추적 테이블을 업데이트할 수 있습니다.

d3-axis , d3-color , d3-dispatch , d3-format 라이브러리의 경우 $ strictNullChecks strictFunctionTypes 및 TS 2.3 열에 ✅를 설정해야 합니다. d3-format , d3-polygon 및 d3-hsv .

또한 d3-dispatch , d3-polygon 및 d3-hsv $ 에 대해 $ JSDoc 열에 ✅ 를 설정해야 합니다.

감사 해요

d3-geo 인터페이스 GeoIdentityTranform 에 오타가 있습니다. GeoIdentityTransform ( s 포함)여야 합니다. 수정해도 될까요? 이전 버전과의 호환성에 대한 우려 사항이 있습니까?

@denisname for d3-geo s GeoIdentityTranform , 다음을 수행할 수 있다고 생각합니다.

• 철자가 틀린 인터페이스의 이름을 바꾸십시오(Great catch!)( geoIdentity() 의 반환 유형으로 사용 포함)
• 당분간 추가

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

• 나중에 편리한 단계에서 철자가 틀린 유형을 모두 제거하십시오.

@denisname 💯 @gustavderdrache @ledragon 지난 짧은 시간 동안 모든 수고에 감사드립니다. 추적 테이블을 업데이트했는데 벌써 훨씬 더 예뻐요! 예쁜 추적 테이블이 우리가 여기서 목표로 하는 것이기 때문입니다 :스마일:

예쁜 추적 테이블이 우리가 여기서 목표로 하는 것이기 때문에

전적으로! 개선된 유형 정의는 즐거운 부작용일 뿐입니다.

기술 부채의 완성을 위해 지금 구체적인 정의를 내리고 있는 사람이 있습니까? d3-array 가 진행되는 동안. 나는 strictFunctionTypes in d3-transition 을 처리하고 d3-selection 과 패리티로 가져옵니다. #25805가 병합되기를 기다리고 있습니다.

ATM이 아닙니다. 내가 하면 언제 하는지 모두 알려줄게

5.2.0 글로벌 번들에 스탬프를 찍을 수 있도록 #25582 작업 중

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에서 TypeScript 컴파일러로 JavaScript를 확인하는 데 사용하기 시작했습니다. 큰 장점은 실제 코드 바로 옆에 타이핑 정의가 있다는 것입니다.
https://github.com/webpack/webpack/blob/master/lib/Compiler.js#L51

안녕하세요 @phil-lgr입니다.
얼마 전에 d3 이슈 트래커에 대한 토론이 있었고 우선 순위 목록의 맨 위에 있는 것 같지 않았습니다(예: Mike Bostock은 타이핑보다 라이브러리 자체 개발에 집중하는 것을 선호했습니다). 스레드에 대한 링크를 찾을 수 없는 것 같습니다. 이 새로운 정보 덕분에 다시 질문이 제기될 수 있겠지만 그럴 가능성은 없다고 생각합니다.

@tomwanzek 에서 추적 테이블을 업데이트할 수 있습니다.

d3-array , d3-array , d3-dsv , d3-fetch 라이브러리의 경우 $ strictNullChecks strictFunctionTypes 및 TS 2.3 열에 ✅를 설정해야 합니다. d3-fetch , d3-hexbin , d3-hierarchy , d3-interpolate , d3-quadtree , d3-queue , d3-request , d3-timer 및 d3-voronoi .

또한 d3-color , d3-hexbin , d3-hierarchy , d3-interpolate 및 d3-quadtree $ 에 대해 $ JSDoc 열에 ✅ 를 설정해야 합니다.

감사 해요