구문이 여기에서 논쟁의 여지가 있다고 제안합니다. TypeScript는 이제 합집합 유형에 대한 선행 파이프를 허용합니다.

class B {}

type A = | number | 
B

자동 세미콜론 삽입 덕분에 지금 컴파일되고 type A = number | B 와 동일합니다.

정확한 유형이 도입되면 이것이 예상되지 않을 수 있다고 생각합니다.

실제인지 확실하지 않지만 참고로 https://github.com/Microsoft/TypeScript/issues/7481

{| ... |} 구문이 채택된 경우 매핑된 유형을 기반으로 작성하여 다음을 작성할 수 있습니다.

type Exact<T> = {|
    [P in keyof T]: P[T]
|}

Exact<User> 작성할 수 있습니다.

이것은 TypeScript와 비교하여 Flow에서 내가 놓친 마지막 것입니다.

Object.assign 예제가 특히 좋습니다. TypeScript가 오늘날과 같은 방식으로 작동하는 이유를 이해하지만 대부분의 경우 정확한 유형을 사용하는 것이 좋습니다.

@HerringtonDarkholme 감사합니다. 내 초기 문제는 그것을 언급했지만 누군가가 어쨌든 더 나은 구문을 가질 것이기 때문에 결국 생략했습니다.

@DanielRosenwass 훨씬 더 합리적으로 보입니다. 감사합니다!

@wallverb 나는 그렇게 생각하지 않지만, 그 기능이 존재하는 것도 보고 싶습니다 😄

일부는 정확하고 일부는 정확하지 않은 유형의 합집합을 표현하려면 어떻게 해야 합니까? 제안된 구문은 공백에 대해 특별히 주의를 기울이더라도 오류가 발생하기 쉽고 읽기 어렵게 만듭니다.

|Type1| | |Type2| | Type3 | |Type4| | Type5 | |Type6|

노동 조합의 어떤 구성원이 정확하지 않은지 빨리 알 수 있습니까?

그리고 조심스럽게 간격을 두지 않으면?

|Type1|||Type2||Type3||Type4||Type5||Type6|

(답변: Type3 , Type5 )

@rotemdan 위의 답변을 참조하십시오. 대신 제네릭 유형 Extact 이 있습니다. 이는 제 것보다 더 견고한 제안입니다. 이것이 선호되는 접근 방식이라고 생각합니다.

편집기 힌트, 미리보기 팝업 및 컴파일러 메시지에서 어떻게 보일지에 대한 우려도 있습니다. 유형 별칭은 현재 원시 유형 표현식으로 "평평화"합니다. 별칭은 보존되지 않으므로 이에 대응하기 위해 몇 가지 특별한 조치가 적용되지 않는 한 이해할 수 없는 표현이 편집기에 계속 나타납니다.

Typescript와 동일한 구문을 사용하는 공용체를 갖고 있는 Flow와 같은 프로그래밍 언어에 이 구문이 수용되었다는 것이 믿기지 않습니다. 나에게 기존 구문과 근본적으로 충돌하는 결함 있는 구문을 도입한 다음 그것을 "덮기" 위해 매우 열심히 노력하는 것은 현명하지 않은 것 같습니다.

흥미로운 (재미있는?) 대안 중 하나는 only 와 같은 수정자를 사용하는 것입니다. 몇 달 전에 이에 대한 제안 초안이 있었던 것 같은데 제출한 적이 없습니다.

function test(a: only string, b: only User) {};

그것은 당시 내가 찾을 수 있는 최고의 구문이었습니다.

_Edit_: just 도 작동할까요?

function test(a: just string, b: just User) {};

_(편집: 이제 구문이 원래 명목 유형에 대한 수정자를 위한 것이지만 실제로는 중요하지 않은 것 같습니다. 두 개념은 충분히 가깝기 때문에 이 키워드도 여기에서 작동할 수 있습니다)_

두 키워드 모두 약간 다른 두 가지 유형의 일치를 설명하기 위해 도입될 수 있는지 궁금합니다.

• just T (의미: "정확히 T ")는 여기에 설명된 대로 정확한 구조적 일치를 위한 것입니다.
• only T (의미: "고유하게 T ") 명목 일치.

명목상 일치는 정확한 구조 일치의 "더 엄격한" 버전으로 볼 수 있습니다. 이는 유형이 구조적으로 동일해야 할 뿐만 아니라 값 자체가 지정된 것과 정확히 동일한 유형 식별자와 연관되어야 함을 의미합니다. 이것은 인터페이스 및 클래스 외에도 유형 별칭을 지원하거나 지원하지 않을 수 있습니다.

only 와 같은 명목 수식어의 개념이 적절한지 판단하는 것은 Typescript 팀의 몫이라고 생각하지만 개인적으로 미묘한 차이가 그렇게 많은 혼란을 야기할 것이라고 생각하지 않습니다. 나는 이것을 옵션으로 제안할 뿐입니다.

_(편집: 클래스와 함께 사용할 때 only 에 대한 참고 사항: 기본 클래스가 참조될 때 명목 하위 클래스를 허용할지 여부에 대한 모호성이 있습니다. 이는 별도로 논의해야 합니다. 낮은 정도 - 인터페이스에 대해서도 동일하게 고려할 수 있음 - 현재로서는 그렇게 유용할 것이라고 생각하지 않지만)_

이것은 일종의 변장된 뺄셈 유형처럼 보입니다. 다음 문제는 관련이 있을 수 있습니다. https://github.com/Microsoft/TypeScript/issues/4183 https://github.com/Microsoft/TypeScript/issues/7993

@thanresnick 그걸 왜 믿나요?

이것은 내가 지금 작업하고 있는 코드베이스에서 매우 유용할 것입니다. 이것이 이미 언어의 일부였다면 오늘 오류를 추적하는 데 시간을 쓰지 않았을 것입니다.

(다른 오류일 수도 있지만 이 특정 오류는 아닙니다 😉)

나는 Flow에서 영감을 받은 파이프 구문을 좋아하지 않습니다. 인터페이스 뒤에 exact 키워드와 같은 것이 더 읽기 쉽습니다.

exact interface Foo {}

@mohsen1 나는 대부분의 사람들이 표현식 위치에서 Exact 제네릭 유형을 사용할 것이라고 확신하므로 너무 중요하지 않아야 합니다. 그러나 이전에 내보내기 전용으로 예약된 interface 키워드의 왼쪽을 너무 일찍 오버로드할 수 있으므로 이와 같은 제안에 대해 우려하고 있습니다(JavaScript 값과 일치 - 예: export const foo = {} ). 또한 해당 키워드가 유형에도 사용할 수 있음을 나타냅니다(예: exact type Foo = {} 및 이제 export exact interface Foo {} ).

{| |} 구문을 사용하면 extends 어떻게 작동합니까? interface Bar extends Foo {| |} 이 정확하지 않으면 Foo 가 정확합니까?

exact 키워드를 사용하면 인터페이스가 정확한지 쉽게 알 수 있다고 생각합니다. type 에서도 작동할 수 있습니다.

interface Foo {}
type Bar = exact Foo

추가 데이터가 자동으로 무시되고 버그를 찾기가 매우 어려울 수 있으므로 모든 선택적 속성이 있는 객체를 가져오는 AWS SDK 와 같은 데이터베이스 또는 SDK에 대한 네트워크 호출 또는 데이터베이스에서 작동하는 작업에 매우 유용합니다.

@mohsen1 키워드 접근 방식을 사용하여 동일한 질문이 여전히 존재하기 때문에 해당 질문은 구문과 관련이 없는 것 같습니다. 개인적으로, 나는 선호하는 답이 없고 그것에 답하기 위해 기존의 기대치를 가지고 놀아야 할 것입니다 - 그러나 나의 초기 반응은 Foo 가 정확한지 아닌지는 중요하지 않아야 한다는 것입니다.

exact 키워드의 사용법이 모호해 보입니다. exact interface Foo {} 또는 type Foo = exact {} 와 같이 사용할 수 있다는 말씀이신가요? exact Foo | Bar 은(는) 무슨 뜻인가요? 일반적인 접근 방식을 사용하고 기존 패턴으로 작업한다는 것은 다시 발명하거나 학습할 필요가 없다는 것을 의미합니다. interface Foo {||} (여기서 유일하게 새로운 것입니다), type Foo = Exact<{}> 및 Exact<Foo> | Bar 입니다.

우리는 이것에 대해 꽤 오랫동안 이야기했습니다. 나는 토론을 요약하려고 노력할 것이다.

초과 재산 확인

정확한 유형은 추가 속성을 감지하는 방법일 뿐입니다. 정확한 유형에 대한 수요는 처음에 초과 속성 검사(EPC)를 구현했을 때 많이 떨어졌습니다. EPC는 아마도 우리가 취한 가장 큰 획기적인 변화였을 것입니다. EPC 가 초과 속성을 감지

사람들이 정확한 유형을 원하는 대부분의 경우 우리는 EPC를 더 똑똑하게 만들어 이를 수정하는 것을 선호합니다. 여기에서 핵심 영역은 대상 유형이 공용체 유형일 때입니다. 우리는 이것을 버그 수정으로 간주하고 싶습니다(EPC 는 여기에서 작동

모든 옵션 유형

EPC와 관련된 것은 모든 선택적 유형(저는 "약한" 유형이라고 함)의 문제입니다. 대부분의 약한 유형은 정확하기를 원할 것입니다. 약한 유형 감지를 구현해야 합니다(#7485 / #3842). 여기서 유일한 방해 요소는 구현에 약간의 추가 복잡성이 필요한 교차 유형입니다.

누구의 유형이 정확합니까?

정확한 유형에서 볼 수 있는 첫 번째 주요 문제는 정확한 유형으로 표시해야 하는 유형이 정말 불분명하다는 것입니다.

스펙트럼의 한쪽 끝에는 고정된 도메인 외부에 자체 키가 있는 객체가 주어지면 문자 그대로 예외를 던지거나 나쁜 일을 하는 함수가 있습니다. 이것들은 거의 없습니다(기억에서 예를 들 수 없습니다). 중간에 조용히 무시하는 기능이 있습니다.
알 수 없는 속성(거의 모두). 그리고 다른 쪽 끝에는 일반적으로 모든 속성에 대해 작동하는 함수가 있습니다(예: Object.keys ).

분명히 "추가 데이터가 주어지면 throw" 함수는 정확한 유형을 허용하는 것으로 표시되어야 합니다. 그러나 중간은 어떻습니까? 사람들은 아마 동의하지 않을 것입니다. Point2D / Point3D 가 좋은 예입니다. Point3D 전달을 방지하려면 magnitude 함수가 (p: exact Point2D) => number 유형을 가져야 한다고 합리적으로 말할 수 있습니다 Point3D . 하지만 왜 내 { x: 3, y: 14, units: 'meters' } 개체를 해당 함수에 전달할 수 없습니까? 이것이 EPC가 들어오는 곳입니다. "추가" units 속성이 확실히 폐기되지만 실제로 앨리어싱과 관련된 호출을 차단하지 않는 위치에서 감지하려고 합니다.

가정/인스턴스화 문제의 위반

정확한 유형이 무효화되는 몇 가지 기본 원칙이 있습니다. 예를 들어 T & U 유형은 항상 T 할당할 수 있다고 가정하지만 T 가 정확한 유형이면 실패합니다. 이 T & U -> T 원칙을 사용하는 일부 일반 함수가 있을 수 있지만 정확한 유형으로 인스턴스화된 T 함수를 호출할 수 있기 때문에 이것은 문제가 됩니다. 따라서 우리가 이 소리를 낼 수 있는 방법은 없습니다(인스턴스화에서 오류가 발생하는 것은 정말 좋지 않음) - 반드시 차단기는 아니지만 수동으로 인스턴스화한 자체 버전보다 일반 함수가 더 관대하다는 것은 혼란스럽습니다!

또한 T 는 항상 T | U 할당할 수 있다고 가정하지만 U 가 정확한 유형인 경우 이 규칙을 적용하는 방법이 명확하지 않습니다. { s: "hello", n: 3 } 을 { s: string } | Exact<{ n: number }> 할당할 수 있습니까? "예"는 n 를 찾고 s 를 보고 기뻐하지 않을 것이기 때문에 잘못된 대답처럼 보이지만 "아니오"도 기본 T -> T | U 위반했기 때문에 잘못된 것으로 보입니다.

잡록

function f<T extends Exact<{ n: number }>(p: T) 은(는) 무슨 뜻인가요? :혼란스러운:

종종 당신이 정말로 원하는 것이 "자동 분리된(auto-disjointed)" 합집합인 경우 정확한 유형이 요구됩니다. 즉, { type: "name", firstName: "bob", lastName: "bobson" } 또는 { type: "age", years: 32 } 를 수락할 수 있지만 예측할 수 없는 일이 발생할 것이기 때문에 { type: "age", years: 32, firstName: 'bob" } 를 수락하고 싶지 않은 API가 있을 수 있습니다. "올바른" 유형은 틀림없이 { type: "name", firstName: string, lastName: string, age: undefined } | { type: "age", years: number, firstName: undefined, lastName: undefined } 이지만 입력하기 귀찮은 좋은 골리입니다. 우리는 잠재적으로 이와 같은 유형을 만들기 위해 설탕에 대해 생각할 수 있습니다.

요약: 필요한 사용 사례

우리의 희망적인 진단은 이것이 상대적으로 소수의 진정으로 폐쇄된 API를 제외하고는 XY 문제 솔루션이라는 것입니다. 가능하면 EPC를 사용하여 "나쁜" 속성을 감지해야 합니다. 따라서 문제가 있고 정확한 유형이 올바른 솔루션이라고 생각하는 경우 여기에 원래 문제를 설명하여 패턴 카탈로그를 구성하고 덜 침습적이거나 혼란스러운 다른 솔루션이 있는지 확인할 수 있도록 하십시오.

사람들이 정확한 객체 유형이 없어 놀라는 것을 보는 주된 장소는 Object.keys 및 for..in -- 항상 'a'|'b' 대신 string 유형을 생성합니다. 'a'|'b' { a: any, b: any } 입력된 항목에 대한

https://github.com/Microsoft/TypeScript/issues/14094 에서 언급했고 기타 섹션에서 설명했듯이 {first: string, last: string, fullName: string} 이 {first: string; last: string} | {fullName: string} 준수한다는 것은 짜증납니다.

예를 들어 T & U 유형은 항상 T에 할당할 수 있다고 가정하지만 T가 정확한 유형이면 실패합니다.

T 가 정확한 유형이면 T & U 가 never (또는 T === U )일 것입니다. 오른쪽?

또는 U 는 T 의 정확하지 않은 하위 집합입니다.

이 제안으로 이끄는 내 사용 사례는 redux 감속기입니다.

interface State {
   name: string;
}
function nameReducer(state: State, action: Action<string>): State {
   return {
       ...state,
       fullName: action.payload // compiles, but it's an programming mistake
   }
}

요약에서 지적했듯이 내 문제는 정확한 인터페이스가 필요하다는 것이 아니라 정확하게 작동하려면 스프레드 연산자가 필요하다는 것입니다. 그러나 Spread 연산자의 동작은 JS에서 제공하므로 내 마음에 떠오르는 유일한 해결책은 반환 유형이나 인터페이스를 정확하게 정의하는 것입니다.

나는의 값을 할당하는 것을 제대로 이해하고 있는가 T 에 Exact<T> 오류가 있을까?

interface Dog {
    name: string;
    isGoodBoy: boolean;
}
let a: Dog = { name: 'Waldo', isGoodBoy: true };
let b: Exact<Dog> = a;

이 예에서 Dog 를 Exact<Dog> 좁히면 안전하지 않겠죠?
다음 예를 고려하십시오.

interface PossiblyFlyingDog extends Dog {
    canFly: boolean;
}
let c: PossiblyFlyingDog = { ...a, canFly: true };
let d: Dog = c; // this is okay
let e: Exact<Dog> = d; // but this is not

@leonadler 네, 그 아이디어입니다. Exact<T> 에는 Exact<T> 만 할당할 수 있습니다. 내 즉각적인 사용 사례는 유효성 검사 기능이 Exact 유형을 처리한다는 것입니다(예: 요청 페이로드를 any 오고 유효한 Exact<T> ). Exact<T> 는 T 할당할 수 있습니다.

@네루모

요약에서 지적했듯이 내 문제는 정확한 인터페이스가 필요하다는 것이 아니라 정확하게 작동하려면 스프레드 연산자가 필요하다는 것입니다. 그러나 Spread 연산자의 동작은 JS에서 제공하므로 내 마음에 떠오르는 유일한 해결책은 반환 유형이나 인터페이스를 정확하게 정의하는 것입니다.

나는 같은 문제에 부딪쳤고 나를 위해 아주 우아한 해결 방법인 이 솔루션을 알아냈습니다. :)

export type State = {
  readonly counter: number,
  readonly baseCurrency: string,
};

// BAD
export function badReducer(state: State = initialState, action: Action): State {
  if (action.type === INCREASE_COUNTER) {
    return {
      ...state,
      counterTypoError: state.counter + 1, // OK
    }; // it's a bug! but the compiler will not find it 
  }
}

// GOOD
export function goodReducer(state: State = initialState, action: Action): State {
  let partialState: Partial<State> | undefined;

  if (action.type === INCREASE_COUNTER) {
    partialState = {
      counterTypoError: state.counter + 1, // Error: Object literal may only specify known properties, and 'counterTypoError' does not exist in type 'Partial<State>'. 
    }; // now it's showing a typo error correctly 
  }
  if (action.type === CHANGE_BASE_CURRENCY) {
    partialState = { // Error: Types of property 'baseCurrency' are incompatible. Type 'number' is not assignable to type 'string'.
      baseCurrency: 5,
    }; // type errors also works fine 
  }

  return partialState != null ? { ...state, ...partialState } : state;
}

내 redux 가이드의 이 섹션에서 더 많은 정보를 찾을 수 있습니다.

• https://github.com/piotrwitek/react-redux-typescript-guide#spread -operation-with-exact-types-check-to-guard-against-excess-or-mismatched-props

이것은 내 제약 유형 제안(#13257)을 사용하여 사용자 영역에서 해결할 수 있습니다.

type Exact<T> = [
    case U in U extends T && T extends U: T,
];

편집: 제안과 관련된 업데이트된 구문

@piotrwitek 감사합니다. 부분적 트릭이 완벽하게 작동하고 이미 내 코드 기반에서 버그를 발견했습니다 ;) 작은 상용구 코드의 가치가 있습니다. 하지만 여전히 @isiahmeadows 의 정확한 의견에 동의합니다.더 좋을 것입니다

@piotrwitek 과 같은 Partial을 사용하여 _거의_ 내 문제를 해결했지만 State 인터페이스가 그렇지 않은 경우에도 속성이 정의되지 않은 상태가 되도록 허용합니다(strictNullChecks로 가정합니다).

인터페이스 유형을 유지하기 위해 약간 더 복잡한 것으로 끝났습니다.

export function updateWithPartial<S extends object>(current: S, update: Partial<S>): S {
    return Object.assign({}, current, update);
}

export function updateWith<S extends object, K extends keyof S>(current: S, update: {[key in K]: S[key]}): S {
    return Object.assign({}, current, update);
}

interface I {
    foo: string;
    bar: string;
}

const f: I = {foo: "a", bar: "b"}
updateWithPartial(f, {"foo": undefined}).foo.replace("a", "x"); // Compiles, but fails at runtime
updateWith(f, {foo: undefined}).foo.replace("a", "x"); // Does not compile
updateWith(f, {foo: "c"}).foo.replace("a", "x"); // Compiles and works

@asmundg 맞습니다. 솔루션은 정의되지 않은 것을 허용하지만 제 관점에서는 이것이 허용됩니다. 제 솔루션에서 페이로드에 필요한 매개변수가 있는 작업 생성자만 사용하고 있기 때문입니다. 이렇게 하면 정의되지 않은 값이 절대 없어야 합니다. nullable이 아닌 속성에 할당됩니다.
실제로 프로덕션에서 꽤 오랜 시간 동안 이 솔루션을 사용하고 있으며 이 문제는 발생하지 않았지만 우려 사항을 알려주세요.

export const CHANGE_BASE_CURRENCY = 'CHANGE_BASE_CURRENCY';

export const actionCreators = {
  changeBaseCurrency: (payload: string) => ({
    type: CHANGE_BASE_CURRENCY as typeof CHANGE_BASE_CURRENCY, payload,
  }),
}

store.dispatch(actionCreators.changeBaseCurrency()); // Error: Supplied parameters do not match any signature of call target.
store.dispatch(actionCreators.changeBaseCurrency(undefined)); // Argument of type 'undefined' is not assignable to parameter of type 'string'.
store.dispatch(actionCreators.changeBaseCurrency('USD')); // OK => { type: "CHANGE_BASE_CURRENCY", payload: 'USD' }

데모 - 옵션에서 strictNullCheck 활성화

필요한 경우 nullable 페이로드도 만들 수 있습니다. 내 가이드에서 자세히 읽을 수 있습니다. https://github.com/piotrwitek/react-redux-typescript-guide#actions

나머지 유형 이 병합되면 이 기능을 통해 쉽게 구문 설탕을 만들 수 있습니다.

제안

유형 동일성 논리는 엄격해야 합니다. 동일한 속성을 가진 유형 또는 부모 유형이 동일한 속성을 갖는 방식으로 인스턴스화할 수 있는 나머지 속성이 있는 유형만 일치하는 것으로 간주됩니다. 이전 버전과의 호환성을 유지하기 위해 합성 나머지 유형이 이미 존재하지 않는 한 모든 유형에 추가됩니다. 새 플래그 --strictTypes 도 추가되어 합성 나머지 매개변수의 추가를 억제합니다.

--strictTypes 미만의 평등:

type A = { x: number, y: string };
type B = { x: number, y: string, ...restB: <T>T };
type C = { x: number, y: string, z: boolean, ...restC: <T>T };

declare const a: A;
declare const b: B;
declare const c: C;

a = b; // Error, type B has extra property: "restB"
a = c; // Error, type C has extra properties: "z", "restC"
b = a; // OK, restB inferred as {}
b = c; // OK, restB inferred as { z: boolean, ...restC: <T>T }

c = a; // Error, type A is missing property: "z"
       // restC inferred as {}

c = b; // Error, type B is missing property: "z"
       // restC inferred as restB 

--strictTypes 가 켜져 있지 않으면 ...rest: <T>T 속성이 A 유형에 자동으로 추가됩니다. 이렇게 하면 a = b; 및 a = c; 이 더 이상 오류가 되지 않으며, 뒤에 오는 두 행에 b 변수가 있는 경우와 같습니다.

가정 위반에 대한 한마디

T & U 유형은 항상 T에 할당할 수 있다고 가정하지만 T가 정확한 유형이면 실패합니다.

예, & 는 가짜 논리를 허용하지만 string & number 의 경우도 마찬가지입니다. string 및 number 는 서로 교차할 수 없는 고유한 고정 유형이지만 유형 시스템에서 허용합니다. 정확한 유형도 엄격하므로 불일치가 여전히 일관됩니다. 문제는 & 연산자에 있습니다.

{ s: "hello", n: 3 }을 { s: string }에 할당할 수 있습니까? | 정확한<{ n: 숫자 }>.

이것은 다음과 같이 번역될 수 있습니다:

type Test = { s: string, ...rest: <T>T } | { n: number }
const x: Test = { s: "hello", n: 3 }; // OK, s: string; rest inferred as { n: number }

따라서 대답은 "예"여야 합니다. 판별자 속성이 없으면 정확하지 않은 유형이 모든 정확한 유형을 포함하므로 정확하지 않은 유형과 일치하는 것은 안전하지 않습니다.

Re: 위의 @RyanCavanaugh 주석 의 f<T extends Exact<{ n: number }>(p: T) 함수는 내 라이브러리 중 하나에서 다음 함수를 구현하고 싶습니다.

const checkType = <T>() => <U extends Exact<T>>(value: U) => value;

즉, 정확히 동일한 유형의 매개변수를 반환하는 함수이지만 동시에 해당 유형이 다른 유형(T)과 정확히 동일한 유형인지 여부도 확인합니다.

다음은 두 가지 요구 사항을 모두 충족하기 위해 실패한 세 번의 시도가 포함된 약간 인위적인 예입니다.

1. CorrectObject 대한 초과 속성 없음
2. HasX 를 개체 유형으로 지정하지 않고 HasX 할당 가능

type AllowedFields = "x" | "y";
type CorrectObject = {[field in AllowedFields]?: number | string};
type HasX = { x: number };

function objectLiteralAssignment() {
  const o: CorrectObject = {
    x: 1,
    y: "y",
    // z: "z" // z is correctly prevented to be defined for o by Excess Properties rules
  };

  const oAsHasX: HasX = o; // error: Types of property 'x' are incompatible.
}

function objectMultipleAssignment() {
  const o = {
    x: 1,
    y: "y",
    z: "z",
  };
  const o2 = o as CorrectObject; // succeeds, but undesirable property z is allowed

  type HasX = { x: number };

  const oAsHasX: HasX = o; // succeeds
}

function genericExtends() {
  const checkType = <T>() => <U extends T>(value: U) => value;
  const o = checkType<CorrectObject>()({
    x: 1,
    y: "y",
    z: "z", // undesirable property z is allowed
  }); // o is inferred to be { x: number; y: string; z: string; }

  type HasX = { x: number };

  const oAsHasX: HasX = o; // succeeds
}

여기서 HasX 는 상수 자체와 다른 레이어에 정의된 매우 단순화된 유형(실제 유형은 스키마 유형에 매핑됨)이므로 o 유형을 만들 수 없습니다. ( CorrectObject & HasX ).

정확한 유형을 사용하는 경우 솔루션은 다음과 같습니다.

function exactTypes() {
  const checkType = <T>() => <U extends Exact<T>>(value: U) => value;
  const o = checkType<CorrectObject>()({
    x: 1,
    y: "y",
    // z: "z", // undesirable property z is *not* allowed
  }); // o is inferred to be { x: number; y: string; }

  type HasX = { x: number };

  const oAsHasX: HasX = o; // succeeds
}

@andy-ms

T가 정확한 유형이라면 아마도 T & U는 절대(또는 T === U)가 아닙니다. 오른쪽?

내 생각 T & U 해야 never 경우에만 U 와라도 유용 호환되지 T , 예를 들어, 경우 T 있다 Exact<{x: number | string}> U 는 {[field: string]: number} 이고 T & U 는 Exact<{x: number}> 여야 합니다.

이에 대한 첫 번째 응답을 참조하십시오.

또는 U는 T의 정확하지 않은 부분 집합입니다.

U가 T에 할당 가능하면 T & U === T 입니다. 그러나 T 와 U 가 다른 정확한 유형이면 T & U === never 입니다.

귀하의 예에서 아무 것도 하지 않는 checkType 함수가 필요한 이유는 무엇입니까? const o: Exact<CorrectObject> = { ... } 만 있으면 되지 않습니까?

x가 확실히 존재하고(CorrectObject에서 선택 사항) 숫자(CorrectObject에서 숫자 | 문자열)라는 정보를 잃기 때문입니다. 또는 Exact가 의미하는 바를 잘못 이해했을 수도 있습니다. 모든 유형이 정확히 동일해야 한다는 것을 반복적으로 의미하는 것이 아니라 외부 속성을 방지할 뿐이라고 생각했습니다.

정확한 유형 지원과 현재 EPC에 대한 또 다른 고려 사항은 리팩토링입니다. 추출 변수 리팩토링을 사용할 수 있는 경우 추출된 변수에 유형 주석이 도입되지 않는 한 EPC가 손실되어 매우 장황해질 수 있습니다.

내가 정확한 유형을 지지하는 이유를 명확히 하기 위해 - 구분된 공용체를 위한 것이 아니라 철자 오류 및 유형 costtraint를 개체 리터럴과 동시에 지정할 수 없는 경우를 대비하여 잘못된 관련 속성을 위한 것입니다.

@andy-ms

U가 T에 할당 가능하면 T & U === T입니다. 그러나 T와 U가 다른 정확한 유형이면 T & U === 절대 아닙니다.

& 유형 연산자는 교집합 연산자이며, 그 결과는 양쪽의 공통 하위 집합이며 반드시 같지는 않습니다. 내가 생각할 수있는 가장 간단한 예 :

type T = Exact<{ x?: any, y: any }>;
type U = { x: any, y? any };

여기서 T & U 는 Exact<{ x: any, y: any }> T & U 이어야 합니다. 이는 T 및 U 의 하위 집합이지만 T 둘 다 U (x 누락) 또는 U 는 T (y 누락)의 하위 집합입니다.

이것은 T , U 또는 T & U 가 정확한 유형인지 여부와 관계없이 작동해야 합니다.

@magnushiie 좋은 지적이 있습니다. 정확한 유형은 너비가 더 큰 유형의 할당 가능성을 제한할 수 있지만 여전히 더 깊은 유형의 할당 가능성은 허용합니다. 당신은 교차 할 수 있도록 Exact<{ x: number | string }> 와 Exact<{ x: string | boolean }> 얻을 Exact<{ x: string }> . 한 가지 문제는 x 가 읽기 전용이 아닌 경우 실제로 유형 안전하지 않다는 것입니다. 더 엄격한 동작을 선택하는 것을 의미하기 때문에 정확한 유형에 대한 실수를 수정하고 싶을 수도 있습니다.

색인 서명에 대한 유형 인수 관계 문제에 정확한 유형을 사용할 수도 있습니다.

interface T {
    [index: string]: string;
}

interface S {
    a: string;
    b: string;
}

interface P extends S {
    c: number;
}

declare function f(t: T);
declare function f2(): P;
const s: S = f2();

f(s); // Error because an interface can have more fields that is not conforming to an index signature
f({ a: '', b: '' }); // No error because literals is exact by default

정확한 유형을 확인하는 해킹 방법은 다음과 같습니다.

// type we'll be asserting as exact:
interface TextOptions {
  alignment: string;
  color?: string;
  padding?: number;
}

// when used as a return type:
function getDefaultOptions(): ExactReturn<typeof returnValue, TextOptions> {
  const returnValue = { colour: 'blue', alignment: 'right', padding: 1 };
  //             ERROR: ^^ Property 'colour' is missing in type 'TextOptions'.
  return returnValue
}

// when used as a type:
function example(a: TextOptions) {}
const someInput = {padding: 2, colour: '', alignment: 'right'}
example(someInput as Exact<typeof someInput, TextOptions>)
  //          ERROR: ^^ Property 'colour' is missing in type 'TextOptions'.

불행히도 현재 Exact 주장을 유형 매개변수로 만드는 것은 불가능하므로 호출 시간 동안 이루어져야 합니다(즉, 이에 대해 기억해야 함).

다음은 작동하는 데 필요한 도우미 유틸리티입니다(일부 @tycho01 덕분에).

type Exact<A, B extends Difference<A, B>> = AssertPassThrough<Difference<A, B>, A, B>
type ExactReturn<A, B extends Difference<A, B>> = B & Exact<A, B>

type AssertPassThrough<Actual, Passthrough, Expected extends Actual> = Passthrough;
type Difference<A, Without> = {
  [P in DiffUnion<keyof A, keyof Without>]: A[P];
}
type DiffUnion<T extends string, U extends string> =
  ({[P in T]: P } &
  { [P in U]: never } &
  { [k: string]: never })[T];

참조: 놀이터 .

좋은 것! @gcanti ( typelevel-ts ) 및 @pelotom ( type-zoo )도 관심을 가질 수 있습니다. :)

관심 있는 사람이라면 함수 매개변수에 정확한 유형을 적용하는 간단한 방법을 찾았습니다. 적어도 TS 2.7에서 작동합니다.

function myFn<T extends {[K in keyof U]: any}, U extends DesiredType>(arg: T & U): void;

편집: 이것이 작동하려면 인수에 직접 개체 리터럴을 지정해야 합니다. 위에서 별도의 const를 선언하고 대신 전달하면 작동하지 않습니다. :/ 그러나 한 가지 해결 방법은 호출 사이트에서 개체 확산을 사용하는 것입니다(예: myFn({...arg}) .

편집: 죄송합니다. TS 2.7만 언급한 것을 읽지 못했습니다. 거기에서 테스트하겠습니다!

@vaskevich 작동하지 않는 것 같습니다. 즉 colour 을 초과 속성으로 감지하지 못합니다 .

조건부 유형이 적용되면(#21316) "새롭지 않은" 객체 리터럴의 경우에도 정확한 유형을 함수 매개변수로 요구하도록 다음을 수행할 수 있습니다.

type Exactify<T, X extends T> = T & {
    [K in keyof X]: K extends keyof T ? X[K] : never
}

type Foo = {a?: string, b: number}

declare function requireExact<X extends Exactify<Foo, X>>(x: X): void;

const exact = {b: 1}; 
requireExact(exact); // okay

const inexact = {a: "hey", b: 3, c: 123}; 
requireExact(inexact);  // error
// Types of property 'c' are incompatible.
// Type 'number' is not assignable to type 'never'.

물론 유형을 넓히면 작동하지 않지만 그것에 대해 실제로 할 수있는 일은 없다고 생각합니다.

const inexact = {a: "hey", b: 3, c: 123} as Foo;
requireExact(inexact);  // okay

생각?

기능 매개변수에 대해 진행 중인 것 같습니다. 함수 반환 값에 대해 정확한 유형을 적용하는 방법을 찾은 사람이 있습니까?

@jezzgoodwin 정말 아닙니다. 추가 속성이 제대로 확인되지 않는 함수 반환의 근본 원인인 #241을 참조하십시오.

사용 사례가 하나 더 있습니다. 오류로 보고되지 않은 다음 상황 때문에 버그가 거의 발생했습니다.

interface A {
    field: string;
}

interface B {
    field2: string;
    field3?: string;
}

type AorB = A | B;

const fixture: AorB[] = [
    {
        field: 'sfasdf',
        field3: 'asd' // ok?!
    },
];

( 놀이터 )

이에 대한 확실한 해결책은 다음과 같습니다.

type AorB = Exact<A> | Exact<B>;

#16679에서 제안된 해결 방법을 보았지만 제 경우에는 유형이 AorBorC 이고 각 개체에 여러 속성이 있으므로 fieldX?:never 속성 집합을 수동으로 계산하기가 다소 어렵습니다. 각 유형에 대해.

@michalstocki #20863 아닌가요? 노동 조합에 대한 초과 재산 확인이 더 엄격해지기를 원합니다.

어쨌든 정확한 유형이 없고 공용체에 대한 엄격한 초과 속성 검사가 없는 경우 조건부 유형 을 사용하는 대신 프로그래밍 방식으로 이러한 fieldX?:never 속성을 수행할 수 있습니다 .

type AllKeys<U> = U extends any ? keyof U : never
type ExclusifyUnion<U> = [U] extends [infer V] ?
 V extends any ? 
 (V & {[P in Exclude<AllKeys<U>, keyof V>]?: never}) 
 : never : never

그런 다음 노조를 다음과 같이 정의하십시오.

type AorB = ExclusifyUnion<A | B>;

로 확장되는

type AorB = (A & {
    field2?: undefined;
    field3?: undefined;
}) | (B & {
    field?: undefined;
})

자동으로. 모든 AorBorC 에서도 작동합니다.

또한 독점 또는 구현에 대해서는 https://github.com/Microsoft/TypeScript/issues/14094#issuecomment -373780463을 참조

@jcalz 고급 유형 ExclusifyUnion은 매우 안전하지 않습니다.

const { ...fields } = o as AorB;

fields.field3.toUpperCase(); // it shouldn't be passed

fields 의 필드는 모두 선택 사항이 아닙니다.

나는 그것이 Exact 유형과 많은 관련이 있다고 생각하지 않지만, 공용체 유형 객체를 퍼뜨렸다가 구조 해제할 때 어떤 일이 발생하는지와 관련이 있다고 생각합니다. 모든 공용체는 개체를 개별 속성으로 분리한 다음 다시 결합하기 때문에 단일 교차 유형으로 평평해집니다. 각 조합의 구성 요소 간의 상관 관계 또는 제약 조건은 손실됩니다. 피하는 방법을 잘 모르겠습니다... 버그라면 별개의 문제일 수 있습니다.

분명히 구조화 전에 유형 보호를 수행하면 상황이 더 잘 작동합니다.

declare function isA(x: any): x is A;
declare function isB(x: any): x is B;

declare const o: AorB;
if (isA(o)) {
  const { ...fields } = o;
  fields.field3.toUpperCase(); // error
} else {
  const { ...fields } = o;
  fields.field3.toUpperCase(); // error
  if (fields.field3) {
    fields.field3.toUpperCase(); // okay
  }
}

이것이 당신이 보는 문제를 "수정"하는 것은 아니지만 누군가가 제한된 노동 조합으로 행동하기를 기대하는 방식입니다.

아마도 https://github.com/Microsoft/TypeScript/pull/24897 이 확산 문제를 해결할 수 있습니다.

나는 파티에 늦을 수도 있지만, 적어도 당신의 유형이 정확히 일치하는지 확인하는 방법은 다음과 같습니다.

type AreSame<A, B> = A extends B
    ? B extends A ? true : false
    : false;
const sureIsTrue: (fact: true) => void = () => {};
const sureIsFalse: (fact: false) => void = () => {};



declare const x: string;
declare const y: number;
declare const xAndYAreOfTheSameType: AreSame<typeof x, typeof y>;
sureIsFalse(xAndYAreOfTheSameType);  // <-- no problem, as expected
sureIsTrue(xAndYAreOfTheSameType);  // <-- problem, as expected

내가 이것을 할 수 있기를 바랍니다:

type Exact<A, B> = A extends B ? B extends A ? B : never : never;
declare function needExactA<X extends Exact<A, X>>(value: X): void;

이 문제에 설명된 기능이 비어 있거나 인덱싱된 인터페이스가 함수나 클래스와 같은 객체 유형과 일치하는 경우에 도움이 될까요?

interface MyType
{
    [propName: string]: any;
}

function test(value: MyType) {}

test({});           // OK
test(1);            // Fails, OK!
test('');           // Fails, OK!
test(() => {});     // Does not fail, not OK!
test(console.log);  // Does not fail, not OK!
test(console);      // Does not fail, not OK!

MyType 인터페이스는 인덱스 서명만 정의하고 test 함수의 유일한 매개변수 유형으로 사용됩니다. 유형의 함수에 전달된 매개변수:

• 개체 리터럴 {} , 통과합니다. 예상되는 동작입니다.
• 숫자 상수 1 는 통과하지 않습니다. 예상되는 동작('1' 유형의 인수는 'MyType' 유형의 매개변수에 할당할 수 없습니다._)
• 문자열 리터럴 '' 는 통과하지 않습니다. 예상되는 동작(_`'""' 유형의 인수는 'MyType' 유형의 매개변수에 할당할 수 없습니다._)
• 화살표 함수 선언 () => {} : 통과. 예상하지 못한 동작입니다. 함수가 객체이기 때문에 통과할 수 있습니까?
• 클래스 방법 console.log 통과. 예상하지 못한 동작입니다. 화살표 기능과 유사합니다.
• console 클래스 통과. 예상하지 못한 동작입니다. 아마도 클래스가 객체이기 때문일까요?

요점은 MyType 인터페이스와 이미 일치하는 변수만 허용한다는 것입니다 (암시적으로 변환되지 않음). TypeScript는 시그니처를 기반으로 많은 암시적 변환을 수행하는 것으로 보이므로 지원되지 않을 수 있습니다.

주제를 벗어난 경우 사과드립니다. 지금까지 이 문제는 위에서 설명한 문제와 가장 근접합니다.

@Janne252 이 제안은 간접적으로 도움이 될 수 있습니다. 명백한 Exact<{[key: string]: any}> 시도했다고 가정하면 작동하는 이유는 다음과 같습니다.

• 개체 리터럴은 이미 {[key: string]: any} 와 같이 예상대로 전달됩니다.
• 리터럴을 {[key: string]: any} 할당할 수 없기 때문에 숫자 상수는 예상대로 실패합니다.
• 문자열 리터럴은 {[key: string]: any} 할당할 수 없기 때문에 예상대로 실패합니다.
• 함수와 클래스 생성자는 call 서명으로 인해 실패합니다(문자열 속성이 아님).
• console 객체는 단지 객체 (클래스가 아님)이기 때문에 전달됩니다. JS는 객체와 키/값 딕셔너리를 구분하지 않으며 TS는 행 다형성 유형이 추가된 것 외에는 여기에서 다르지 않습니다. 또한 TS는 값 종속 유형을 지원하지 않으며 typeof 는 몇 가지 추가 매개변수 및/또는 유형 별칭을 추가하기 위한 단순한 설탕입니다.

@blakeembrey @michalstocki @aleksey-bykov
이것은 정확한 유형을 수행하는 방법입니다.

type Exact<A extends object> = A & {__kind: keyof A};

type Foo = Exact<{foo: number}>;
type FooGoo = Exact<{foo: number, goo: number}>;

const takeFoo = (foo: Foo): Foo => foo;

const foo = {foo: 1} as Foo;
const fooGoo = {foo: 1, goo: 2} as FooGoo;

takeFoo(foo)
takeFoo(fooGoo) // error "[ts]
//Argument of type 'Exact<{ foo: number; goo: number; }>' is not assignable to parameter of type 'Exact<{ //foo: number; }>'.
//  Type 'Exact<{ foo: number; goo: number; }>' is not assignable to type '{ __kind: "foo"; }'.
//    Types of property '__kind' are incompatible.
//      Type '"foo" | "goo"' is not assignable to type '"foo"'.
//        Type '"goo"' is not assignable to type '"foo"'."

const takeFooGoo = (fooGoo: FooGoo): FooGoo => fooGoo;

takeFooGoo(fooGoo);
takeFooGoo(foo); // error "[ts]
// Argument of type 'Exact<{ foo: number; }>' is not assignable to parameter of type 'Exact<{ foo: number; // goo: number; }>'.
//  Type 'Exact<{ foo: number; }>' is not assignable to type '{ foo: number; goo: number; }'.
//    Property 'goo' is missing in type 'Exact<{ foo: number; }>'.

함수 매개변수, 반환 및 할당에서도 작동합니다.
const foo: Foo = fooGoo; // 오류
런타임 오버헤드가 없습니다. 유일한 문제는 새로운 정확한 객체를 생성할 때마다 해당 유형에 대해 캐스팅해야 하지만 실제로는 큰 문제가 아니라는 것입니다.

원래 예제가 올바른 동작을 한다고 생각합니다. interface 가 열려 있을 것으로 예상합니다. 대조적으로, 나는 type 가 닫힐 것으로 예상합니다(그리고 그들은 때때로 닫힙니다). 다음은 MappedOmit 유형을 작성할 때 놀라운 동작의 예입니다.
https://gist.github.com/donabrams/b849927f5a0160081db913e3d52cc7b3

예제의 MappedOmit 유형은 구별된 공용체에 대해 의도된 대로만 작동합니다. 비차별 공용체의 경우 공용체 유형의 교차 가 전달되면 Typescript 3.2가 통과됩니다.

as TypeX 또는 as any 를 사용하여 캐스팅하는 위의 해결 방법은 구성에서 오류를 숨기는 부작용이 있습니다!. 우리는 typechecker가 구성 오류를 잡는 데도 도움이 되기를 바랍니다! 또한 잘 정의된 유형에서 정적으로 생성할 수 있는 몇 가지 항목이 있습니다. 위와 같은 해결 방법(또는 여기에 설명된 명목형 해결 방법: https://gist.github.com/donabrams/74075e89d10db446005abe7b1e7d9481)이 해당 생성기의 작동을 중지합니다( _ 선행 필드를 필터링할 수 있지만 이는 고통스러운 규칙입니다. 그것은 절대적으로 피할 수 있습니다).

@aleksey-bykov 참고로 귀하의 구현이 99%의 방식으로 이루어졌다고 생각합니다. 이것은 저에게 효과적이었습니다.

type AreSame<A, B> = A extends B
    ? B extends A ? true : false
    : false;
type Exact<A, B> = AreSame<A, B> extends true ? B : never;

const value1 = {};
const value2 = {a:1};

// works
const exactValue1: Exact<{}, typeof value1> = value1;
const exactValue1WithTypeof: Exact<typeof value1, typeof value1> = value1;

// cannot assign {a:number} to never
const exactValue1Fail: Exact<{}, typeof value2> = value2;
const exactValue1FailWithTypeof: Exact<typeof value1, typeof value2> = value2;

// cannot assign {} to never
const exactValue2Fail: Exact<{a: number}, typeof value1> = value1;
const exactValue2FailWithTypeof: Exact<typeof value2, typeof value1> = value1;

// works
const exactValue2: Exact<{a: number}, typeof value2> = value2;
const exactValue2WithTypeof: Exact<typeof value2, typeof value2> = value2;

와우, 꽃은 여기 두고 가세요, 선물은 저 상자에 넣어요

여기서 할 수 있는 작은 개선 사항:
Exact 의 다음 정의를 사용하여 A 에서 A 및 never 유형으로 B 를 A 의 모든 항목에 효과적으로 뺍니다 B 의 고유 키를 사용하면 잘못된 속성에 대해 더 세부적인 오류가 발생할 수 있습니다.

type Omit<T, K> = Pick<T, Exclude<keyof T, keyof K>>;
type Exact<A, B = {}> = A & Record<keyof Omit<B, A>, never>;

마지막으로 두 번째 B 템플릿 인수의 명시적인 템플릿 사용을 추가하지 않고도 이 작업을 수행할 수 있기를 원했습니다. 런타임에 영향을 미치므로 이상적이지는 않지만 실제로 필요한 경우 유용합니다.

function makeExactVerifyFn<T>() {
  return <C>(x: C & Exact<T, C>): C => x;
}

샘플 사용법:

interface Task {
  title: string;
  due?: Date;
}

const isOnlyTask = makeExactVerifyFn<Task>();

const validTask_1 = isOnlyTask({
    title: 'Get milk',
    due: new Date()  
});

const validTask_2 = isOnlyTask({
    title: 'Get milk'
});

const invalidTask_1 = isOnlyTask({
    title: 5 // [ts] Type 'number' is not assignable to type 'string'.
});

const invalidTask_2 = isOnlyTask({
    title: 'Get milk',
    procrastinate: true // [ts] Type 'true' is not assignable to type 'never'.
});

@danielnmsft 특히 적절한 유효성 검사에 필요한 경우 예제에서 B in Exact<A, B> 선택 사항으로 두는 것이 이상하게 보입니다. 그렇지 않으면 나에게 꽤 좋아 보입니다. Equal 라는 이름이 더 좋아 보입니다.

@drabinowitz Exact 유형은 실제로 여기에 제안된 내용을 나타내지 않으며 아마도 AreExact 와 같은 이름으로 변경되어야 합니다. 내 말은, 당신은 당신의 유형으로 이것을 할 수 없습니다:

function takesExactFoo<T extends Exact<Foo>>(foo: T) {}

그러나 유형은 정확한 매개변수 유형을 구현하는 데 편리합니다!

type AreSame<A, B> = A extends B
    ? B extends A ? true : false
    : false;
type Exact<A, B> = AreSame<A, B> extends true ? B : never;

interface Foo {
    bar: any
}

function takesExactFoo <T>(foo: T & Exact<Foo, T>) {
                    //  ^ or `T extends Foo` to type-check `foo` inside the function
}

let foo = {bar: 123}
let foo2 = {bar: 123, baz: 123}

takesExactFoo(foo) // ok
takesExactFoo(foo2) // error

UPD1이이 같이 한 런타임 함수를 생성하지 않습니다 솔루션 @danielnmsft의 물론 훨씬 더 유연합니다.

UPD2 Daniel이 실제로 @drabinowitz 와 같은 Exact 유형을 기본적으로 만들었지 만 더 작고 더 나은 유형을 만들었다는 것을 방금 깨달았습니다. 나는 또한 다니엘이 한 것과 같은 일을 한다는 것을 깨달았습니다. 그러나 누군가가 유용하다고 생각하면 내 의견을 남길 것입니다.

AreSame / Exact 는 공용체 유형에서 작동하지 않는 것 같습니다.
예: Exact<'a' | 'b', 'a' | 'b'> 결과는 never 입니다.
이것은 type AreSame<A, B> = A|B extends A&B ? true : false; 정의하여 분명히 고칠 수 있습니다.

@nerumo 는 당신이 보여준 것과 같은 유형의 감속기 기능에 대해

가지고 있던 몇 가지 추가 옵션:

1 typeof 사용하여 반환 유형을 입력 유형과 동일하게 설정할 수 있습니다. 매우 복잡한 유형인 경우 더 유용합니다. 내가 이것을 볼 때 의도는 추가 속성을 방지하는 것이 더 분명합니다.

interface State {
   name: string;
}
function nameReducer(state: State, action: Action<string>): typeof state {
   return {
       ...state,
       fullName: action.payload        // THIS IS REPORTED AS AN ERROR
   };
}

2 감속기의 경우 임시 변수 대신 반환하기 전에 다시 할당하십시오.

interface State {
   name: string;
}
function nameReducer(state: State, action: Action<string>) {
   return (state = {
       ...state,
       fullName: action.payload        // THIS IS REPORTED AS AN ERROR
   });
}

3 정말로 임시 변수를 원하면 명시적 유형을 지정하지 말고 typeof state 다시 사용하십시오.

interface State {
   name: string;
}
function nameReducer(state: State, action: Action<string>) {

   const newState: typeof state = {
       ...state,
       fullName: action.payload         // THIS IS REPORTED AS AN ERROR
   };

   return newState;
}

3b 감속기에 ...state 포함되어 있지 않으면 다음 유형에 Partial<typeof state> 를 사용할 수 있습니다.

interface State {
   name: string;
}
function nameReducer(state: State, action: Action<string>) {

   const newState: Partial<typeof state> = {
       name: 'Simon',
       fullName: action.payload         // THIS IS REPORTED AS AN ERROR
   };

   return newState;
}

나는 이 전체 대화(그리고 방금 전체 스레드를 읽었습니다)가 대부분의 사람들에게 문제의 핵심을 놓쳤다고 생각합니다. 오류를 방지하기 위해 우리가 원하는 것은 '더 넓은' 유형을 허용하지 않는 유형 주장뿐이라는 것입니다.

이것이 사람들이 먼저 시도할 수 있는 것으로 'fullName'을 허용하지 않습니다.

 return <State> {
       ...state,
       fullName: action.payload         // compiles ok :-(
   };

이것은 <Dog> cat 가 컴파일러 에게 말하고 있기 때문입니다. 예, 제가 무엇을 하는지 알고 있습니다. Dog ! 당신은 허가를 요청하지 않습니다.

따라서 나에게 가장 유용한 것은 관련 없는 속성을 방지하는 더 엄격한 <Dog> cat 버전입니다.

 return <strict State> {
       ...state,
       fullName: action.payload     // compiles ok :-(
   };

전체 Exact<T> 유형은 결과를 통해 많은 파급 효과가 있습니다(이것은 긴 스레드입니다!). 그것은 당신이 원한다고 생각 하는 것이지만 많은 문제가 있다는 것이 밝혀진 전체 '확인된 예외' 논쟁을 상기시킵니다(갑자기 5분 후에 Unexact<T> 원함).

반면에 <strict T> 는 '불가능한' 유형이 '통과'하는 것을 방지하는 장벽처럼 작동합니다. 본질적으로 유형을 통과하는 유형 필터입니다(위에서 런타임 함수에서 수행한 것처럼).

그러나 신규 이민자들은 '불량 데이터'가 통과하는 것이 불가능한 경우 이를 방지했다고 가정하기 쉽습니다.

따라서 제안 구문을 만들어야 한다면 다음과 같을 것입니다.

/// This syntax is ONLY permitted directly in front of an object declaration:
return <strict State> { ...state, foooooooooooooo: 'who' };

OP로 돌아가기: 이론적으로 ^[1] 부정 유형을 사용 하면 type Exact<T> = T & not Record<not keyof T, any> 작성할 수 있습니다. 그러면 Exact<{x: string}> 는 x 이외의 키가 있는 유형이 할당되는 것을 금지합니다. 여기 모든 사람이 묻는 것을 만족시키기에 충분한지 확실하지 않지만 OP에 완벽하게 맞는 것 같습니다.

_{[1] 더 나은 인덱스 서명을 기반 으로 하기 때문에 이론적으로 말하는 것입니다.}

여기에 설명된 문제가 있는지 궁금합니다. 다음과 같은 코드가 있습니다.

const Layers = {
  foo: 'foo'
  bar: 'bar'
  baz: 'baz'
}

type Groups = {
  [key in keyof Pick<Layers, 'foo' | 'bar'>]: number
}

const groups = {} as Groups

그런 다음 내가 원하지 않는 알 수 없는 속성을 설정할 수 있습니다.

groups.foo = 1
groups.bar = 2
groups.anything = 2 // NO ERROR :(

anything 설정 any 입니다. 나는 그것이 오류이기를 바랐다.

이것이 이 문제로 해결될 것인가?

내가 했어야 했어

type Groups = {
  [key in keyof Pick<typeof Layers, 'foo' | 'bar'>]: number
}

typeof 의 추가된 사용에 주목하십시오.

Atom 플러그인 atom-typescript 은 실패하지 않기 위해 열심히 노력하다가 결국 충돌했습니다. typeof 추가했을 때 상황이 정상으로 돌아갔고 예상했던 대로 알 수 없는 소품이 더 이상 허용되지 않았습니다.

즉, typeof 사용하지 않을 때 atom-typescript 는 Groups 유형의 개체를 사용하고 있던 코드의 다른 위치에서 유형을 파악하려고 했습니다. 알 수 없는 소품을 추가하고 any 의 유형 힌트를 보여주었습니다.

그래서 나는이 스레드의 문제가 있다고 생각하지 않습니다.

또 다른 복잡성은 선택적 속성을 처리하는 방법일 수 있습니다.

선택적 속성이 있는 유형이 있는 경우 해당 속성에 대한 Exact<T> 는 다음을 의미합니다.

export type PlaceOrderResponse = { 
   status: 'success' | 'paymentFailed', 
   orderNumber: string
   amountCharged?: number
};

Exact<T> 는 모든 선택적 속성을 정의해야 함을 의미합니까? 무엇으로 지정하시겠습니까? 런타임 효과가 있기 때문에 '정의되지 않음' 또는 'null'이 아닙니다.

이제 '필수 선택적 매개변수'를 지정하는 새로운 방법이 필요합니까?

예를 들어 다음 코드 샘플에서 유형의 '정확성'을 충족시키려면 amountCharged 무엇을 할당해야 합니까? 우리가 이 속성을 최소한 '승인'하도록 강제하지 않는다면 우리는 매우 '정확'하지 않습니다. <never> 입니까? undefined 또는 null .

const exactOrderResponse: Exact<PlaceOrderResponse> = 
{
   status: 'paymentFailed',
   orderNumber: '1001',
   amountCharged: ????      
};

그래서 당신은 생각할 수 있습니다 - 그것은 여전히 ​​선택 사항이며 이제는 선택 사항 으로 번역되는 사항 입니다. 그리고 확실히 런타임 에는 설정하지 않아도 되지만 물음표를 붙여서 Exact<T> 를 '깨진' 것처럼 보입니다.

이 확인이 필요한 것은 두 유형 사이에 값을 할당할 때만 그럴까요? (둘 다 amountCharged?: number 포함하도록 하기 위해)

여기에 대화 상자의 입력 데이터에 대한 새로운 유형을 도입하겠습니다.

export type OrderDialogBoxData = { 
   status: 'success' | 'paymentFailed', 
   orderNumber: string
   amountCharge?: number      // note the typo here!
};

다음을 시도해 보겠습니다.

// run the API call and then assign it to a dialog box.
const serverResponse: Exact<PlaceOrderResponse> = await placeOrder();
const dialogBoxData: Exact<OrderDialogBoxData> = serverResponse;    // SHOULD FAIL

이 속성은 두 가지 모두에서 선택 사항이지만 오타로 인해 이것이 실패할 것으로 예상합니다.

그래서 나는 '애초에 우리가 이것을 원하는 이유는 무엇입니까?'로 돌아 왔습니다. .
나는 그것이 다음과 같은 이유 때문이라고 생각합니다(또는 상황에 따라 하위 집합).

• 속성 이름의 오타 방지
• 어떤 '구성요소'에 속성을 추가하면 그것을 사용하는 모든 것이 해당 속성도 추가해야 합니다.
• 일부 '구성요소'에서 속성을 제거하면 모든 곳에서 제거해야 합니다.
• 불필요하게 추가 속성을 제공하지 않는지 확인하십시오(아마도 우리는 그것을 API로 보내고 페이로드를 린 상태로 유지하기를 원할 것입니다).

'정확한 선택적 속성'이 제대로 처리되지 않으면 이러한 이점 중 일부가 손상되거나 크게 혼동됩니다!

또한 위의 예에서 우리는 오타를 피하기 위해 Exact 를 '구두부리'했지만 큰 혼란을 일으키는 데에만 성공했습니다! 그리고 지금은 그 어느 때보다 더 부서지기 쉽습니다.

내가 자주 필요로 하는 것은 실제로 Exact<T> 유형이 아니라 다음 두 가지 중 하나입니다.

NothingMoreThan<T> 또는
NothingLessThan<T>

'필수 선택 사항' 은 이제 일입니다. 첫 번째는 할당의 RHS에 의해 추가로 정의할 수 있는 것이 없고 두 번째는 할당의 RHS에 모든 항목(선택적 속성 포함)이 지정되었는지 확인합니다.

NothingMoreThan 는 유선 또는 JSON.stringify() 통해 전송된 페이로드에 유용하며 RHS에 너무 많은 속성이 있기 때문에 오류가 발생하는 경우에만 선택하도록 런타임 코드를 작성해야 합니다. 필요한 속성. 그것이 바로 자바스크립트가 작동하는 방식이기 때문입니다.

NothingLessThan 는 선택적 (optional?: number) 속성을 고려해야 한다는 점을 제외하고는 모든 일반 할당에 대해 typescript에 이미 있는 것과 같습니다.

이 이름이 관심을 끌 것으로 기대하지는 않지만 개념이 Exact<T> 보다 더 명확하고 세분화되어 있다고 생각합니다.

그런 다음 아마도 (정말 필요한 경우):

Exact<T> = NothingMoreThan<NothingLessThan<T>>;

또는 다음과 같을 것입니다.

Exact<T> = NothingLessThan<NothingMoreThan<T>>;   // !!

이 게시물은 일부 선택적 속성이 포함된 '대화 상자 데이터 유형'이 있고 서버에서 오는 내용이 할당 가능한지 확인하려는 오늘 겪고 있는 실제 문제의 결과입니다.

최종 참고 사항: NothingLessThan / NothingMoreThan 는 유형 A가 유형 B에서 확장되거나 B가 A에서 확장되는 위의 일부 주석과 유사한 '느낌'을 갖습니다. 선택적 속성을 다루지 않을 것입니다(적어도 오늘날에는 그렇게 할 수 없다고 생각합니다).

@simeyla "그 이상"변종으로 벗어날 수 있습니다.

• "이하"는 그냥 일반적인 유형입니다. TS는 이를 암시적으로 수행하며 모든 유형은 for all T extends X: T 와 동등하게 취급됩니다.
• "Nothing more than"은 기본적으로 반대입니다. 암시적 for all T super X: T

하나 또는 둘 다를 명시적으로 선택하는 방법으로 충분합니다. 부작용으로 Java의 T super C 를 제안된 T extends NothingMoreThan<C> 지정할 수 있습니다. 그래서 나는 이것이 아마도 표준 정확한 유형보다 나을 것이라고 확신합니다.

나는 이것이 구문이어야한다고 생각합니다. 아마도 이것은?

• extends T - T에 할당할 수 있는 모든 유형의 합집합, 즉 일반 T 합니다.
• super T - T가 할당 가능한 모든 유형의 합집합입니다.
• extends super T , super extends T - T에 해당하는 모든 유형의 합집합입니다. 유형만 할당 가능하고 자체적으로 할당될 수 있기 때문에 그리드에서 벗어납니다.
• type Exact<T> = extends super T - 가독성을 돕기 위해 위의 일반적인 경우에 설탕이 내장되어 있습니다.
• 이것은 할당 가능성을 토글하기 때문에 정확한 또는 상위 유형의 공용체와 같은 것을 여전히 가질 수 있습니다.

이것은 또한 Exact<{a: number}> | Exact<{b: number}> 와 같이 각 변형 Exact<T> 만들어 사용자 영역에서 #14094 를 구현할 수 있게 합니다.

이것이 사용자 영역에서 부정 유형을 가능하게 하는지도 궁금합니다. 나는 그것이 가능하다고 생각하지만 그것을 확인하기 위해 먼저 복잡한 유형 산술을 수행해야하며 증명할 것이 분명하지 않습니다.

(super T) | (확장 T)는 알 수 없음과 동일합니다. 나는 그렇다고 생각하지만 그것을 확인하기 위해 먼저 복잡한 유형 산술을 수행해야하며 증명할 수있는 분명한 것은 아닙니다.

(super T) | (extends T) === unknown 이 할당 가능성을 유지하려면 총 주문이 필요합니다.

@jack-williams 잘 잡혀 수정되었습니다(클레임 제거). 나는 조금 놀다가 처음에 일이 잘 풀리지 않는 이유가 궁금했다.

@잭윌리암스

"이하"는 그냥 일반적인 유형입니다. TS는 이를 암시적으로 수행하며 모든 유형은 동등하게 처리됩니다.

예, 아니요. 하지만 대부분 그렇습니다... ...하지만 strict 모드인 경우에만 가능합니다!

그래서 논리적으로 '선택적'이어야 하는 속성이 필요한 상황이 많았지만 컴파일러가 내가 '잊었거나' 철자가 틀린지 알려주기를 원했습니다.

글쎄, 그게 정확히 당신이 lastName: string | undefined 얻는 것입니다. 반면 저는 대부분 lastName?: string 얻었고, 물론 strict 모드가 없으면 모든 불일치에 대해 경고를 받지 않을 것입니다.

나는 항상 엄격 모드에 대해 알고 있었고 어제까지 그것을 켜지 않은 이유를 평생 동안 찾을 수 없었습니다. ) '즉시' 원하는 동작을 얻는 것이 훨씬 쉽습니다.

Required<A> extends Required<B> 를 가지고 노는 것과 ? 속성 플래그를 제거하려고 시도하는 것을 포함하여 원하는 것을 얻기 위해 모든 종류의 일을 시도했습니다. 그것은 나를 완전히 다른 토끼 구멍으로 보냈습니다. (그리고 이것은 내가 strict 모드를 켜기 전의 모든 것이었습니다).

요점은 오늘날 '정확한' 유형에 가까운 것을 얻으려면 strict 모드(또는 플래그 조합이 올바른 검사를 제공하는 모든 것)를 활성화하는 것으로 시작해야 한다는 것입니다. 그리고 나중에 middleName: string | undefined 를 추가해야 하는 경우 붐 - 갑자기 '고려'해야 하는 모든 곳에서 찾을 수 있습니다 :-)

추신. 의견 주셔서 감사합니다 - 매우 도움이되었습니다. 나는 분명히 strict 모드를 사용하지 않는 많은 코드를 보았다는 것을 깨닫고 있습니다. 그리고 나서 사람들은 저처럼 벽에 부딪힙니다. 더 많은 사용을 장려하기 위해 무엇을 할 수 있는지 궁금합니다.

@simeyla 귀하의 피드백과 감사는 @isiahmeadows에게 전달되어야 한다고 생각합니다!

기본 프로토타입을 구현한 후 Exact 유형에 대한 경험을 적어야겠다고 생각했습니다. 내 일반적인 생각은 팀이 평가를 제대로 수행했다는 것입니다.

우리의 희망적인 진단은 이것이 상대적으로 소수의 진정으로 폐쇄된 API를 제외하고는 XY 문제 솔루션이라는 것입니다.

나는 또 다른 객체 유형을 도입하는 비용이 더 많은 오류를 포착하거나 새로운 유형 관계를 활성화함으로써 갚는다고 생각하지 않습니다. 궁극적으로 정확한 유형을 사용하면 더 _말_할 수 있지만, 더는 _할_ 수 없습니다.

정확한 유형의 몇 가지 잠재적 사용 사례 조사:

keys 및 for ... in 대한 강력한 입력.

키를 열거할 때 보다 정확한 유형을 사용하는 것이 매력적으로 보이지만 실제로는 개념적으로 정확한 것에 대한 키를 열거하는 자신을 발견하지 못했습니다. 키를 정확히 알고 있다면 직접 주소를 지정하지 않는 이유는 무엇입니까?

강화 선택적 속성 확대.

할당 가능성 규칙 { ... } <: { ...; x?: T } 은 왼쪽 유형에 앨리어싱된 호환되지 않는 x 속성이 포함될 수 있기 때문에 올바르지 않습니다. 정확한 유형에서 할당할 때 이 규칙은 건전합니다. 실제로 저는 이 규칙을 사용하지 않습니다. 처음부터 정확한 유형이 없는 레거시 시스템에 더 적합해 보입니다.

반응 및 HOC

나는 props 전달을 개선하고 스프레드 유형을 단순화하는 정확한 유형에 마지막 희망을 걸었습니다. 현실은 정확한 유형이 제한된 다형성의 반대이고 근본적으로 비구성적이라는 것입니다.

제한된 제네릭을 사용하면 관심 있는 소품을 지정하고 나머지는 전달할 수 있습니다. 경계가 정확해지면 너비 하위 유형이 완전히 사라지고 제네릭이 훨씬 덜 유용해집니다. 또 다른 문제는 TypeScript의 주요 작성 도구 중 하나가 교차이지만 교차 유형은 정확한 유형과 호환되지 않는다는 것입니다. 정확한 구성 요소가 있는 중요하지 않은 교차 ​​유형은 비어 있습니다. _정확한 유형은 구성하지 않습니다_. react 및 props의 경우 행 유형과 행 다형성을 원할 수 있지만 이는 다른 날을 위한 것입니다.

정확한 유형으로 해결할 수 있는 거의 모든 흥미로운 버그는 초과 속성 검사로 해결됩니다. 가장 큰 문제는 차별적 속성이 없는 노동조합에 대해서는 과잉재산점검이 통하지 않는다는 점이다. 이것을 해결하면 정확한 유형과 관련된 거의 모든 흥미로운 문제가 사라집니다. IMO.

@jack-williams 정확한 유형을 갖는 것이 일반적으로 그다지 유용하지 않다는 데 동의합니다. 초과 속성 검사 개념은 실제로 내 super T 연산자 제안에 의해 다루어집니다. 단지 간접적으로 T가 할당할 수 있는 모든 유형의 합집합이 T의 적절한 하위 유형을 포함 하지 않기 때문 입니다.

나는 T super U *를 제외하고 개인적으로 이것을 크게 지지하지 않습니다. 초과 속성 검사에 대해 내가 경험 한 유일한 사용 사례는 고장난 서버를 다루는 것이었습니다. 일반적으로 다음을 통해 해결할 수 있습니다. 래퍼 기능을 사용하여 수동으로 요청을 생성하고 초과 쓰레기를 제거합니다. 지금까지 이 스레드에서 보고된 다른 모든 문제는 간단한 식별 조합을 사용하여 간단히 해결할 수 있습니다.

* 이것은 기본적으로 내 제안을 사용하여 T extends super U - 하한은 반공변(contravariant) 제네릭 유형을 제한하는 데 때때로 유용하며 해결 방법은 일반적으로 내 경험에 따라 많은 추가 유형 상용구를 도입하게 됩니다.

@isiahmeadows 저는 하한 유형이 유용할 수 있다는 데 확실히 동의하며, 그 중에서 정확한 유형을 얻을 수 있다면 사용하려는 사람들에게 유리합니다. 내 게시물에 경고를 추가해야 한다고 생각합니다. 즉, 저는 주로 정확한 개체 유형에 대해 특별히 새 연산자를 추가하는 개념을 다루고 있습니다.

@jack-williams 초과 재산 확인의 정확한 유형과 관련 부분을 주로 언급했다는 제 뉘앙스를 놓친 것 같습니다. 하한 유형에 대한 약간의 이유는 각주였습니다. 접선으로만 관련된 탈선이었습니다.

다양한 정확도가 필요한 함수 인수에 대해 작동하는 구현을 작성했습니다.

// Checks that B is a subset of A (no extra properties)
type Subset<A extends {}, B extends {}> = {
   [P in keyof B]: P extends keyof A ? (B[P] extends A[P] | undefined ? A[P] : never) : never;
}

// This can be used to implement partially strict typing e.g.:
// ('b?:' is where the behaviour differs with optional b)
type BaseOptions = { a: string, b: number }

// Checks there are no extra properties (Not More, Less fine)
const noMore = <T extends Subset<BaseOptions, T>>(options: T) => { }
noMore({ a: "hi", b: 4 })        //Fine
noMore({ a: 5, b: 4 })           //Error 
noMore({ a: "o", b: "hello" })   //Error
noMore({ a: "o" })               //Fine
noMore({ b: 4 })                 //Fine
noMore({ a: "o", b: 4, c: 5 })   //Error

// Checks there are not less properties (More fine, Not Less)
const noLess = <T extends Subset<T, BaseOptions>>(options: T) => { }
noLess({ a: "hi", b: 4 })        //Fine
noLess({ a: 5, b: 4 })           //Error
noLess({ a: "o", b: "hello" })   //Error
noLess({ a: "o" })               //Error  |b?: Fine
noLess({ b: 4 })                 //Error
noLess({ a: "o", b: 4, c: 5 })   //Fine

// We can use these together to get a fully strict type (Not More, Not Less)
type Strict<A extends {}, B extends {}> = Subset<A, B> & Subset<B, A>;
const strict = <T extends Strict<BaseOptions, T>>(options: T) => { }
strict({ a: "hi", b: 4 })        //Fine
strict({ a: 5, b: 4 })           //Error
strict({ a: "o", b: "hello" })   //Error
strict({ a: "o" })               //Error  |b?: Fine
strict({ b: 4 })                 //Error
strict({ a: "o", b: 4, c: 5 })   //Error

// Or a fully permissive type (More Fine, Less Fine)
type Permissive<A extends {}, B extends {}> = Subset<A, B> | Subset<B, A>;
const permissive = <T extends Permissive<BaseOptions, T>>(options: T) => { }
permissive({ a: "hi", b: 4 })        //Fine
permissive({ a: 5, b: 4 })           //Error
permissive({ a: "o", b: "hello" })   //Error
permissive({ a: "o" })               //Fine
permissive({ b: 4 })                 //Fine
permissive({ a: "o", b: 4, c: 5 })   //Fine

// This is a little unweildy, there's also a shortform that works in many cases:
type Exact<A extends {}> = Subset<A, A>
// The simpler Exact type works for variable typing
const options0: Exact<BaseOptions> = { a: "hi", b: 4 }        //Fine
const options1: Exact<BaseOptions> = { a: 5, b: 4 }           //Error
const options2: Exact<BaseOptions> = { a: "o", b: "hello" }   //Error
const options3: Exact<BaseOptions> = { a: "o" }               //Error |b?: Fine
const options4: Exact<BaseOptions> = { b: 4 }                 //Error
const options5: Exact<BaseOptions> = { a: "o", b: 4, c: 5 }   //Error

// It also works for function typing when using an inline value
const exact = (options: Exact<BaseOptions>) => { }
exact({ a: "hi", b: 4 })        //Fine
exact({ a: 5, b: 4 })           //Error
exact({ a: "o", b: "hello" })   //Error
exact({ a: "o" })               //Error  |b?: Fine
exact({ b: 4 })                 //Error
exact({ a: "o", b: 4, c: 5 })   //Error

// But not when using a variable as an argument even of the same type
const options6 = { a: "hi", b: 4 }
const options7 = { a: 5, b: 4 }
const options8 = { a: "o", b: "hello" }
const options9 = { a: "o" }
const options10 = { b: 4 }
const options11 = { a: "o", b: 4, c: 5 }
exact(options6)                 //Fine
exact(options7)                 //Error
exact(options8)                 //Error
exact(options9)                 //Error |b?: Fine
exact(options10)                //Error
exact(options11)                //Fine  -- Should not be Fine

// However using strict does work for that
// const strict = <T extends Strict<BaseOptions, T>>(options: T) => { }
strict(options6)                //Fine
strict(options7)                //Error
strict(options8)                //Error
strict(options9)                //Error |b?: Fine
strict(options10)               //Error
strict(options11)               //Error -- Is correctly Error

보다

https://www.npmjs.com/package/ts-strictargs
https://github.com/Kotarski/ts-strictargs

소품을 "통과"해야 하는 React 구성 요소를 래핑할 때 이에 대한 사용 사례가 있는 것 같습니다. https://github.com/Microsoft/TypeScript/issues/29883. @jack-williams 이에 대한 생각이 있으십니까?

@OliverJash 관련성이 있어 보이지만 React를 가장 잘 모른다는 것을 인정해야 합니다. 정확한 유형이 여기에서 정확히 도움이 될 수 있는 방법을 통해 작업하는 것이 도움이 될 것이라고 생각합니다.

type MyComponentProps = { foo: 1 };
declare const MyComponent: ComponentType<MyComponentProps>;

type MyWrapperComponent = MyComponentProps & { myWrapperProp: 1 };
const MyWrapperComponent: ComponentType<MyWrapperComponent> = props => (
    <MyComponent
        // We're passing too many props here, but no error!
        {...props}
    />
);

내가 틀린 말을 하면 언제든지 정정해 주세요.

정확한 유형을 허용하기 위해 MyComponent 를 지정하는 것이 시작이 될 것이라고 생각합니다.

declare const MyComponent: ComponentType<Exact<MyComponentProps>>;

이 경우 오류가 발생하지만 오류를 어떻게 수정합니까? 여기에서는 래퍼 구성 요소가 완전히 동일한 prop 유형을 갖고 있지 않으며 어느 시점에서 실제로 prop 하위 집합을 동적으로 추출해야 한다고 가정합니다. 이것은 합리적인 가정입니까?

MyWrapperComponent props도 정확하다면 destructuring bind를 하는 것으로 충분하다고 생각합니다. 일반적인 경우에는 정확한 유형보다 Omit 유형이 필요하며 그 의미를 잘 모르겠습니다. 나는 그것이 동형 매핑 유형처럼 작동하고 정확성을 유지할 수 있다고 생각하지만 이것은 더 많은 생각이 필요하다고 생각합니다.

MyWrapperComponent 가 정확하지 않은 경우 새 유형의 정확성을 증명하기 위해 런타임 검사가 필요합니다. 이는 원하는 속성을 명시적으로 선택해야만 수행할 수 있습니다(여기서 말한 대로 확장되지 않음 당신의 OP). 이 경우에 얼마나 많은 이익을 얻을 수 있을지 모르겠습니다.

props 가 일부 일반 유형이고 { ...props1, ...props2 } 와 같은 소품을 결합해야 하는 일반 경우일 가능성이 얼마나 되는지 모르기 때문에 다루지 않은 사항입니다. 이게 흔한 일인가요?

@Kotarski 혹시 NPM 레지스트리에 게시하셨나요?

@gitowiec

@Kotarski 혹시 NPM 레지스트리에 게시하셨나요?

https://www.npmjs.com/package/ts-strictargs
https://github.com/Kotarski/ts-strictargs

이 사용 사례가 있습니다.

type AB = { a: string, b: string }
type CD = { c: string, d: string }
type ABCD = AB & CD

// I want this to error, because the 'c' should mean it prevents either AB or ABCD from being satisfied.
const foo: AB | ABCD = { a, b, c };

// I presume that I would need to do this:
const foo: Exact<AB> | Exact<ABCD> = { a, b, c };

@ryami333 정확한 유형이 필요하지 않습니다. 초과 속성 검사에 대한 수정이 필요합니다: #13813.

@ryami333 추가 유형을 사용하려는 경우 원하는 대로 수행할 수 있는 유형 이 있습니다.

type AB = { a: string, b: string }
type CD = { c: string, d: string }
type ABCD = AB & CD


type UnionKeys<T> = T extends any ? keyof T : never;
type StrictUnionHelper<T, TAll> = T extends any ? T & Partial<Record<Exclude<UnionKeys<TAll>, keyof T>, never>> : never;
type StrictUnion<T> = StrictUnionHelper<T, T>

// Error now.
const foo: StrictUnion<AB | ABCD> = { a: "", b: "", c: "" };

@dragomirtitian 매력적 입니다. 왜인지 궁금하다

type KeyofV1<T extends object> = keyof T

과는 다른 결과를 낳는다

type KeyofV2<T> = T extends object ? keyof T : never

누군가 나에게 이것을 설명 할 수 있습니까?

type AB = { a: string, b: string }
type CD = { c: string, d: string }
type ABCD = AB & CD

KeyofV1< AB | ABCD > // 'a' | 'b'
KeyofV2< AB | ABCD > // 'a' | 'b' | 'c' | 'e'

V1 는 공용체의 공통 키를 가져오고 V2 는 각 공용체 구성원의 키를 가져오고 결과를 공용체로 만듭니다.

@weswigham 다른 결과를 반환해야 하는 이유가 있습니까?

예? 내가 말했듯이 - V1 때문에 인수에 모든 조합원에 _common의 keys_를 얻을 keyof 끝낸다 keyof (AB | ABCD) 단지 인을, "A" | "B" 반면, 조건부 내의 버전은 입력에 대한 조건부 배포 덕분에 한 번에 하나의 공용체 구성원만 수신하므로 기본적으로 keyof AB | keyof ABCD 입니다.

@weswigham 그래서 조건부는 암시적 루프를 통해 이와 같이 평가합니까?

type Union =
    (AB extends object ? keyof AB : never) |
    (ABCD extends object ? keyof ABCD : never)

해당 코드를 읽을 때 일반적으로 (AB | ABCD) extends object 검사가 단일 단위로 작동할 것으로 예상하고 (AB | ABCD) 가 object 할당 가능한지 확인한 다음 keyof (AB | ABCD) 반환합니다. 'a' | 'b' . 암시적 매핑은 나에게 정말 이상하게 보입니다.

@isiahmeadows 분배 조건부 유형을 공용체에 대한 foreach로 볼 수 있습니다. 그들은 조합의 각 구성원에 조건부 유형을 차례로 적용하고 결과는 각 부분 결과의 합집합입니다.

그래서 UnionKeys<A | B> = UnionKeys<A> | UnionKeys<B> =(keyof A) | (keyof B)

그러나 조건부 유형이 배포되는 경우에만, 테스트된 유형이 네이키드 유형 매개변수인 경우에만 배포됩니다. 그래서:

type A<T> = T extends object ? keyof T : never // distributive
type B<T> = [T] extends [object] ? keyof T : never // non distributive the type parameter is not naked
type B<T> = object extends T ? keyof T : never // non distributive the type parameter is not the tested type

고마워 얘들아, 내가 얻은 것 같아. 이해를 돕기 위해 다시 정리했습니다. NegativeUncommonKeys 그 자체로도 유용하다고 생각합니다. 다른 사람에게도 유용한 경우를 대비하여 여기에 있습니다.

type UnionKeys<T> = T extends any ? keyof T : never;
type NegateUncommonKeys<T, TAll> = (
    Partial<
        Record<
            Exclude<
                UnionKeys<TAll>,
                keyof T
            >,
            never
        >
    >
) 

type StrictUnion<T, TAll = T> = T extends any 
  ? T & NegateUncommonKeys<T, TAll>
  : never;

또한 T 및 TAll 가 모두 있는 이유도 이해합니다. T가 테스트되고 노출되지 않은 "루프 효과"는 T 에 대한 통합의 각 항목이 적용되는 반면 테스트되지 않은 TAll 에는 모든 항목의 원래 완전한 통합이 포함됩니다.

이것은 분배 조건부 유형에 대한

@weswigham 예 .. 섹션이 다른 컴파일러 엔지니어를 위해 한 컴파일러 엔지니어가 작성한 것처럼 읽는 것을 제외하고는.

확인된 유형이 네이키드 유형 매개변수인 조건부 유형을 분배 조건부 유형이라고 합니다.

네이키드 유형 매개변수란 무엇입니까? (그리고 그들은 옷을 좀 입는 게 어때요 😄)

즉, T는 조건형이 공용체형에 분산된 후의 개별 구성요소를 나타냄)

바로 어제 저는 이 특정 문장이 의미하는 바와 '후'라는 단어가 강조된 이유에 대해 토론했습니다.

사용자가 항상 가지고 있지는 않을 수도 있는 사전 지식과 용어를 가정하여 문서를 작성했다고 생각합니다.

핸드북 섹션은 나에게 의미가 있고 훨씬 더 잘 설명되어 있지만 여전히 디자인 선택에 회의적입니다. 그 행동이 집합 이론 및 유형 이론 관점에서 어떻게 자연스럽게 따를지 논리적으로 이해되지 않습니다. 그것은 조금 너무 해킹처럼 보입니다.

집합 이론 및 유형 이론 관점에서 자연스럽게 따릅니다.

세트의 각 항목을 취하고 술어에 따라 분할하십시오.

배포 작업입니다!

세트의 각 항목을 취하고 술어에 따라 분할하십시오.

범주 이론과 훨씬 더 비슷하게 들리기 시작하는 집합 집합(즉, 공용체 유형)에 대해 이야기할 때만 의미가 있습니다.

좋아 @RyanCavanaugh, 그래서 나를 명확히하자 : 나는 직관적으로 읽을 T extends U ? F<T> : G<T> 같이 T <: U ⊢ F(T), (T <: U ⊢ ⊥) ⊢ G(T) 비교가 아니라 완전한 단계로하지 구분 완료와 함께. 이는 현재 의미 체계인 "for all {if t ∈ U then F({t}) else G({t}) | t ∈ T} 의 합집합"과 분명히 다릅니다.

(내 구문이 약간 틀려도 용서하십시오. 내 유형 이론 지식은 완전히 독학이므로 구문 형식을 모두 알지 못한다는 것을 압니다.)

어떤 작업이 더 직관적인지는 무한한 논쟁의 여지가 있지만 현재 규칙에서는 [T] extends [C] 를 사용하여 분배 유형을 비분배 유형으로 만드는 것이 쉽습니다. 기본값이 분배되지 않는 경우 분배를 유발하려면 다른 수준에서 몇 가지 새로운 주문이 필요합니다. 그것은 또한 어떤 행동이 더 자주 선호되는 것과는 별개의 질문입니다. IME 비 배포 유형을 거의 원하지 않습니다.

예, 배포에 대한 강력한 이론적 근거는 구문 작업이기 때문에 없습니다.

현실은 매우 유용하며 다른 방식으로 인코딩하려고 하면 고통스러울 것입니다.

그대로, 나는 대화가 주제에서 너무 멀어지기 전에 계속 진행하겠습니다.

이미 배포성에 관한 문제가 너무 많은데, 새로운 구문이 필요하다는 사실에 직면하지 않는 이유는 무엇입니까?

30572

다음은 예제 문제입니다.

내 사용자 API 끝점/서비스가 서비스 인터페이스에 지정된 것 이외의 추가 속성(예: 암호)을 반환하지 않아야 한다고 지정하고 싶습니다. 실수로 추가 속성이 있는 개체를 반환하면 결과 개체가 개체 리터럴에 의해 생성되었는지 여부에 관계없이 컴파일 시간 오류가 발생합니다.

반환된 모든 객체의 런타임 검사는 특히 배열의 경우 비용이 많이 들 수 있습니다.

이 경우 과도한 속성 검사는 도움이 되지 않습니다. 솔직히, 나는 그것이 이상한 원트릭 포니 솔루션이라고 생각합니다. 이론상으로는 "그냥 작동하는" 종류의 경험을 제공해야 합니다. 실제로 는 혼란의 원인이기도 합니다. 대신 정확한 개체 유형을 구현해야 했으며 두 사용 사례를 모두 훌륭하게 처리했을 것입니다.

@babakness 당신의 타입은 NoExcessiveProps 입니다. 나는 그들이 다음과 같은 것을 의미한다고 생각합니다.

interface API {
    username: () => { username: string }
}

const api: API = {
    username: (): { username: string } => {
        return { username: 'foobar', password: 'secret'} // error, ok
    }
}

const api2: API = {
    username: (): { username: string } => {
        const id: <X>(x: X) => X = x => x;
        const value = id({ username: 'foobar', password: 'secret' });
        return value  // no error, bad?
    }
}

API 유형의 작성자는 username 가 사용자 이름을 반환하도록 강제하고 싶지만 객체 유형에는 너비 제한이 없기 때문에 구현자는 이 문제를 해결할 수 있습니다. 그것은 구현자가 할 수도 있고하지 않을 수도 있는 리터럴의 초기화에만 적용될 수 있습니다. 하지만 정확한 유형을 언어 기반 보안으로 사용하지 않는 것이 좋습니다.

@spion

이 경우 과도한 속성 검사는 도움이 되지 않습니다. 솔직히, 나는 그것이 이상한 원트릭 포니 솔루션이라고 생각합니다. 이론적으로 그들은 "그냥 작동하는" 종류의 경험을 제공했어야 했습니다.

EPC는 많은 문제를 커버하는 합리적으로 합리적이고 가벼운 디자인 선택입니다. 현실은 정확한 유형이 '그냥 작동'하지 않는다는 것입니다. 확장성을 지원하는 건전한 방식으로 구현하려면 완전히 다른 유형의 시스템이 필요합니다.

@jack-williams 물론 존재를 확인하는 다른 방법도 있지만(성능이 문제가 아닌 런타임 검사, 테스트 등) 빠른 피드백을 위해서는 추가 컴파일 시간이 매우 중요합니다.

또한 정확한 유형이 "그냥 작동"한다는 의미는 아닙니다. 나는 EPC가 "그냥 작동"하도록 의도되었지만 실제로는 제한적이고 혼란스럽고 안전하지 않다는 것을 의미했습니다. 주로 "고의적으로" 사용하려고 하면 일반적으로 발에 총을 쏘게 되기 때문입니다.

편집: 예, 혼란을 깨달았을 때 "그들"을 "그것"으로 바꾸도록 편집했습니다.

@spion

또한 정확한 유형이 "그냥 작동"한다는 의미는 아닙니다. 나는 EPC가 "그냥 작동"하도록 의도되었지만 실제로는 제한적이고 혼란스럽고 안전하지 않다는 것을 의미했습니다. 주로 "고의적으로" 사용하려고 하면 일반적으로 발에 총을 쏘게 되기 때문입니다.

내 실수. 원래 주석을 다음과 같이 읽으십시오.

이론적으로 그들은 "그냥 작동하는" 종류의 경험을 제공했어야 했습니다. [EPC 대신 정확한 유형이었을 것입니다]

[]의 주석은 내 독서입니다.

수정된 진술:

이론적으로는 제공 한한다 경험의 종류를 "그냥 작동"

훨씬 더 명확합니다. 오해해서 죄송합니다!

type NoExcessiveProps<O> = {
  [K in keyof O]: K extends keyof O ? O[K] : never 
}

// no error
const getUser1 = (): {username: string} => {
  const foo = {username: 'foo', password: 'bar' }
  return foo 
} 

// Compile-time error, OK
const foo: NoExcessiveProps<{username: string}>  = {username: 'a', password: 'b' }

// No error? 🤔
const getUser2 = (): NoExcessiveProps<{username: string}> => {
  const foo = {username: 'foo', password: 'bar' }
  return foo 
}

getUser2 대한 결과는 놀랍고 일관성이 없고 컴파일 시간 오류를 생성 해야 하는 것처럼 느껴집니다. 그렇지 않은 이유에 대한 통찰력은 무엇입니까?

@babakness 귀하는 NoExcessiveProps 그냥 평가 T (같은 키를 잘 유형 T ). 에서 [K in keyof O]: K extends keyof O ? O[K] : never , K 항상의 열쇠가 될 것입니다 O 당신이 이상 매핑하기 때문에 keyof O . const 예제 오류는 {username: string} 로 입력했을 때와 마찬가지로 EPC를 트리거하기 때문입니다.

추가 함수를 호출하는 것이 마음에 들지 않으면 전달된 객체의 실제 유형을 캡처하고 초과 속성 검사의 사용자 정의 양식을 수행할 수 있습니다. (요점은 이러한 유형의 오류를 자동으로 잡아내는 것이므로 가치가 제한적일 수 있음을 알고 있습니다.)

function checked<T extends E, E>(o: T & Record<Exclude<keyof T, keyof E>, never>): E {
    return o;
}

const getUser2 = (): { username: string } => {
    const foo = { username: 'foo', password: 'bar' }
    return checked(foo) //error
}
const getUser3 = (): { username: string } => {
    const foo = { username: 'foo' }
    return checked(foo) //ok
}

@dragomirtitian 아... 맞아요... 좋은 지적입니다! 그래서 귀하의 checked 기능을 이해하려고 합니다. 나는 특히 어리둥절하다.

const getUser2 = (): { username: string } => {
    const foo = { username: 'foo', password: 'bar' }
    const bar = checked(foo) // error
    return checked(foo) //error
}
const getUser3 = (): { username: string } => {
    const foo = { username: 'foo' }
    const bar = checked(foo) // error!?
    return checked(foo) //ok
}

bar 에 할당 getUser3 실패합니다. foo 오류가 있는 것 같습니다.

오류 세부정보

여기서 bar 의 유형은 {} . 이는 checked 때문인 것 같습니다.

function checked<T extends E, E>(o: T & Record<Exclude<keyof T, keyof E>, never>): E {
    return o;
}

E 는 어디에도 할당되지 않습니다. 그러나 typeof E 를 typeof {} 로 바꾸면 작동하지 않습니다.

E의 유형은 무엇입니까? 어떤 종류의 상황 인식 일이 일어나고 있습니까?

@babakness 유형 매개변수를 유추할 다른 위치가 없으면 typescript는 반환 유형에서 이를 유추합니다. 그래서 우리는 결과에 할당하는 경우 checked 의 반환에 getUser* , E 반환 함수의 유형 및 될 것입니다 T 될 것입니다 반환하려는 값의 실제 유형입니다. E 를 유추할 곳이 없으면 기본값은 {} 이므로 항상 오류가 발생합니다.

내가 이렇게 한 이유는 명시적 유형 매개변수를 피하기 위한 것이므로 더 명시적인 버전을 만들 수 있습니다.

function checked<E>() {
    return function <T extends E>(o: T & Record<Exclude<keyof T, keyof E>, never>): E {
        return o;
    }
}

const getUser2 = (): { username: string } => {
    const foo = { username: 'foo', password: 'bar' }
    return checked<{ username: string }>()(foo) //error
}
const getUser3 = (): { username: string } => {
    const foo = { username: 'foo' }
    return checked<{ username: string }>()(foo) //ok
}

참고: 아직 부분 인수 유추(https://github.com/Microsoft/TypeScript/pull/26349)가 없으므로 커리 함수 접근 방식이 필요합니다. 같은 전화. 이 문제를 해결하기 위해 첫 번째 호출에서 E 를 지정하고 두 번째 호출에서 T 를 유추합니다. 특정 유형에 대해 cache 함수를 캐시하고 캐시된 버전을 사용할 수도 있습니다.

function checked<E>() {
    return function <T extends E>(o: T & Record<Exclude<keyof T, keyof E>, never>): E {
        return o;
    }
}
const checkUser = checked<{ username: string }>()

const getUser2 = (): { username: string } => {
    const foo = { username: 'foo', password: 'bar' }
    return checkUser(foo) //error
}
const getUser3 = (): { username: string } => {
    const foo = { username: 'foo' }
    return checkUser(foo) //ok
}

FWIW 이것은 "노출된" 메서드에서 실수로 추가 속성을 반환하지 않는 특정 문제를 해결하는 WIP/스케치 tslint 규칙입니다.

https://gist.github.com/spion/b89d1d2958f3d3142b2fe64fea5e4c32

확산 사용 사례의 경우( https://github.com/Microsoft/TypeScript/issues/12936#issuecomment -300382189 참조) 린터가 이와 같은 패턴을 감지하고 유형이 안전하지 않다고 경고할 수 있습니까?

앞서 언급한 주석에서 코드 예제 복사:

interface State {
   name: string;
}
function nameReducer(state: State, action: Action<string>): State {
   return {
       ...state,
       fullName: action.payload // compiles, but it's an programming mistake
   }
}

cc @JamesHenry / @armano2

그런 일이 일어나는 것을 매우 보고 싶습니다. GraphQL 끝점에 대해 생성된 TypeScript 정의를 사용하고 GraphQL이 런타임에 이러한 쿼리를 실행하지 못하기 때문에 쿼리에 필요한 것보다 더 많은 필드가 있는 개체를 전달할 때 TypeScript에서 오류가 발생하지 않는 것이 문제입니다.

할당 중 추가 속성을 더 잘 확인하는 3.5.1 업데이트로 이 중 얼마나 많은 문제가 해결되었습니까? 3.5.1로 업그레이드한 후 원하는 방식으로 알려진 문제 영역을 오류로 표시했습니다.

문제가 있고 정확한 유형이 올바른 솔루션이라고 생각하는 경우 여기에 원래 문제를 설명하세요.

https://github.com/microsoft/TypeScript/issues/12936#issuecomment -284590083

다음은 React 참조 와 관련된 것입니다.

/cc @RyanCavanaugh

나를 위한 한 가지 사용 사례는

export const mapValues =
  <T extends Exact<T>, V>(object: T, mapper: (value: T[keyof T], key: keyof T) => V) => {
    type TResult = Exact<{ [K in keyof T]: V }>;
    const result: Partial<TResult> = { };
    for (const [key, value] of Object.entries(object)) {
      result[key] = mapper(value, key);
    }
    return result as TResult;
  };

object 에 추가 속성이 있는 경우 이러한 추가 키와 값에 대해 mapper 를 호출하는 것이 안전하지 않기 때문에 정확한 유형을 사용하지 않으면 이것은 불건전합니다.

여기서 진정한 동기는 코드에서 재사용할 수 있는 열거형 값을 갖고 싶어한다는 것입니다.

const choices = { choice0: true, choice1: true, choice2: true };
const callbacksForChoices = mapValues(choices, (_, choice) => () => this.props.callback(choice));

여기서 this.props.callback 유형은 (keyof typeof choices) => void 입니다.

따라서 실제로는 유형 시스템이 유형 랜드의 키 집합(예: 공용체)과 정확히 일치하는 코드 랜드의 키 목록이 있다는 사실을 나타낼 수 있으므로 이에 대해 작동하는 함수를 작성할 수 있습니다. 키 목록을 작성하고 결과에 대해 유효한 유형 어설션을 작성하십시오. 유형 시스템이 아는 한, 코드 랜드 객체는 사용되는 객체 유형 이외의 추가 속성을 가질 수 있기 때문에 객체(이전 예에서 choices )를 사용할 수 없습니다. 우리는 배열 (사용할 수 없습니다 ['choice0', 'choice1', 'choice2'] as const 멀리 타입 시스템이 알고있는대로 배열은 배열 형식에서 허용하는 모든 키를 포함하지 않을 수 있기 때문입니다.

아마도 exact 는 유형이 아니라 함수의 입력 및/또는 출력에 대한 수정자여야 합니까? 흐름의 분산 수정자( + / - )와 같은 것

@phaux가 방금 말한 것에 Exact 대한 실제 용도는 컴파일러가 함수의 모양을 보장하도록 하는 것입니다. 프레임워크가 있으면 (T, S): AtMost<T> , (T, S): AtLeast<T> 또는 (T, S): Exact<T> 중 하나를 원할 수 있습니다. 여기서 컴파일러는 사용자가 정의한 기능이 정확히 맞는지 확인할 수 있습니다.

몇 가지 유용한 예:
AtMost 는 구성에 유용합니다(따라서 추가 매개변수/오타를 무시하고 조기에 실패하지 않습니다).
AtLeast 는 사용자가 원하는 추가 항목을 개체에 밀어 넣을 수 있는 반응 구성 요소 및 미들웨어와 같은 항목에 적합합니다.
Exact 는 직렬화/역직렬화에 유용합니다(데이터를 삭제하지 않고 동형임을 보장할 수 있습니다).

이런 일이 발생하는 것을 방지하는 데 도움이 될까요?

interface IDate {
  year: number;
  month: number;
  day: number;
}

type TBasicField = string | number | boolean | IDate;

 // how to make this generic stricter?
function doThingWithOnlyCorrectValues<T extends TBasicField>(basic: T): void {
  // ... do things with basic field of only the exactly correct structures
}

const notADate = {
  year: 2019,
  month: 8,
  day: 30,
  name: "James",
};

doThingWithOnlyCorrectValues(notADate); // <- this should not work! I want stricter type checking

TS에서 T extends exactly { something: boolean; } ? xxx : yyy 라고 말하는 방법이 정말 필요합니다.

또는 다음과 같습니다.

const notExact = {
  something: true,
  name: "fred",
};

여전히 xxx 반환합니다.

const 키워드를 사용할 수 있습니까? 예: T extends const { something: boolean }

@pleerock JavaScript / TypeScript에서와 같이 변수를 const 로 정의할 수 있지만 여전히 개체 속성을 추가/제거할 수 있으므로 약간 모호할 수 있습니다. exact 라는 키워드가 포인트라고 생각합니다.

정확히 관련이 있는지 확실하지 않지만 이 경우 최소 두 가지 오류가 예상됩니다.
운동장

@mityok 나는 그것이 관련이 있다고 생각합니다. 나는 당신이 다음과 같은 라인을 따라 무언가를하고 싶어한다고 생각합니다.

class Animal {
  makeSound(): exact Foo {
     return { a: 5 };
  }
}

exact 가 유형을 더 엄격하게 만든 경우 Dog 에서 한 것처럼 추가 속성으로 확장할 수 없습니다.

const ( as const )를 활용하고 다음과 같은 인터페이스 및 유형 전에 사용

const type WillAcceptThisOnly = number

function f(accept: WillAcceptThisOnly) {
}

f(1) // error
f(1 as WillAcceptThisOnly) // ok, explicit typecast

const n: WillAcceptThisOnly = 1
f(n) // ok

const 변수에 할당해야 하는 것은 정말 장황하지만, 예상한 것과 정확히 일치하지 않는 typealias를 전달할 때 많은 경우를 피할 수 있습니다.

저는 Exact<T> 문제에 대한 순수한 TypeScript 솔루션을 생각해 냈습니다. 이 솔루션은 메인 포스트에서 요청한 것과 똑같이 동작합니다.

// (these two types MUST NOT be merged into a single declaration)
type ExactInner<T> = <D>() => (D extends T ? D : D);
type Exact<T> = ExactInner<T> & T;

function exact<T>(obj: Exact<T> | T): Exact<T> {
    return obj as Exact<T>;
};

ExactInner 가 Exact 포함되지 않아야 하는 이유는 #32824 수정 사항이 아직 릴리스되지 않았기 때문입니다(그러나 이미 !32924에 병합

오른쪽 표현식도 Exact<T> 인 경우 Exact<T> 유형의 변수 또는 함수 인수에만 값을 할당할 수 있습니다. 여기서 T 는 두 부분에서 정확히 동일한 유형입니다. 할당의.

값을 Exact 유형으로 자동 승격하지 않았으므로 exact() 도우미 기능이 사용됩니다. 모든 값은 정확한 유형으로 승격될 수 있지만 TypeScript가 표현식의 두 부분 모두의 기본 유형이 확장 가능할 뿐만 아니라 정확히 동일함을 증명할 수 있는 경우에만 할당이 성공합니다.

TypeScript가 extend 관계 검사를 사용하여 오른손 유형이 왼손 유형에 할당될 수 있는지 여부를 결정한다는 사실을 이용하여 작동합니다. .

인용 checker.ts ,

// 두 개의 조건부 유형 'T1 extends U1 ? X1 : Y1' 및 'T2는 U2를 확장합니까? X2 : Y2'는 다음과 같은 경우 관련이 있습니다.
// T1과 T2 중 하나는 다른 하나와 관련되고 U1과 U2는 동일한 유형이며 X1은 X2와 관련되며
// Y1은 Y2와 관련이 있습니다.

ExactInner<T> 제네릭은 U1 및 U2 를 정확성 검사가 필요한 기본 유형으로 대체하여 설명된 접근 방식을 사용합니다. Exact<T> 는 대상 변수 또는 함수 인수가 정확한 유형이 아닐 때 TypeScript가 정확한 유형을 완화할 수 있도록 일반 기본 유형과의 교차를 추가합니다.

프로그래머의 관점에서, Exact<T> 행동한다 그것에는 설정 것처럼 exact 에 플래그 T 검사없이 T 그리고 독립적 형태를 생성하지 않고 또는 변화.

여기 플레이그라운드 링크 와 요지 링크가 있습니다.

가능한 향후 개선 사항은 정확하지 않은 유형을 정확한 유형으로 자동 승격하여 exact() 기능의 필요성을 완전히 제거하는 것입니다.

멋진 작품 @toriningen!

exact 호출에서 값을 래핑하지 않고도 이 작업을 수행할 수 있는 방법을 찾을 수 있는 사람이 있다면 완벽할 것입니다.

이것이 올바른 문제인지 확실하지 않지만 여기에 내가 일하고 싶은 것의 예가 있습니다.

https://www.typescriptlang.org/play/#code/KYOwrgtgBAyg9gJwC4BECWDgGMlriKAbwCgooBBAZyygF4oByAQ2oYBpSoVhq7GATHlgbEAvsWIAzMCBx4CTfvwDyCQQgBCATwAU -DNlz4AXFABE5GAGEzUAD7mUAUWtmAlEQnjiilWuCauvDI6Jhy + AB0VFgRSHAAqgAOiQFWLMA6bm4A3EA

enum SortDirection {
  Asc = 'asc',
  Desc = 'desc'
}
function addOrderBy(direction: "ASC" | "DESC") {}
addOrderBy(SortDirection.Asc.toUpperCase());

@lookfirst 다릅니다. 이것은 {foo: 1, bar: 2} 를 할당할 수 없는 exact {foo: number} 유형과 같이 추가 속성을 허용하지 않는 유형에 대한 기능을 요구합니다. 존재하지 않을 가능성이 있는 열거형 값에 적용할 텍스트 변환을 요청하는 것입니다.

이것이 올바른 문제인지 확실하지 않지만 [...]

다른 곳에서 유지 관리인으로서의 나의 경험에 따르면, 의심스럽고 명확한 기존 문제를 찾을 수 없다면 새로운 버그와 최악의 시나리오를 제출하고 찾지 못한 속임수로 마감됩니다. 이것은 대부분의 주요 오픈 소스 JS 프로젝트의 경우입니다. (JS 커뮤니티에서 우리 대부분의 더 큰 유지 관리자는 실제로 괜찮은 사람들입니다. 버그 보고서 등으로 인해 정말 수렁에 빠질 수 있으므로 때때로 정말 간결하지 않기가 어렵습니다.)

@isiahmeadows 답변 감사합니다. 중복 문제를 먼저 검색했기 때문에 새 문제를 제출하지 않았습니다. 이것이 올바른 방법입니다. 나는 이것이 올바른 문제인지 아닌지 또는 내가 말하는 것을 분류하는 방법조차 확신하지 못했기 때문에 사람들을 당황하게 만들지 않으려고 노력했습니다.

다른 샘플 사용 사례:

https://www.typescriptlang.org/play/index.html#code/JYOwLgpgTgZghgYwgAgIoFdoE8AKcpwC2EkUAzsgN4BQydycAXMmWFKAOYDct9ARs1bsQ3agF9q1GOhAIwwAPYhkCKBDiQAKgAtgUACZ4oYXHA4QAqgCUAMgAoAjpiimChMswzYjREtDIAlFS8dGpg6FDKAAbaYGAADh4A9EkQAB5E8QA2EAB0CAqESQD8ACSUIBAA7sjWNgDK6lAI2j7udgDyfABWEHK5EODsEGSOzq5EgQFiUeKSKcgAolBQCuQANAwU6fF9kPrUqupaugZGJnjmdXaUDMwA5PebAsiPmwgPYLpkALTx + EQflVgFksj8EHB0GQID8vnp9H98CZEeZYQpwQQyNp7sgxAEeIclKxkP83BQALxUO6vJ7IF5vFSfb6ItxAkFgiFQmFwgws5H-VFgdGqOBYnFiAkLQC8G4BGPeQJl2Km0fQA1pxkPoIDBjhB9HSsFsyMAOCB1cAwPKFAwSQDiKRDmoNBAdPDzqYrrY7KTJvigA

편집됨: @aigoncharov 솔루션 이 더 빠르다고 생각하기 때문에 @aigoncharov 솔루션을 확인하십시오.

type Exact<T, R> = T extends R
  ? R extends T
    ? T
    : never
  : never

이것이 더 개선될 수 있을지 모르겠습니다.

type Exact<T, Shape> =
    // Check if `T` is matching `Shape`
    T extends Shape
        // Does match
        // Check if `T` has same keys as `Shape`
        ? Exclude<keyof T, keyof Shape> extends never
            // `T` has same keys as `Shape`
            ? T
            // `T` has more keys than `Shape`
            : never
        // Does not match at all
        : never;

type InexactType = {
    foo: string
}

const obj = {
    foo: 'foo',
    bar: 'bar'
}

function test1<T>(t: Exact<T, InexactType>) {}
function test2(t: InexactType) {}

test1(obj) // $ExpectError
test2(obj)

코멘트를하지 않고

type ExactKeys<T1, T2> = Exclude<keyof T1, keyof T2> extends never
    ? T1
    : never

type Exact<T, Shape> = T extends Shape
    ? ExactKeys<T, Shape>
    : never;

이것이 더 개선될 수 있을지 모르겠습니다.

type Exact<T, Shape> =
    // Check if `T` is matching `Shape`
    T extends Shape
        // Does match
        // Check if `T` has same keys as `Shape`
        ? Exclude<keyof T, keyof Shape> extends never
            // `T` has same keys as `Shape`
            ? T
            // `T` has more keys than `Shape`
            : never
        // Does not match at all
        : never;

type InexactType = {
    foo: string
}

const obj = {
    foo: 'foo',
    bar: 'bar'
}

function test1<T>(t: Exact<T, InexactType>) {}
function test2(t: InexactType) {}

test1(obj) // $ExpectError
test2(obj)

코멘트를하지 않고

type ExactKeys<T1, T2> = Exclude<keyof T1, keyof T2> extends never
    ? T1
    : never

type Exact<T, Shape> = T extends Shape
    ? ExactKeys<T, Shape>
    : never;

그 아이디어를 좋아하세요!

작업을 수행할 수 있는 또 다른 트릭은 양방향에서 할당 가능성을 확인하는 것입니다.

type Exact<T, R> = T extends R
  ? R extends T
    ? T
    : never
  : never

type A = {
  prop1: string
}
type B = {
  prop1: string
  prop2: string
}
type C = {
  prop1: string
}

type ShouldBeNever = Exact<A, B>
type ShouldBeA = Exact<A, C>

http://www.typescriptlang.org/play/#code/C4TwDgpgBAogHgQwMbADwBUA0UBKA + KAXinSgjmAgDsATAZ1wCgooB + XMi6 + k5lt3vygAuKFQgA3CACc + o8VNmNQkKAEEiUAN58w0gPZgAjKLrBpASyoBzRgF9l4aACFNOlnsMmoZyzd0GYABMpuZWtg4q0ADCbgFeoX4RjI6qAMoAFvoArgA2NM4QAHKSMprwyGhq2M54qdCZOfmFGsQVKKjVUNF1QkA

@iamandrewluca의 또 다른 놀이터 https://www.typescriptlang.org/play/?ssl=7&ssc=6&pln=7&pc=17#code/C4TwDgpgBAogHgQwMbADwBUA0UBKA + KAXinSgjmAgDsATAZ1wCgooB + XMi6 + k5lt3vygAuKFQgA3CACc + o8VNmNQkKAElxiFOnDRiAbz4sAZgHtTousGkBLKgHNGAX0aMkpqlaimARgCsiKEMhMwsoAHJQ8MwjKB8EaVFw + Olw51djAFcqFBsPKEorAEYMPAAKYFF4ZDQsdU0anUg8AEoglyyc4DyqAogrACYK0Q1yRt02-RdlfuAist8-NoB6ZagAEnhIFBhpaVNZQuAhxZagA

여기서 미묘한 차이는 Exact<{ prop1: 'a' }> 를 Exact<{ prop1: string }> 할당할 수 있어야 하는지 여부입니다. 내 사용 사례에서는 그래야 합니다.

@jeremybparagon 귀하의 사례가 적용되었습니다. 여기에 몇 가지 더 많은 사례가 있습니다.

type InexactType = {
    foo: 'foo'
}

const obj = {
    // here foo is infered as `string`
    // and will error because `string` is not assignable to `"foo"`
    foo: 'foo',
    bar: 'bar'
}

function test1<T>(t: Exact<T, InexactType>) {}
function test2(t: InexactType) {}

test1(obj) // $ExpectError
test2(obj) // $ExpectError

type InexactType = {
    foo: 'foo'
}

const obj = {
    // here we cast to `"foo"` type
    // and will not error
    foo: 'foo' as 'foo',
    bar: 'bar'
}

function test1<T>(t: Exact<T, InexactType>) {}
function test2(t: InexactType) {}

test1(obj) // $ExpectError
test2(obj)

type Exact<T, R> = T extends R
  ? R extends T
    ? T
    : never
  : never

이 트릭을 사용하는 사람은 (유효한 용도가 없다고 말하는 것이 아닙니다) "정확한" 유형에서 더 많은 소품을 얻는 것이 매우 쉽다는 사실을 잘 알고 있어야 합니다. InexactType 는 Exact<T, InexactType> 할당할 수 있으므로 이와 같은 항목이 있으면 자신도 모르게 정확성에서 벗어나게 됩니다.

function test1<T>(t: Exact<T, InexactType>) {}

function test2(t: InexactType) {
  test1(t); // inexactType assigned to exact type
}
test2(obj) // but 

놀이터 링크

이것이 TS에 정확한 유형이 없는 이유(최소한 하나)입니다. 정확하지 않은 유형이 정확한 유형에 할당될 수 없는 정확한 유형과 정확하지 않은 유형의 완전한 분기가 필요하기 때문입니다. 액면 그대로 그들은 호환됩니다. 정확하지 않은 유형에는 항상 더 많은 속성이 포함될 수 있습니다. (적어도 이것은 @ahejlsberg가 tsconf로 언급된 이유 중 하나였습니다).

asExact 이 정확한 객체를 표시하는 구문적 방법인 경우 이러한 솔루션은 다음과 같을 수 있습니다.

declare const exactMarker: unique symbol 
type IsExact = { [exactMarker]: undefined }
type Exact<T extends IsExact & R, R> =
  Exclude<keyof T, typeof exactMarker> extends keyof R? T : never;

type InexactType = {
    foo: string
}
function asExact<T>(o: T): T & IsExact { 
  return o as T & IsExact;
}

const obj = asExact({
  foo: 'foo',
});


function test1<T extends IsExact & InexactType>(t: Exact<T, InexactType>) {

}

function test2(t: InexactType) {
  test1(t); // error now
}
test2(obj) 
test1(obj);  // ok 

const obj2 = asExact({
  foo: 'foo',
  bar: ""
});
test1(obj2);

const objOpt = asExact < { foo: string, bar?: string }>({
  foo: 'foo',
  bar: ""
});
test1(objOpt);

놀이터 링크

@dragomirtitian 그래서 제가 조금 더 일찍 https://github.com/microsoft/TypeScript/issues/12936#issuecomment -524631270 이 문제를 겪지 않는 솔루션을 생각해 냈습니다.

@dragomirtitian 함수를 입력하는 방법의 문제입니다.
조금 다르게 하면 효과가 있습니다.

type Exact<T, R> = T extends R
  ? R extends T
    ? T
    : never
  : never

type InexactType = {
    foo: string
}

const obj = {
    foo: 'foo',
    bar: 'bar'
}

function test1<T>(t: Exact<T, InexactType>) {}

function test2<T extends InexactType>(t: T) {
  test1(t); // fails
}
test2(obj)

https://www.typescriptlang.org/play/#code/C4TwDgpgBAogHgQwMbADwBUA0UBKA + KAXinSgjmAgDsATAZ1wCgooB + XMi6 + k5lt3vygAuKFQgA3CACc + o8VNmNQkKAElxiFOnDRiAbz4sAZgHtTousGkBLKgHNGAX0aMkpqlaimARgCsiKEMhMwsoAHJQ8MwjKB8EaVFw + Olw51djAFcqFBsPKEorAEYMPAAKYFF4ZDQsdU0anUg8AEogl0YsnOA8qgKIKwAmDE5KWgYNckbdcsqSNuD + 4oqWgG4oAHoNqGMEGwAbOnTC4EGy3z82oA

@jeremybparagon 귀하의 사례가 적용되었습니다.

@iamandrewluca 여기 와 여기 의 솔루션 은 내 예제 를 처리 하는 방법 이 다르다고 생각 합니다 .

type Exact<T, R> = T extends R
  ? R extends T
    ? T
    : never
  : never

type A = {
  prop1: 'a'
}
type C = {
  prop1: string
}

type ShouldBeA = Exact<A, C> // This evaluates to never.

const ob...

놀이터 링크

@aigoncharov 문제는 이를 인식할 필요가 있으므로 이를 쉽게 수행할 수 없고 test1 가 여전히 추가 속성으로 호출될 수 있다는 것입니다. IMO는 실수로 인한 부정확한 할당을 쉽게 허용할 수 있는 솔루션은 이미 실패했습니다. 요점은 유형 시스템에서 정확성을 적용하는 것이기 때문입니다.

@toriningen 예, 귀하의 솔루션이 더 나은 것 같습니다. 저는 마지막으로 게시된 솔루션을 언급한 것뿐입니다. 귀하의 솔루션은 추가 기능 유형 매개 변수가 필요하지 않다는 사실을 알고 있지만 선택적 속성에는 잘 작동하지 않는 것 같습니다.

// (these two types MUST NOT be merged into a single declaration)
type ExactInner<T> = <D>() => (D extends T ? D : D);
type Exact<T> = ExactInner<T> & T;
type Unexact<T> = T extends Exact<infer R> ? R : T;

function exact<T>(obj: Exact<T> | T): Exact<T> {
    return obj as Exact<T>;
};

////////////////////////////////
// Fixtures:
type Wide = { foo: string, bar?: string };
type Narrow = { foo: string };
type ExactWide = Exact<Wide>;
type ExactNarrow = Exact<Narrow>;

const ew: ExactWide = exact<Wide>({ foo: "", bar: ""});
const assign_en_ew: ExactNarrow = ew; // Ok ? 

놀이터 링크

아니에요 @jeremybparagon 확인 @aigoncharov의 솔루션은하지만 선택 속성에 대한 좋은 작업을 수행합니다. T extends S 및 S extends T 를 기반으로 하는 모든 솔루션은

type A = { prop1: string }
type C = { prop1: string,  prop2?: string }
type CextendsA = C extends A ? "Y" : "N" // Y 
type AextendsC = A extends C ? "Y" : "N" // also Y 

놀이터 링크

Exclude<keyof T, keyof Shape> extends never 를 사용하는 @iamandrewluca 가 좋다고 생각합니다. 제 유형은 매우 유사합니다(추가 검사 없이 T extends R 를 보장하기 위해 &R 를 추가하도록 원래 답변을 편집했습니다).

type Exact<T extends IsExact & R, R> =
  Exclude<keyof T, typeof exactMarker> extends keyof R? T : never;

나는 내 솔루션에 구멍이 없다는 평판을 걸지 않을 것입니다. 그렇게 열심히 찾지는 않았지만 그러한 발견을 환영합니다 😊

이것이 전역적으로 활성화되는 플래그가 있어야 합니다. 이런 식으로 느슨한 유형을 원하는 사람은 계속 같은 작업을 수행할 수 있습니다. 이 문제로 인해 너무 많은 버그가 발생했습니다. 이제 나는 스프레드 연산자를 피하고 pickKeysFromObject(shipDataRequest, ['a', 'b','c']) 사용하려고 합니다.

최근에 우연히 발견한 정확한 유형의 사용 사례는 다음과 같습니다.

type PossibleKeys = 'x' | 'y' | 'z';
type ImmutableMap = Readonly<{ [K in PossibleKeys]?: string }>;

const getFriendlyNameForKey = (key: PossibleKeys) => {
    switch (key) {
        case 'x':
            return 'Ecks';
        case 'y':
            return 'Why';
        case 'z':
            return 'Zee';
    }
};

const myMap: ImmutableMap = { x: 'foo', y: 'bar' };

const renderMap = (map: ImmutableMap) =>
    Object.keys(map).map(key => {
        // Argument of type 'string' is not assignable to parameter of type 'PossibleKeys'
        const friendlyName = getFriendlyNameForKey(key);
        // No index signature with a parameter of type 'string' was found on type 'Readonly<{ x?: string | undefined; y?: string | undefined; z?: string | undefined; }>'.    
        return [friendlyName, map[key]];
    });
;

기본적으로 유형이 정확하지 않기 때문에 Object.keys 는 string[] 를 반환해야 하지만(https://github.com/microsoft/TypeScript/pull/12253#issuecomment-263132208 참조), 이 경우 경우, ImmutableMap 정확했다, 그것은 반환하지 수있는 이유가 없습니다 PossibleKeys[] .

@dallonf 이 예제에는 정확한 유형 외에 추가 기능이 필요합니다. Object.keys 는 단지 함수 이며 정확한 유형에 대해 keyof T 를 반환하는 함수를 설명하는 메커니즘이 필요합니다. 다른 유형의 경우 string 입니다. 정확한 유형을 선언하는 옵션을 갖는 것만으로는 충분하지 않습니다.

@RyanCavanaugh 나는 그것이 의미, 정확한 유형 + 그들을 감지하는 능력이라고 생각합니다.

반응 유형에 대한 사용 사례:

forwardRef<T, P>(render: (props: P, ref: Ref<T>) => ReactElement<P> & { displayName?: string }) => ComponentType<P> .

에 정기적으로 구성 요소를 통과 끌리기 forwardRef 이 감지되면 문제가 경고를 런타임 반작용 이유입니다 propTypes 또는 defaultProps 온 render 인수를. 우리는 이것을 유형 수준에서 표현하고 싶지만 never 로 대체해야 합니다.

- forwardRef<T, P>(render: (props: P, ref: Ref<T>) => ReactElement<P> & { displayName?: string }) => ComponentType<P>
+ forwardRef<T, P>(render: (props: P, ref: Ref<T>) => ReactElement<P> & { displayName?: string, propTypes?: never, defaultProps?: never }) => ComponentType<P>

never 가 포함된 오류 메시지는 도움이 되지 않습니다("{}는 undefined에 할당할 수 없습니다").

@toriningen 의 솔루션이 다른 이벤트 개체 모양의 조합으로 어떻게

type StoreEvent =
  | { type: 'STORE_LOADING' }
  | { type: 'STORE_LOADED'; data: unknown[] }

이벤트의 정확한 모양만 허용하는 형식화된 dispatch() 함수를 어떻게 만들 수 있는지 명확하지 않습니다.

(업데이트: 알아냈습니다: https://gist.github.com/sarimarton/d5d539f8029c01ca1c357aba27139010)

사용 사례:

Exact<> 지원이 없으면 GraphQL 변형에 런타임 문제가 발생합니다. GraphQL은 허용되는 속성의 정확한 목록을 허용합니다. props를 과도하게 제공하면 오류가 발생합니다.

따라서 양식에서 일부 데이터를 얻을 때 Typescript는 초과(추가) 속성의 유효성을 검사할 수 없습니다. 그리고 런타임에 오류가 발생합니다.

다음 예는 상상의 안전을 보여줍니다

• 첫 번째 경우에는 모든 입력 매개변수를 추적했습니다.
• 그러나 실생활에서(폼에서 데이터를 가져와서 일부 변수에 저장하는 두 번째 경우와 같이) Typescript

플레이그라운드에서 시도

https://fettblog.eu/typescript-match-the-exact-object-shape/ 기사 및 위에 제공된 유사한 솔루션에 따르면 다음과 같은 추악한 솔루션을 사용할 수 있습니다.

이 savePerson<T>(person: ValidateShape<T, Person>) 솔루션이 못생긴 이유는 무엇입니까?

깊이 중첩된 입력 유형이 있다고 가정합니다. 예:

// Assume we are in the ideal world where implemented Exact<>

type Person {
  name: string;
  address: Exact<Address>;
}

type Address {
   city: string
   location: Exact<Location>
}

type Location {
   lon: number;
   lat: number; 
}

savePerson(person: Exact<Person>)

현재 사용 가능한 솔루션으로 동일한 동작을 얻기 위해 어떤 스파게티를 작성해야 하는지 상상할 수 없습니다.

savePerson<T, TT, TTT>(person: 
  ValidateShape<T, Person keyof ...🤯...
     ValidateShape<TT, Address keyof ...💩... 
         ValidateShape<TTT, Location keyof ...🤬... 
> > >)

따라서 현재로서는 복잡한 중첩 입력 데이터와 함께 작동하는 코드의 정적 분석에 큰 구멍이 있습니다.

"신선함"이 손실되어 TS가 초과 속성의 유효성을 검사하지 않는 첫 번째 이미지에 설명된 경우도 약간의 골칫거리였습니다.

쓰기

doSomething({
  /* large object of options */
})

종종 가독성이 훨씬 떨어집니다.

const options = {
  /* large object of options */
}
doSomething(options)

const options: DoSomethingOptions = { 명시적으로 주석을 달면 도움이 되지만 코드 검토에서 발견하고 적용하기가 약간 번거롭고 어렵습니다.

이것은 다소 주제를 벗어난 아이디어이며 여기에 설명된 정확성에 대한 대부분의 사용 사례를 해결하지 못합니다. 그러나 둘러싸는 범위 내에서 한 번만 사용되는 경우 객체 리터럴을 신선하게 유지할 수 있습니까?

@RyanCavanaugh EPC를 설명

안녕하세요 @noppa 좋은 아이디어라고 생각합니다. 직접 할당하는 것과 변수에 먼저 할당하는 것의 차이점을 발견했을 때 나는 이것을 우연히 발견했습니다. 심지어 나를 여기로 데려온 SO에 대한

GraphQL 돌연변이의 예와 동일한 문제가 있다고 생각합니다(정확한 중첩 입력, 추가 속성이 허용되지 않아야 함). 제 경우에는 공통 모듈(프론트엔드와 백엔드 간에 공유)에 API 응답을 입력하려고 합니다.

export type ProductsSlashResponse = {
  products: Array<{
    id: number;
    description: string;
  }>,
  total: number;
};

서버 측에서는 응답이 해당 유형 서명을 준수하는지 확인하고 싶습니다.

router.get("products/", async () =>
  assertType<ProductsSlashResponse>(getProducts())));

여기에서 솔루션을 시도했습니다. 작동하는 것으로 보이는 것은 T extends U ? U extends T ? T : never : never 이며 이상적이지 않은 커리 함수와 함께입니다. 주요 문제는 누락되거나 추가된 속성에 대한 피드백을 받지 못한다는 것입니다. 다른 솔루션은 깊이 중첩된 개체에서 작동하지 않습니다.

물론 프론트엔드는 일반적으로 지정된 것보다 더 많은 정보를 보내면 충돌하지 않지만 API가 필요한 것보다 더 많은 정보를 보내면 정보 누출이 발생할 수 있습니다(데이터베이스에서 데이터를 읽는 흐릿한 특성 때문에 어떤 유형이 반드시 코드와 항상 동기화되지는 않는지, 이런 일이 발생할 수 있습니다).

@fer22f GraphQL은 클라이언트가 요청하지 않은 필드를 보내지 않습니다... products 또는 배열 요소에 대해 JSON 스칼라 유형을 사용하지 않는 한 거기에 대해 걱정할 필요가 없습니다.

죄송합니다. 잘못 읽었습니다. GraphQL을 사용하고 있다고 생각했습니다.

누군가가 이미 GraphQL에 대해 언급했지만 "사용 사례 수집"( @DanielRosenwasser가 몇 년 전에 스레드에서 언급한 :-) "사용 사례가 없는 것") 측면에서 내가 원했던 두 가지 사용 사례 Exact 사용:

1. 데이터 저장소/데이터베이스/ORM으로 데이터 전달--전달된 추가 필드는 자동으로 삭제/저장되지 않습니다.

2. 유선 호출 / RPC / REST / GraphQL에 데이터를 전달하면 전달되는 추가 필드가 자동으로 삭제되거나 전송되지 않습니다.

(음, 아마 자동으로 삭제되지는 않았을 것입니다. 런타임 오류일 수 있습니다.)

두 경우 모두 프로그래머/나 자신에게 (컴파일 오류를 통해) "... '저장' 또는 ' 보낸다'는 것이다.

이것은 "부분 업데이트" 스타일 API, 즉 약한 유형에서 특히 필요합니다.

type Data = { firstName:? string; lastName?: string; children?: [{ ... }] };
const data = { firstName: "a", lastNmeTypo: "b" };
await saveDataToDbOrWireCall(data);

약한 유형 검사 b/c와 일치하는 하나 이상의 매개변수 firstName 통과하므로 100% 분리되지는 않지만 lsatNmeTypo 의 "명백한" 오타가 여전히 잡히지 않습니다.

물론 다음과 같은 경우 EPC가 작동합니다.

await saveDataToDbOrWireCall({ firstName, lastNmeTypo });

그러나 모든 필드를 구조화하고 다시 입력해야 하는 것은 꽤 지루합니다.

@jcalz 의 Exactify 와 같은 솔루션은 1단계 속성에서 작동하지만 재귀적인 경우(예: children 는 배열이고 배열 요소는 정확해야 함) 일단 히트하면 어려움을 겪고 있습니다. Exact<Foo<Bar<T>> 와 같은 제네릭을 사용한 "실제" 사용 사례

이것이 기본 제공되는 것이 좋으며 우선 순위 지정/로드맵에 도움이 되는 경우 이러한 명시적 사용 사례(기본적으로 부분/약한 유형으로 호출 연결)를 기록하고 싶었습니다.

(FWIW https://github.com/stephenh/joist-ts/pull/35/files는 현재 깊은 Exact 에 대한 시도와 사소한 경우를 통과하는 Exact.test.ts 에 대한 시도가 있지만 PR 자체에는 좀 더 난해한 사용법에 대한 컴파일 오류가 있습니다. 면책 조항 이 특정 PR을 조사할 사람은 없지만 " Exact 가 유용할 것입니다." + "AFAICT 이것은 user-land" 데이터 포인트에서 하기 어렵습니다.)

이봐,

정확한 유형의 레코드 및 튜플 제안에 대한 TS 팀의 생각이 궁금하십니까? https://github.com/tc39/proposal-record-tuple

이러한 새로운 기본 요소에 대해 정확한 유형을 도입하는 것이 의미가 있습니까?

@slorber TS는 아니지만 직교입니다. 그 제안은 불변성에 관한 것이며, Immutable.js와 같은 라이브러리와 그 제안은 거의 동일합니다.

@stephenh 재귀 버전을 반복했습니다. 재귀로 정의되지 않은 경우를 올바르게 처리하는 데 문제가 있었고 더 깨끗한 솔루션을 사용할 수 있습니다. 배열이나 복잡한 데이터 구조가 있는 일부 경우에는 작동하지 않을 수 있습니다.

export type Exact<Expected, Actual> = Expected &
  Actual & // Needed to infer `Actual`
  (null extends Actual
    ? null extends Expected
      ? Actual extends null // If only null stop here, because NonNullable<null> = never
        ? null
        : CheckUndefined<Expected, Actual>
      : never // Actual can be null but not Expected: forbid the field
    : CheckUndefined<Expected, Actual>);

type CheckUndefined<Expected, Actual> = undefined extends Actual
  ? undefined extends Expected
    ? Actual extends undefined // If only undefined stop here, because NonNullable<undefined> = never
      ? undefined
      : NonNullableExact<NonNullable<Expected>, NonNullable<Actual>>
    : never // Actual can be undefined but not Expected: forbid the field
  : NonNullableExact<NonNullable<Expected>, NonNullable<Actual>>;

type NonNullableExact<Expected, Actual> = {
  [K in keyof Actual]: K extends keyof Expected
    ? Actual[K] extends (infer ActualElement)[]
      ? Expected[K] extends (infer ExpectedElement)[] | undefined | null
        ? Exact<ExpectedElement, ActualElement>[]
        : never // Not both array
      : Exact<Expected[K], Actual[K]>
    : never; // Forbid extra properties
};

운동장

Exact는 API 응답을 반환할 때 매우 유용합니다. 현재 다음과 같이 해결합니다.

const response = { companies };

res.json(exact<GetCompaniesResponse, typeof response>(response));

export function exact<S, T>(object: Exact<S, T>) {
  return object;
}

여기서 Exact 유형은 @ArnaudBarre 가 위에서 제공한 것입니다.

저를 차단 해제하고 몇 가지를 가르쳐주신 @ArnaudBarre 에게 감사드립니다.
귀하의 솔루션에 대해 살펴보기:

export type Exact<Expected, Actual> =
  keyof Expected extends keyof Actual
    ? keyof Actual extends keyof Expected
      ? Expected extends ExactElements<Expected, Actual>
        ? Expected
        : never
      : never
    : never;

type ExactElements<Expected, Actual> = {
  [K in keyof Actual]: K extends keyof Expected
    ? Expected[K] extends Actual[K]
      ? Actual[K] extends Expected[K]
        ? Expected[K]
        : never
      : never
    : never
};

// should succeed (produce exactly the Expected type)
let s1: Exact< { a: number; b: string }, { a: number; b: string } >;
let s2: Exact< { a?: number; b: string }, { a?: number; b: string } >;
let s3: Exact< { a?: number[]; b: string }, { a?: number[]; b: string } >;
let s4: Exact< string, string >;
let s5: Exact< string[], string[] >;
let s6: Exact< { a?: number[]; b: string }[], { a?: number[]; b: string }[] >;

// should fail (produce never)
let f1: Exact< { a: string; b: string }, { a: number; b: string } >;
let f2: Exact< { a: number; b: string }, { a?: number; b: string } >;
let f3: Exact< { a?: number; b: string }, { a: number; b: string } >;
let f4: Exact< { a: number[]; b: string }, { a: string[]; b: string } >;
let f5: Exact< { a?: number[]; b: string }, { a: number[]; b: string } >;
let f6: Exact< { a?: number; b: string; c: string }, { a?: number; b: string } >;
let f7: Exact< { a?: number; b: string }, { a?: number; b: string; c: string } >;
let f8: Exact< { a?: number; b: string; c?: string }, { a?: number; b: string } >;
let f9: Exact< { a?: number; b: string }, { a?: number; b: string; c?: string } >;
let f10: Exact< never, string >;
let f11: Exact< string, never >;
let f12: Exact< string, number >;
let f13: Exact< string[], string >;
let f14: Exact< string, string[] >;
let f15: Exact< string[], number[] >;
let f16: Exact< { a?: number[]; b: string }[], { a?: number[]; b: string } >;

이전 솔루션은 f6, f8 및 f9에 대해 '성공'했습니다.
이 솔루션은 '더 깔끔한' 결과도 반환합니다. 일치하면 '예상' 유형을 다시 가져옵니다.
@ArnaudBarre 의 의견과 마찬가지로 ... 모든 경우가 처리되었는지 확실하지 않으므로 ymmv ...

@heystewart 귀하의 Exact 는 대칭 결과를 제공하지 않습니다:

let a: Exact< { foo: number }[], { foo: number, bar?: string }[] >;
let b: Exact< { foo: number, bar?: string }[], { foo: number }[] >;

a = [{ foo: 123, bar: 'bar' }]; // error
b = [{ foo: 123, bar: 'bar' }]; // no error

편집 : @ArnaudBarre 버전에도 동일한 문제가 있습니다.

@papb 네 효과적으로 입력이 작동하지 않습니다 진입점이 배열입니다. variables 가 항상 객체인 graphQL API에 필요했습니다.

이 문제를 해결하려면 ExactObject와 ExactArray를 분리하고 둘 중 하나에 들어가는 진입점이 있어야 합니다.

그렇다면 객체가 그 이상도 그 이하도 아닌 정확한 속성을 갖도록 하는 가장 좋은 방법은 무엇입니까?

@captain-yossarian은 TypeScript 팀이 이것을 구현하도록 설득합니다. 여기에 제시된 솔루션은 예상되는 모든 경우에 작동하지 않으며 거의 ​​모든 경우에 명확성이 부족합니다.

@toriningen 은 TS 팀이 이 기능을 구현할 경우 얼마나 많은 문제가 해결될지 상상할 수 없습니다.

@RyanCavanaugh
현재 저를 여기로 데려온 한 가지 사용 사례가 있으며 "기타"라는 주제로 바로 연결됩니다. 다음과 같은 기능을 원합니다.

1. 선택적 매개변수가 있는 인터페이스를 구현하는 매개변수를 취합니다.
2. 주어진 매개변수의 더 좁은 실제 인터페이스에 유형이 지정된 객체를 반환하므로

이러한 즉각적인 목표는 다음과 같은 목적을 달성합니다.

1. 입력에 대한 초과 속성 검사를 받습니다.
2. 출력에 대한 자동 완성 및 속성 유형 안전성을 얻습니다.

예시

내 경우를 다음과 같이 줄였습니다.

type X = {
    red?: number,
    green?: number,
    blue?: number,
}

function y<
    Y extends X
>(
    y: (X extends Y ? Y : X)
) {
    if ((y as any).purple) throw Error('bla')

    return y as Y
}

const z = y({
    blue: 1,
    red: 3,
    purple: 4, // error
})
z.green // error

type Z = typeof z

그 설정은 작동하고 원하는 모든 목표를 달성하므로 순수한 실행 가능성의 관점에서 볼 때 이것이 진행되는 한 저는 좋습니다. 그러나 EPC는 (X extends Y ? Y : X) 입력 매개변수를 통해 달성됩니다. 나는 기본적으로 우연히 그것을 우연히 발견했고 그것이 효과가 있다는 것에 다소 놀랐습니다.

제안

그리고 이것이 여기서 유형이 초과 속성을 갖지 않아야 한다는 의도를 표시하기 위해 extends 대신 사용할 수 있는 implements 키워드를 갖고 싶은 이유입니다. 이렇게:

type X = {
    red?: number,
    green?: number,
    blue?: number,
}

function x<
    Y implements X
>( y: Y ) {
    if ((y as any).purple) throw Error('bla')

    return y as Y
}

const z = y({
    blue: 1,
    red: 3,
    purple: 4, // error
})
z.green // error

type Z = typeof z

이것은 현재 해결 방법보다 훨씬 명확해 보입니다. 보다 간결한 것 외에도 제네릭과 매개 변수 사이의 현재 분할과 달리 제네릭 선언으로 전체 제약 조건을 찾습니다.

이는 또한 현재 불가능하거나 비현실적인 추가 사용 사례를 가능하게 할 수 있지만 현재로서는 직감에 불과합니다.

대안으로 약한 유형 감지

특히, #3842에 따른 Weak Type Detection은 이 문제도 수정해야 하며, 내 사용 사례에 따라 extends 와 관련하여 작동하는 경우 추가 구문이 필요하지 않기 때문에 유리할 수 있습니다.

Exact<Type> 등에 관하여

마지막으로 implements 는 Exact<Type> 의 보다 일반적인 경우를 해결하려고 시도하지 않기 때문에 function f<T extends Exact<{ n: number }>(p: T) 에 대한 귀하의 요점과 관련하여 매우 간단해야 합니다.

일반적으로 Exact<Type> 는 EPC 옆에 거의 유용하지 않은 것으로 보이며 이러한 그룹을 벗어나는 일반적으로 유용한 경우를 상상할 수 없습니다.

• 함수 호출: 이제 내 예제에 따라 쉽게 처리할 수 있으며 implements 이점을 얻을 수 있습니다.
• 할당: 리터럴만 사용하므로 EPC가 적용됩니다.
• 제어 영역 외부의 데이터: 유형 검사는 이를 방지할 수 없으며 런타임에 이를 처리해야 하며 이 시점에서 안전한 캐스트로 돌아갑니다.

분명히 리터럴을 할당할 수 없는 경우가 있지만 유한 집합이어야 합니다.

• 함수에 할당 데이터가 제공된 경우 호출 서명에서 유형 검사를 처리합니다.
• OP에 따라 여러 개체를 병합하는 경우 각 소스 개체의 유형을 올바르게 주장하면 as DesiredType 안전하게 캐스팅할 수 있습니다.

요약: implements 좋지만 그렇지 않으면 좋습니다.

요약하면 implements 와 EPC 수정(문제가 발생하는 경우)으로 정확한 유형을 실제로 처리해야 한다고 확신합니다.

모든 이해 관계자에게 질문: 여기에 실제로 열려 있는 것이 있습니까?

여기에서 유스 케이스를 살펴본 결과 거의 모든 재현이 지금쯤 적절하게 처리되고 나머지는 위의 작은 예제로 작동하도록 만들 수 있다고 생각합니다. 이것은 질문을 던집니다. 오늘날에도 최신 TS와 관련하여 여전히 문제가 있는 사람이 있습니까?

유형 주석에 대한 미숙한 아이디어가 있습니다. 일치하는 개체는 정확히 같을 수 있는 구성원으로 나뉩니다. 더도 말고 덜도 말고, 더도 말고 덜도 말고, 더도 말고 덜도 말고. 위의 각 경우에 대해 하나의 표현식이 있어야 합니다.

정확히 같음, 즉 더도 말고 덜도 말고:

function foo(p:{|x:any,y:any|})

//it matched 
foo({x,y})
//no match
foo({x})
foo({y})
foo({x,y,z})
foo({})

그 이상도 이하도 아닌:

function foo(p:{|x:any,y:any, ...|})

//it matched 
foo({x,y})
foo({x,y,z})

//no matched
foo({x})
foo({y})
foo({x,z})

더도 말고 덜도 말고:

function foo(p:{x:any,y:any})

//it matched 
foo({x,y})
foo({x})
foo({y})

//no match
foo({x,z})
foo({x,y,z})

많거나 적은:

function foo(p:{x:any,y:any, ...})

//it matched 
foo({x,y})
foo({x})
foo({y})
foo({x,z})
foo({x,y,z})

결론:

세로선이 있는 것은 더 적은 것이 없다는 것을 나타내고, 세로선이 없는 것은 더 적을 수 있음을 의미합니다. 생략 부호가 있으면 더 있을 수 있음을 의미하고 생략 부호가 없으면 더 이상 있을 수 없음을 의미합니다. 배열 일치도 같은 생각입니다.

function foo(p:[|x,y|]) // p.length === 2
function foo(p:[|x,y, ... |]) // p.length >= 2
function foo(p:[x,y]) // p.length >= 0
function foo(p:[x,y,...]) // p.length >= 0

귀하의 예를 사용하여 @rasenplanscher 는 다음을 컴파일합니다.

const x = { blue: 1, red: 3, purple: 4 };
const z = y(x);

그러나 정확한 유형에서는 그렇지 않아야 합니다. 즉, 여기서 요구하는 것은 EPC에 의존하지 말라는 것입니다.

@xp44mm "더 많거나 적음"은 이미 동작이고 "더 많거나 적음"은 모든 속성을 선택 사항으로 표시한 경우의 동작입니다.

function foo(p:{x?: any, y?: any}) {}
const x = 1, y = 1, z = 1
// all pass
foo({x,y})
foo({x})
foo({y})
const p1 = {x,z}
foo(p1)
const p2 = {x,y,z}
foo(p2)

유사하게, 정확한 유형이 있는 경우 정확한 유형 + 선택적 모든 속성은 본질적으로 "더는 아니지만 덜"이 됩니다.

이 문제에 대한 또 다른 예입니다. 이 제안에 대한 좋은 시연이라고 생각합니다. 이 경우 rxjs 를 사용하여 Subject를 다루지만 ("잠긴") Observable ( next , error 등의 메서드가 없는)을 반환하고 싶습니다. 값.)

someMethod(): Observable<MyType> {
  const subject = new Subject<MyType>();

  // This works, but should not. (if this proposal is implemented.)
  return subject;

  // Only Observable should be allowed as return type.
  return subject.asObservable();
}

나는 항상 정확한 유형 Observable 만 반환하고 이를 확장하는 Subject 반환하지 않기를 원합니다.

제안:

// Adding exclamation mark `!` (or something else) to match exact type. (or some other position `method(): !Foo`, ...)
someMethod()!: Observable<MyType> {
  // ...
}

그러나 나는 당신이 더 나은 아이디어를 가지고 있다고 확신합니다. 특히 이것은 반환 값에만 영향을 미치는 것이 아니기 때문입니다. 그렇죠? 어쨌든, 그냥 의사 코드 데모입니다. 나는 그것이 오류와 부족을 피하는 좋은 기능이라고 생각합니다. 위에서 설명한 경우처럼. 또 다른 솔루션은 새로운 유틸리티 유형을 추가하는 것입니다.
아니면 내가 뭔가를 놓쳤나요? 이것은 이미 작동합니까? 저는 TypeScript 4를 사용합니다.