Typescript: 제안: get/set 접근자를 다른 유형으로 허용

여기에서 이것이 얼마나 좋은지 알 수 있지만(지금은 문제를 찾을 수는 없지만 이전에 요청한 적이 있음) 유틸리티가 이를 보증하기에 충분한지 여부는 불가능합니다. 문제는 접근자가 .d.ts에서 일반 속성과 다르게 표시되지 않는다는 것입니다. 그 관점에서 보면 동일하게 보이기 때문입니다. getter와 setter 사이에 차이가 없다는 의미이므로 a) 구현이 단일 인스턴스 멤버가 아닌 접근자를 사용하도록 요구하고 b) getter와 setter 간의 유형 차이를 지정하는 방법이 없습니다.

빠른 답변 감사합니다, Dan. 덜 우아한 방법을 따르겠습니다. 훌륭한 작업에 감사드립니다!

다른 유형의 JavaScript getter 및 setter는 완벽하게 유효하고 훌륭하게 작동하며 이것이 이 기능의 주요 이점/목적이라고 생각합니다. TypeScript를 기쁘게 하기 위해 setMyDate() 를 제공해야 하는 것은 그것을 망칩니다.

다음 패턴을 따르는 순수 JS 라이브러리에 대해서도 생각해 보십시오. .d.ts는 공용체 또는 any 를 노출해야 합니다.

문제는 접근자가 일반 속성과 다르게 .d.ts에 표시되지 않는다는 것입니다.

그런 다음 이 제한이 수정되고 이 문제가 계속 열려 있어야 합니다.

// MyClass.d.ts

// Instead of generating:
declare class MyClass {
  myDate: moment.Moment;
}

// Should generate:
declare class MyClass {
  get myDate(): moment.Moment;
  set myDate(value: Date | moment.Moment);
}

// Or shorter syntax:
declare class MyClass {
  myDate: (get: moment.Moment, set: Date | moment.Moment);
  // and 'fooBar: string' being a shorthand for 'fooBar: (get: string, set: string)'
}

나는 이것이 단지 의견이라는 것을 알고 있지만 $ a.x = y; $#$ 직후에 a.x === y 가 true $가 아닌 것과 같은 setter를 작성하는 것은 거대한 위험 신호입니다. 그런 라이브러리의 소비자는 어떤 속성에 마법의 부작용이 있고 어떤 속성이 없는지 어떻게 알 수 있습니까?

마법 부작용이 있는 속성과 그렇지 않은 속성을 어떻게 알 수 있습니까?

JavaScript에서는 직관적이지 않을 수 있으며 TypeScript에서는 도구(IDE + 컴파일러)가 불평합니다. TypeScript를 다시 좋아하는 이유는 무엇입니까? :)

다른 유형의 JavaScript getter 및 setter는 완벽하게 유효하고 훌륭하게 작동하며 이것이 이 기능의 주요 이점/목적이라고 생각합니다.

이것은 JavaScript가 약하게 형식화되어 있으므로 TypeScript가 약하게 형식화되어야 한다는 주장입니다. :-에스

이것은 JavaScript가 약하게 형식화되어 있으므로 TypeScript가 약하게 형식화되어야 한다고 주장합니다.

C#은 이를 허용하며 이 언어를 약하게 형식화 하지 않습니다. C#은 다른 형식의 get/set을 허용하지 않습니다.

C#은 이를 허용하며 이 언어를 약하게 형식화 하지 않습니다. C#은 다른 형식의 get/set을 허용하지 않습니다.

:눈짓:

접근자가 약한 유형이어야 한다고 주장하는 사람은 아무도 없으며 유형을 정의할 수 있는 유연성이 있어야 한다고 주장합니다.

보통 오래된 개체를 개체 인스턴스에 복사해야 하는 경우가 많습니다.

    get fields(): Field[] {
      return this._fields;
    }

    set fields(value: any[]) {
      this._fields = value.map(Field.fromJson);
    }

그것은 대안보다 훨씬 좋으며 내 setter가 정확한 유형의 논리 setter를 캡슐화할 수 있습니다.

@paulwalker 거기에서 사용하는 패턴( any 을 받는 setter와 더 구체적인 유형을 반환하는 getter)은 오늘 유효합니다.

@danquirk 반갑 습니다, 감사합니다! ST용 IDE 플러그인 컴파일러를 업데이트해야 하는 것 같습니다.

@danquirk 놀이터(또는 버전 1.6.2)에 따라 작동하지 않는 것 같습니다.
http://www.typescriptlang.org/Playground#src =%0A%0Aclass%20Foo%20%7B%0A%0A%20%20get%20items()%3A%20string%5B%5D%20%7B%0A %09%20%20반환%20%5B%5D%3B%0A%20%20%7D%0A%20%20%0A%20%20set%20items(value%3A%20any)%20%7B%0A% 09%20%20%0A%20%20%7D%0A%7D

방금 typescript@next (버전 1.8.0-dev.20151102)로 테스트했는데 오류도 있습니다.

~$ tsc --version
message TS6029: Version 1.8.0-dev.20151102
~$ cat a.ts
class A {
    get something(): number {return 5;}
    set something(x: any) {}
}

~$ tsc -t es5 a.ts
a.ts(2,2): error TS2380: 'get' and 'set' accessor must have the same type.
a.ts(3,2): error TS2380: 'get' and 'set' accessor must have the same type.

아이러니하게도 Sublime 린터를 업데이트한 후 TypeScript 1.7.x를 사용하는 오류가 더 이상 발생하지 않았습니다. 나는 그것이 1.7+에서 곧 개선될 것이라고 가정하고 있으므로 아마도 1.8.0이 퇴보했을 것입니다.

typescript 1.7.5를 지원하는 Visual Studio 코드 버전(0.10.5(2015년 12월))과 내 컴퓨터에 전역적으로 설치된 typescript 1.7.5에서도 여전히 문제입니다.

그럼 어떤 버전이 지원될까요?
감사 해요

댄이 잘못 생각한 것 같아요. getter와 setter는 동일한 유형이어야 합니다.

창피. 각도기 테스트에 사용할 페이지 개체를 작성할 때 좋은 기능이 되었을 것입니다.

나는 각도기 테스트를 작성할 수 있었을 것입니다:

po.email = "[email protected]";
expect(po.email).toBe("[email protected]");

... 페이지 개체를 작성하여:

class PageObject {
    get email(): webdriver.promise.Promise<string> {
        return element(by.model("ctrl.user.email")).getAttribute("value")
    }
    set email(value: any) {
        element(by.model("ctrl.user.email")).clear().sendKeys(value);
    }
}

그 코드는 setter가 any 유형이어야 합니까?

getter는 webdriver.promise.Promise<string> 를 반환하지만 setter는 string 값을 할당하려고 합니다.

다음과 같은 더 긴 형태의 각도기 테스트를 사용하면 더 명확해질 수 있습니다.

po.email = "[email protected]";
var currentEmail : webdriver.promise.Promise<string> = po.email;
expect(currentEmail).toBe("[email protected]")

@RyanCavanaugh null 주석의 도입으로 null을 사용하여 setter를 호출하여 일부 기본값으로 설정할 수 있는 코드를 방지합니다.

class Style {
    private _width: number = 5;

    // `: number | null` encumbers callers with unnecessary `!`
    get width(): number {
        return this._width;
    }

    // `: number` prevents callers from passing in null
    set width(newWidth: number | null) {
        if (newWidth === null) {
            this._width = 5;
        }
        else {
            this._width = newWidth;
        }
    }
}

| null 및 | undefined 가 있는 경우 최소한 유형을 다르게 허용하는 것을 고려할 수 있습니까?

이것은 정말 좋은 기능이 될 것입니다.

그럼 이게 기능이 될까요?

@artyil 닫혀 있고 _By Design_ 태그가 지정되어 현재 추가할 계획이 없음을 나타냅니다. 위에 표현된 우려 사항을 무시한다고 생각하는 강력한 사용 사례가 있는 경우 자유롭게 사례를 만들 수 있으며 추가 피드백을 통해 핵심 팀이 자신의 입장을 재고할 수 있습니다.

@kitsonk 위의 의견에서 설득력 있는 사용 사례가 충분히 제공되었다고 생각합니다. 현재 디자인은 이 제한이 있는 대부분의 다른 유형 언어의 공통 패턴을 따르지만 Javascript 컨텍스트에서는 불필요하고 지나치게 제한적입니다. 설계에 의한 것이지만 설계가 잘못되었습니다.

동의한다.

이것에 대해 좀 더 생각한 후. 여기서 문제는 실제로 구현의 복잡성이라고 생각합니다. 나는 개인적으로 @Arnavion 의 예제가 매력적이라고 ​​생각하지만 오늘날 유형 시스템은 getter/setter를 일반 속성으로 취급합니다. 이것이 작동하려면 둘 다 동일한 값을 가져야 합니다. 읽기/쓰기 유형을 지원하는 것은 큰 변화가 될 것입니다. 여기서 유틸리티가 구현 비용의 가치가 있는지 확신할 수 없습니다.

저는 TypeScript를 사랑하고 팀이 들이는 모든 노력에 감사하지만(정말로, 여러분은 기뻐요!), 이 결정에 실망했다는 것을 인정해야 합니다. getFoo()/setFoo() 또는 get foo()/set foo()/setFooEx() 의 대안보다 훨씬 더 나은 솔루션이 될 것입니다.

간단한 문제 목록:

• 현재 속성에는 정확히 하나의 유형이 있다고 가정합니다. 이제 모든 위치에 있는 모든 속성의 "읽기" 유형과 "쓰기" 유형을 구별해야 합니다.
• 속성당 하나가 아닌 두 가지 유형을 추론해야 하기 때문에 모든 유형 관계가 훨씬 더 복잡해집니다( { get foo(): string | number; set foo(): boolean } 를 { foo: boolean | string | number } $ 에 할당할 수 있습니까? 또는 그 반대로도 가능합니까?).
• 우리는 현재 속성이 설정된 후에도 다음 줄에 설정된 값의 유형이 있다고 가정합니다(일부 사람들의 코드베이스에서는 분명히 잘못된 가정, 와트?). 우리는 아마도 이와 같은 속성에 대한 모든 흐름 제어 분석을 "꺼야" 할 것입니다.

솔직히, 나는 여기에서 코드 작성 방법에 대해 규정하지 않으려고 노력하지만 이 코드가

foo.bar = "hello";
console.log(foo.bar);

정상적인 의미를 가지려고 시도하는 언어에서 "hello" 보다 더 많은 것을 인쇄해야 합니다. 속성은 필드와 외부 관찰자가 구분할 수 없는 동작을 가져야 합니다.

@RyanCavanaugh 주입된 의견에 동의하는 동안 _might_는 매우 TypeScripty일 수 있다는 반대 주장을 볼 수 있습니다... setter에서 약하게 유형이 지정된 무언가를 던지지만 항상 강력한 유형이 반환되는 것, 예:

foo.bar = [ '1', 2 ];  // any[]
console.log(foo.bar);  // number[]: [ 1, 2 ]

개인적으로 나는 당신이 그렇게 마법처럼 될 것이라고 생각하는 경향이 있지만 최종 개발자가 무엇이 구부러지고 접히고 잘릴 것인지 명확하게 이해할 수 있도록 메소드를 만드는 것이 가장 좋습니다.

다음은 이 기능의 사용 사례입니다. API는 _Autocasting_이라는 기능을 도입했습니다. 주요 이점은 유형이 잘 정의된 속성을 할당하기 위해 가져올 클래스 수를 제거할 수 있는 간소화된 개발자 환경입니다.

예를 들어 색상 속성은 Color 인스턴스 또는 rgba(r, g, b, a) 와 같은 CSS 문자열 또는 3개 또는 4개의 숫자 배열로 표현할 수 있습니다. 속성은 여전히 Color 의 인스턴스로 입력됩니다. 값을 읽을 때 얻는 유형이기 때문입니다.

그것에 대한 몇 가지 정보: https://developers.arcgis.com/javascript/latest/guide/autocasting/index.html

사용자는 필요한 가져오기 수를 줄여 해당 기능을 사용하게 되어 매우 기뻤고 할당 후에 유형이 변경된다는 점을 완벽하게 이해하고 있습니다.

이 문제에 대한 또 다른 예: https://github.com/gulpjs/vinyl#filebase

file.base = 'd:\\dev';
console.log(file.base); //  'd:\\dev'
file.base = null;
console.log(file.base); //  'd:\\dev\\vinyl' (returns file.cwd)

따라서 setter는 string | null | undefined 이고 getter는 string 입니다. 이 라이브러리의 유형 정의에서 어떤 유형을 사용해야 합니까? 전자를 사용하는 경우 컴파일러는 모든 곳에서 쓸모없는 null 검사를 요구할 것입니다. 후자를 사용하면 이 속성에 null 를 할당할 수 없습니다.

getter가 nullable을 반환하기를 원하지만 setter가 null을 입력으로 허용하지 않아야 하는 또 다른 예가 있습니다.

class Memory {
    public location: string;
    public time: Date;
    public company: Person[];
}

class Person
{
    private _bestMemoryEver: Memory | null;

    public get bestMemoryEver(): Memory | null { // Might not have one yet
        return this._bestMemoryEver;
    }

    public set bestMemoryEver(memory: Memory) { // But when he/she gets one, it can only be replaced, not removed
        this._bestMemoryEver = memory;
    }
}

var someDude = new Person();
// ...
var bestMemory: Memory | null = someDude.bestMemoryEver;
//...
someDude.bestMemoryEver = null; // Oh no you don't!

null에 대해 getter/setter를 다르게 하기 위한 몇 가지 특별한 논리를 구축하는 것이 너무 많은 작업일 수 있다는 것을 이해하고, 나에게는 그렇게 큰 문제가 아니지만 있으면 좋을 것입니다.

@Elephant-Vessel 철학적으로 나는 이 예를 절대적으로 좋아합니다. 인간의 변덕스러운 본성을 잘 나타내지 null (또는 undefined )을 설정합니다. 시스템에서 시냅스 장애를 어떻게 모델링할 수 있습니까?

@aluanhaddad 왜 시냅스 실패를 원합니까? 나는 내 우주에서 그런 종류의 나쁜 것을 원하지 않습니다 ;)

이에 대한 업데이트가 있습니까? null 또는 undefined로 설정될 때 기본값 을 갖는 것은 어떻습니까?

나는 소비자가 사전에 null 체크를 하는 것을 원하지 않습니다. 현재는 대신 setter를 별도의 메소드로 만들어야 하는데 동일하게 하고 싶습니다.

다음은 내가 갖고 싶은 것입니다.

export class TestClass {
  private _prop?: number;

  get prop(): number {
    // return default value if not defined
    this._prop === undefined ? 0 : this._prop;
  }
  set prop(val: number | undefined) {
    this._prop = val;
  }
}

Null이 아닌 검사의 이점은 문제와 함께 제공되며 이것이 그 중 하나인 것 같습니다. 엄격한 null 검사를 끄면 이것이 가능하지만 null 참조 예외를 방지하기 위한 컴파일러의 도움을 받지 못합니다. 그러나 컴파일러 지원을 원한다면 최소한 null 허용 여부와 관련하여 getter 및 setter에 대한 별도의 정의를 갖는 것과 같은 더 많은 지원이 제공되어야 한다고 생각합니다.

문제의 레이블은 이것이 설계 제한이며 구현이 너무 복잡한 것으로 간주될 수 있음을 나타냅니다. 이는 본질적으로 누군가가 이것이 사실이어야 하는 매우 강력한 이유가 있는 경우 아무데도 가지 않는다는 것을 의미합니다.

@mhegazy @kitsonk 편견이 있을 수 있지만, 이것은 특히 아직 null 검사가 없는 언어와 같은 다른 중괄호에서 일반적인 패턴에 대한 엄격한 null 검사를 위해 발생한 버그 라고 생각합니다. 해결 방법은 소비자가 강타 연산자를 사용하거나 실제로 null이 아닌지 확인해야 합니다(기본값을 사용하여 null이 되지 않는다는 점).

이것은 기술적으로 다른 유형이기 때문에 엄격한 null 검사를 추가하면 문제가 해결됩니다. 나는 강력한 다른 유형을 설정하도록 요구하지 않지만 이를 가능하게 하는 디자인 요구 사항은 강력한 다른 유형도 가능하게 하는 것 같습니다.

null 및 undefined와 같은 유형이 완전히 다른 유형을 활성화하지 않으려는 경우 인터페이스 정의 및 d.ts 파일에 대해 특수한 경우가 되도록 약한 유형에 대체 디자인을 사용할 수 있습니다.

https://github.com/Microsoft/TypeScript/issues/2521#issuecomment -199650959에 대한 응답으로
구현하기가 덜 복잡해야 하는 제안 디자인은 다음과 같습니다.

export interface Test {
  undefset prop1: number; // property [get] type number and [set] type number | undefined
  nullset prop2: number; // property [get] type number and [set] type number | null
  nilset prop3: number; // property [get] type number and [set] type number | null | undefined
  undefget prop4: number; // property [get] type number | undefined and [set] type number
  nullget prop5: number; // property [get] type number | null and [set] type number
  nilget prop6: number; // property [get] type number | null | undefined and [set] type number
}

TypeScript에 훨씬 더 익숙한 이 스레드를 보고 있는 사람들이 있는 것 같으므로 여전히 관심을 갖고 있는 누군가가 관련 질문에 답변할 수 있습니다. 이 Cesium 문제 에서 저는 여기서 논의하고 있는 get/set 유형 제한에 대해 언급했으며 Cesium 사람들은 그들이 따르고 있는 패턴이 C#에서 온 것이라고 말했습니다 -- 이것은 암시적 생성자 입니다.

TypeScript가 암시적 생성자를 지원할 수 있습니까? 즉, myThing.foo 는 항상 Bar Bar 를 직접 할당할 수 있지만 number 를 할당할 수도 있습니다. 개발자의 편의를 위해 Bar 에 조용히 래핑/초기화하는 데 사용하시겠습니까? Bar 주석을 달거나 " number is assignable to Bar<number> "라고 구체적으로 말하면 Cesium 문제에서 논의된 사용 사례를 해결할 수 있습니다. 그리고 이 스레드에서 제기된 많은 문제들.

그렇지 않은 경우 별도의 문제에서 암시적 생성자 지원을 제안해야 합니까?

그것에 대해 더 많이 생각하거나 읽을수록 "암시적 생성자 패턴"에 이 호에서 설명하는 기능이 필요하다는 확신이 더 많이 듭니다. 바닐라 JS에서 가능한 유일한 방법은 객체 get/set 접근자를 사용하는 것입니다. 왜냐하면 명목 할당( = 연산자)이 실제로 사용자 정의 함수를 호출하는 유일한 시간이기 때문입니다. (맞나?) 그래서 우리에게 정말 필요할 것 같아

class MyThing{
  set foo(b: Bar<boolean> | boolean);
  get foo(): Bar<boolean>;
}

@RyanCavanaugh 가 "제정신의 의미론"이 아니라고 생각하는 것처럼 들립니다.

간단한 사실은 이 패턴을 사용하는 꽤 인기 있는 JS 라이브러리가 있으며 주어진 기존 TS 제약 조건을 설명하는 것이 불가능하지는 않더라도 어려운 것처럼 보입니다. 내가 틀렸으면 좋겠어.

JavaScript는 이미 설명하는 패턴을 허용합니다. _challenge_는 TypeScript에서 유형의 읽기 및 쓰기 측면이 설계상 동일한 것으로 가정된다는 것입니다. 할당을 허용하지 않는 언어 수정( readonly )이 있었지만 _쓰기 전용_ 개념을 요청한 몇 가지 문제가 있습니다. 이 개념은 실제 가치에 비해 너무 복잡하다고 논의되었습니다.

IMO, JavaScript가 접근자를 허용한 이후로 사람들은 잠재적으로 그들과 혼동되는 API를 만들었습니다. 저는 개인적으로 할당된 것이 _마술적으로_ 다른 것으로 변경되는 것이 혼란스럽다고 생각합니다. 암시적인 모든 것, 특히 유형 변환은 JavaScript IMO의 골칫거리입니다. 문제를 일으키는 것은 바로 유연성입니다. _magic_이 있는 이러한 유형의 변환에서는 개인적으로 메서드가 호출되는 것을 보고 싶습니다. 여기서 일종의 ✨가 발생하고 값을 검색하기 위해 읽기 전용 getter를 만드는 것이 소비자에게 좀 더 명시적입니다.

이는 실제 사용이 존재하지 않는다는 것을 의미하지 않으며, 이는 잠재적으로 제정신이고 합리적입니다. 전체 유형 시스템을 두 개로 분할하는 복잡성 때문에 유형이 읽기 및 쓰기 조건에서 추적되어야 한다고 생각합니다. 그것은 매우 사소하지 않은 시나리오처럼 보입니다.

나는 :sparkles: here에 동의합니다. 하지만 패턴 사용에 대해 찬성하거나 반대하는 것이 아닙니다. 단지 이미 패턴을 사용 하고 패턴의 모양을 설명하는 코드를 따라가려고 할 뿐입니다. 그것은 이미 작동하는 방식으로 작동하며 TS는 이를 설명할 도구를 제공하지 않습니다.

좋든 나쁘든 JS는 할당을 함수 호출로 바꿀 수 있는 기능을 제공했으며 사람들은 이를 사용하고 있습니다. set/get 쌍에 다른 유형을 할당할 수 있는 기능이 없는데 왜 앰비언트 타이핑에 set/get 가 있습니까? Salsa는 myThing.foo 가 할당의 어느 쪽에 있는지에 관계없이 항상 단일 유형의 멤버 변수로 처리하려는 경우 속성이 getter 및 setter로 구현된다는 것을 알 필요가 없습니다. (물론 실제 TypeScript 컴파일은 완전히 다른 것입니다.)

@thw0rted

TypeScript에 훨씬 더 익숙한 이 스레드를 보고 있는 사람들이 있는 것 같으므로 여전히 관심을 갖고 있는 누군가가 관련 질문에 답변할 수 있습니다. 이 Cesium 문제에서 저는 여기서 논의하고 있는 get/set 유형 제한에 대해 언급했으며 Cesium 사람들은 그들이 따르는 패턴이 C#에서 온 것이라고 말했습니다 -- 이것은 암시적 생성자입니다.

C#의 암시적 사용자 정의 변환 연산자는 값 유형을 기반으로 정적 코드 생성을 수행합니다. TypeScript 유형은 지워지고 런타임 동작에 영향을 주지 않습니다($ Promise 폴리필러의 경우 async / await #$ 예외 케이스는 견딜 수 없음).

@kitsonk 속성과 관련하여 일반적으로 동의하지 않습니다. Java, C++ 및 C#을 사용하여 상당한 시간을 보냈지만 중요한 구문 추상화를 제공하기 때문에 속성(C#에서 볼 수 있음)을 절대적으로 좋아합니다(JavaScript에서는 다소 사실임). 이를 통해 인터페이스는 구문을 변경하지 않고도 의미 있는 방식으로 읽기/쓰기 기능을 분리할 수 있습니다. 나는 X 를 얻는 것이 암시적일 수 있을 때 getX() 와 같은 사소한 작업에 동사가 낭비되는 것을 보는 것을 싫어합니다.
IMO의 혼란스러운 API는 접근자를 남용한다고 하는 것처럼 너무 많은 _setters_가 마법 같은 일을 하기 때문에 더 많이 발생합니다.

읽기 전용이지만 일부 데이터에 대한 라이브 뷰(예: registry )가 있는 경우 읽기 전용 속성을 이해하기가 매우 쉽다고 생각합니다.

interface Entry {key: string; value: any;}

export function createRegistry() {
  let entries: Entry[] = [];
  return {
    register(key: string, value: any) {
      entries = [...entries, {key, value}];
    },
    get entries() {
      return [...entries];
    }
  }
}

const registry = createRegistry();

registry.register('hello', '您好');
console.log(registry.entries); //[{key: 'hello', value: '您好'}]
registry.register('goodbye', '再见');
console.log(registry.entries); //[{key: 'hello', value: '您好'}, {key: 'goodbye', value: '再见'}]

접선에 대해 미안하지만 나는 이것에 대한 접근자를 좋아하고 이해하기 쉽다고 생각하지만 그렇지 않으면 기꺼이 확신하고 가독성이 나의 첫 번째 관심사입니다.

TypeScript가 JavaScript를 제한하면 이점보다 성가신 것이 더 많습니다. TypeScript는 개발자가 서로 의사 소통할 수 있도록 도와주는 것이 아닌가요?

또한 세터를 뮤테이터라고 부르는 데는 이유가 있습니다. 어떤 종류의 변환도 필요하지 않다면 setter를 사용하지 않고 직접 변수를 설정합니다.

자바스크립트 프로젝트를 typescript로 포팅. 나는이 문제를 만났다..

이것은 각도 @Input 데코레이터에서 사용하는 것이 좋습니다. 값이 템플릿에서 전달되기 때문에 다른 들어오는 개체 유형을 처리하는 것이 훨씬 더 깔끔해집니다.

업데이트: 이것은 나를 위해 작동하는 것으로 보입니다.

import { Component, Input } from '@angular/core';
import { flatMap, isString, isArray, isFalsy } from 'lodash';

@Component({
  selector: 'app-error-notification',
  templateUrl: './error-notification.component.html',
})

export class ErrorNotificationComponent {
  private _errors: Array<string> = [];
  constructor() { }
  /**
   * 'errors' is expected to be an input of either a string or an array of strings
   */
  @Input() set errors(errors: Array<string> | any){
      // Caller just passed in a string instead of an array of strings
      if (isString(errors)) {
        this._errors = [errors];
      }
      // Caller passed in array, assuming it is a string array
      if (isArray(errors)) {
        this._errors = errors;
      }
      // Caller passed in something falsy, which means we should clear error list
      if (isFalsy(errors)) {
        this._errors = [];
      }
      // At this point just set it to whatever might have been passed in and let
      // the user debug when it is broken.
      this._errors = errors;
  }

  get errors() {
    return this._errors;
  }
}

우리도 그랬나요? setter와 getter를 사용하여 다른 유형을 반환할 수 있는 가능성을 정말로 갖고 싶습니다. 예를 들어:

class Field {
  private _value: string;

  get value(): string {
    return this._value;
  }

  set value(value: any) {
    this._value = String(value);
  }
}

이것은 네이티브 구현의 99%를 수행하는 것입니다( (input as HTMLInputElement).value 에 숫자를 전달하면 항상 문자열을 반환합니다. 사실 get 및 set 은 메서드로 간주되어야 하며 일부를 허용해야 합니다.

set value(value: string);
set value(value: number);
set value(value: any) {
  this._value = String(value);
}
  // AND/OR
set value(value: string | number) {
  this._value = String(value);
}

@raysuelzer , 코드가 "작동"한다고 말할 때 ErrorNotificationComponent.errors 는 Array<string> | any 유형을 반환하지 않습니까? 즉, 실제로 Array<string> 반환할 수 있다는 것을 알 때 사용할 때마다 유형 가드가 필요합니다.

@lifaon74 , 내가 아는 한 이 문제에 대한 움직임이 없습니다. 여러 시나리오가 제시되고 이로 인해 Typescript에서 적절하게 설명할 수 없는 수많은 레거시 JS 코드가 제시되었지만 문제는 종결되었습니다. 현장의 사실이 달라졌다고 생각한다면 새로운 사실을 여는 것이 좋을까요? 나는 오래된 주장을 다시 읽는 것에 대한 팀의 정책을 모르지만 나는 당신의 등을 받겠습니다.

나는 오래된 주장을 다시 읽는 것에 대한 팀의 정책을 모르지만 나는 당신의 등을 받겠습니다.

그들은 이전에 닫힌 주제를 재고할 것입니다. 이슈 상단에 👍를 붙이면 의미가 있다는 믿음을 줍니다. 나는 그것이 일반적으로 유형 시스템이 모든 읽기 및 쓰기에서 분기되어야 함을 의미하기 때문에 "너무 복잡한" 범주에 속한다고 생각합니다. 유효하지만 다소 드문 사용 사례는 그만한 가치가 없습니다.

내 개인적인 느낌은 특히 이 패턴을 효과적으로 사용하는 기존 JavaScript 코드를 모델링할 수 있다는 점에서 _있으면 좋은_ 것입니다.

저는 개인적으로 레거시 JS 문제에 대해 전혀 부담스럽지 않은 해결 방법을 생각해 낸다면 문제가 해결된 것으로 간주할 것입니다. 나는 여전히 일종의 TS Greenhorn이므로 현재 솔루션(강제 캐스팅 또는 불필요한 유형 가드)이 기존 기능을 최적으로 사용하지 않는 것일까요?

동의하다. setter 유형이 같아야 하는 경우 너무 제한적입니다... 개선하십시오.

이를 수행하기 위한 권장 사항을 찾고 있습니다.

get price() {
    return (this._price as number);
  }

  set price(price) {
    this._price = typeof price === 'string' ? parseFloat(parseFloat(price).toFixed(8)) : parseFloat(price.toFixed(8));
  }

저장된 값이 숫자가 되기를 원하지만 속성을 설정할 때마다 parseFloat를 수행할 필요가 없도록 setter에서 문자열에서 float로 변환하고 싶습니다.

나는 이것이 Typescript 내부에 잘 맞지 않는 유효한(또는 최소한 합리적으로 잘 받아들여진) Javascript 패턴이라고 평결을 내렸습니다. 내부 변경이 너무 큰 변경이라면 TS가 내부적으로 컴파일되는 방식을 변경하는 일종의 주석을 얻을 수 있습니까? 같은 것

class Widget {
  get price(): number | /** <strong i="7">@impossible</strong> */ string | undefined { return this._price; }
  set price(val: number|string|undefined){ ... }
}

let w = new Widget();
w.price = 10;
// Annotation processes as "let p:number|undefined = (w.price as number|undefined)"
let p: number|undefined = w.price;

즉, TS가 JS로 변환되기 전에 전처리기(?)가 w.price 의 모든 읽기를 명시적 캐스트로 변환하도록 TS를 마크업할 수 있습니다. 물론 TS가 주석을 관리하는 방법의 내부를 알지 못하므로 이것은 완전히 쓰레기일 수 있지만 일반적인 아이디어는 TS 변환기를 JS를 생성합니다.

이 기능이 필요하지 않다는 것은 아니지만 set 를 우회하는 방법이 있습니다. IMO get 는 항상 동일한 변수 유형을 반환해야 하므로 이 정도면 충분했습니다.

class Widget {
    get price(): number { return this._price; }
    set price(val){ return this.setPrice(val); } // call another function

    // do processing here
    private setPrice(price: number | string): number {
        let num = Number(price);
        return isNaN(num) ? 0 : num;
    }
}

@iamjoyce widget.price = '123' 는 코드에서 컴파일 오류를 발생시킵니다.

@iamjoyce => 컴파일러가 $ set price(val) val: number 를 가정하기 때문에 잘못되었습니다.

예, Angular의 구성 요소 사용이 다른 getter/setter 유형을 갖기를 원하기 때문에 저도 여기에 있습니다.

Angular는 입력 속성의 유형에 관계없이 (바인딩 표현식을 사용하지 않는 한) 마크업에서 구성 요소 속성을 설정하면(속성을 통해) 항상 문자열을 주입합니다. 따라서 다음과 같이 모델링할 수 있다면 정말 좋을 것입니다.

private _someProperty: SomeEnum;
set someProperty(value: SomeEnum | string) {
   this._someProperty = this.coerceSomeEnum(value);
} 
get someProperty(): SomeEnum {
  return this._someProperty;
}

오늘날 이것은 | string 를 생략하면 작동하지만 Angular가 구성 요소를 사용하는 방법을 더 정확하게 설명할 수 있습니다. 코드에서 액세스하면 속성의 유형이 중요하지만 속성처럼 설정하면 문자열이 강제로 입력됩니다.

우리는 이런 방식으로 API를 설계하고 싶기 때문에 일반적으로 이 기능을 원하지 않는다고 생각합니다. 나는 속성이 덮개 아래에서 강제 부작용을 일으키지 않는 경우 더 낫다는 데 동의합니다. 이 문제를 해결하려면 속성 집합 대 바인딩 속성 집합이 서로 다른 진입점에 들어가도록 Angular가 설계되었으면 좋았을 것입니다.

그러나 이것을 실용적으로 보면 TypeScript가 읽기/쓰기 유형 평등 공리를 무시하는 방식으로 우리 유형을 사용하는 외부 라이브러리와의 상호 작용을 모델링할 수 있게 해준다면 도움이 됩니다.

이 경우 모든 종류의 성가신 유형 가드/어설션이 필요하므로 getter에서 공용체 유형을 사용하는 것은 매우 문제가 됩니다. 그러나 어떤 도구라도 속성에서 설정되는 속성이 문자열에서 할당 가능해야 하는지 확인하려고 시도하기 시작할 수 있기 때문에 setter에서 공용체 유형을 남겨두는 것은 잘못된 것 같습니다.

따라서 이 경우 유형 시스템은 외부 라이브러리가 유형을 사용하도록 허용되는 방법을 캡처할 만큼 충분히 표현적이지 않습니다. 이것은 외부 라이브러리가 실제로 유형 정보와 함께 유형 스크립트 수준에서 이러한 유형을 소비하지 않기 때문에 _즉각적으로_ 중요하지 않습니다. 그러나 도구가 유형 정보를 매우 잘 소비할 수 있으므로 결국 중요할 수 있습니다.

위의 한 사람은 약간 불쾌해 보이지만 아마도 작동할 수 있는 대체 솔루션을 언급했습니다. 이렇게 하면 setter/getter 모두에 대해 공용체 유형을 사용할 수 있지만 공용체의 특정 유형이 getter에 대해 불가능하다는 것을 나타내는 방법이 있습니다. 실제로 누군가가 유형 가드를 사용하여 존재하지 않는지 확인하는 것처럼 getter 호출 사이트 사이트 제어 흐름에서 고려 사항에서 사전 제거됩니다. 그러나 getter의 하위 집합 합집합과 비교하여 setter의 상위 집합 합집합을 허용하는 것과 비교하면 성가신 것 같습니다.

그러나 아마도 그것이 내부적으로 문제를 해결하는 방법일 것입니다. setter가 getter 유형의 상위 집합 조합인 한. getter 및 setter 유형을 내부적으로 동등하게 취급하지만 getter의 공용체 유형 부분을 불가능한 것으로 표시합니다. 따라서 제어 흐름 분석은 고려 사항에서 제거합니다. 설계 제약을 피할 수 있습니까?

위의 내용을 자세히 설명합니다. 복합형의 일부를 불가능한 것으로 표시할 수 있는 것이 타입 표현성의 관점에서 유용한 것일 수도 있습니다. 이것은 구조가 동일하지만 불가능한 수정자가 없는 다른 유형과의 동등성에 영향을 미치지 않습니다. 불가능한 수정자는 제어 흐름 분석에만 영향을 미칩니다.

대체 제안으로 사용자 정의 유형 가드를 반환 값에 적용하는 구문이 있다면 이것으로도 충분합니다. 정상적인 상황에서는 이것이 약간 우스꽝스럽지만 반환 값과 인수에 대해 그런 종류의 표현이 있으면 이러한 극단적인 경우를 해결하는 데 도움이 될 것입니다.

반환 값에 대한 사용자 정의 유형 보호는 속성으로 압축될 때 유형 선언/인터페이스에서 표현할 수 있는 이점도 있습니다.

여기에 다른 사용 사례를 추가하기만 하면 mobx-state-tree를 사용하여 몇 가지 다른 방법(인스턴스 및 스냅샷 유형에서)으로 속성을 설정할 수 있지만 get 접근자에서 단일 표준 방식(인스턴스)으로만 속성을 반환합니다. 지원된다면 매우 유용할 것입니다.

나는 다음과 같이 이 문제를 해결하고 있다.

interface SomeNestedString {
  foo: string;
}

...

private _foo: SomeNestedString | string;

get foo(): SomeNestedString | string {
  return this._foo;
}

set foo(value: SomeNestedString | string) {
  this._foo = (value as SomeNestedString).foo;
}

나는 그것이 당면한 문제를 해결한다고 생각하지 않습니다. 실제로는 getter가 공용체 유형의 하위 집합만 반환하더라도 getter를 사용할 때 여전히 유형 가드가 필요합니다.

TSLint를 해결하기 위해 any 를 사용하고 있습니다. 그리고 컴파일러도 불평하지 않습니다.

export class FooBar {
  private bar: string;

  get foo (): string | any {
    return this.bar;
  }

  set foo (value: Date | string | any) {
    // Type guarding enables IntelliSense in VS Code
    if (value instanceof Date) {
      this.bar = value.toISOString();
    } else if (typeof value === 'string') {
      this.bar = value;
    } else {
      this.bar = String(value); // Or throw an error
    }
  }
}

@jpidelatorre 이런 식으로 유형 안전성을 잃게 됩니다.

const fooBar = new FooBar()
const a: number = fooBar.foo // works while it should fail
fooBar.foo = 123 // fails only at runtime, not compile time. It doesnt fail in this particular case with strings and numbers, but it will with something more complex

@keenondrums 이것이 바로 우리가 접근자가 다른 유형을 가지기를 원하는 이유입니다. 내가 찾은 것은 해결책이 아니라 해결 방법입니다.

@jpidelatorre 현재 해결 방법은 다른 기능을 setter로 사용하는 것입니다.

export class FooBar {
  private bar: string;

  get foo (): string {
    return this.bar;
  }

  setFoo (value: Date | string ) {}
}

@keenondrums 접속자만큼은 아니지만 아직까지는 최선의 선택입니다.

getter에 대해 별도의 함수를 사용하지 않는 한 Angular 구성 요소의 @input 속성으로 발생하는 일에 대한 모델이 아닙니다.

너무 추악합니다.

나는 또한 이 기능을 원하지만 해결 방법이 없는 .d.ts 파일에서 잘 작동해야 합니다. Mocha(Objective-C/Javascript 브리지)를 통해 노출된 일부 클래스를 문서화하려고 하고 래핑된 항목의 인스턴스 속성은 다음과 같이 설정됩니다.

class Foo {
    get bar:()=>number;
    set bar:number;
}

const foo = new Foo();
foo.bar = 3;
foo.bar(); // 3

또한 API를 사용하여 인터페이스와 일치하는 객체로 속성을 설정할 수 있지만 getter는 항상 실제 클래스 인스턴스를 반환하는 경우를 많이 보았습니다.

interface IFoo {
    bar: string;
}

class Foo implements IFoo {
    bar: string;
    toString():string;
}

class Example {
    get foo:Foo;
    set foo:Foo|IFoo;
}

나는 이 문제에 대해 대체로 잊고 있었지만, 그것을 다시 읽으면서 한 가지 생각이 떠올랐다. 나는 이것이 추상적으로 할 가치가 있지만 실현 가능하기에는 너무 기술적으로 복잡하다는 아이디어에 정착했다고 생각합니다. 그것은 절충점 계산입니다. 기술적으로 불가능한 것은 아니며 구현하는 데 시간과 노력(및 코드 복잡성 추가)의 가치가 없습니다. 오른쪽?

이것이 핵심 DOM API를 정확하게 기술하는 것을 불가능하게 만든다는 사실이 수학을 전혀 변경합니까? @RyanCavanaugh 라고

나는 이 코드 foo.bar = "hello"; console.log(foo.bar); 가 정상적인 의미를 가지려고 시도하는 언어에서 "hello" 이외의 모든 것을 인쇄해야 한다는 생각에 진정으로 반대합니다.

이런 식으로 사용해야 하는지에 대해 논쟁할 수 있지만 DOM은 항상 el.hidden=1; console.log(el.hidden) // <-- true, not 1 와 같은 구성을 지원했습니다. 이것은 단지 소수의 사람들이 사용하는 패턴이 아니며 인기 있는 라이브러리에 있기 때문에 지원하는 것이 좋습니다. JS가 항상 어떻게 작동했는지에 대한 핵심 교리입니다. DWIM이 언어의 핵심에 녹아들어 있습니다. 언어 수준에서 이를 불가능하게 만드는 것은 JS의 "상위 집합"이어야 한다는 TS의 기본 원칙을 깨는 것입니다. . 그것은 벤다이어그램에서 튀어나온 못생긴 거품이며, 우리는 그것을 잊어서는 안됩니다.

이것이 내가 여전히 동일한 유형의 setter/getter를 유지하는 아이디어를 좋아하는 이유입니다.

number | boolean

그러나 getter가 기술적으로 동일한 공용체 유형을 갖지만 실제로는 공용체에 있는 유형의 하위 집합만 반환한다는 것을 나타낼 수 있는 일종의 typegaurd를 도입합니다. getter(추론 흐름 문제?)에서 일종의 좁히는 가드로 처리하면 유형 모델을 수정하는 것보다 더 간단해지지 않습니까? (그는 내부에 대해 아무것도 모른다고 말한다...)

또는 getter에 사용된 유형이 setters 유형의 엄격한 하위 집합인 경우에만 암시될 수 있습니까?

또는 getter에 사용된 유형이 setters 유형의 엄격한 하위 집합인 경우에만 암시될 수 있습니까?

👍 !

설정 가능하지 않은 유형을 얻을 수 없어야 한다는 데 우리 모두 동의할 수 있다고 생각합니다. get 의 유형을 자동으로 좁힐 수 있는 방법을 사용하여 항상 그런 유형이 되도록 하고 싶습니다.

나는 왜 일부 사람들이 그것이 유형 안전과 모든 것을 위반할 것이라고 반대하는지 이해하지 못합니다. 적어도 setter가 다른 유형을 가질 수 있도록 허용하는 경우 유형 안전성을 위반하는 것으로 보이지 않습니다.
전:
속성이 Array라고 가정해 보겠습니다.그러나 DB에서는 '10,20,40'과 같이 쉼표로 구분된 문자열로 반환됩니다. 하지만 지금은 그것을 모드 속성에 매핑할 수 없으므로 다음과 같이 허용할 수 있다면 매우 도움이 될 것입니다.

개인 _employeeIdList : 번호[]

EmployeeIDList() 가져오기: 숫자[] {
이것을 반환하십시오._employeeIdList ;
}
EmployeeIDList(_idList: 모든 ) 설정 {
if (typeof _idList== '문자열') {
this._employeeIdList = _idList.split(',').map(d => 숫자(d));
}
else if (typeof _idList== '객체') {
this._employeeIdList = _idList as number[];
}
}

나는 이 문제를 쉽게 해결할 수 있었고 SET에서 다른 유형을 허용했지만 여전히 속성에 잘못된 유형을 할당하는 것을 막지만 완벽하게 유형 안전합니다. 그러니 승리하세요. 팀원들이 자존심을 내려놓고 그것이 만들어내는 문제를 생각하고 고쳐나가길 바랍니다.

나는 이것이 기존 JS 라이브러리의 동작을 모델링하는 데 여전히 중요하다고 생각한다는 점에서 차임하고 싶습니다.

코를 켜고 유형을 들어오는 유형의 하위 집합으로 강제 변환하고 항상 getter의 하위 집합을 코드 냄새로 반환하는 setter를 정의하는 것이 좋지만 실제로는 JS 영역에서 상당히 일반적인 패턴입니다. .

TypeScript는 이상적으로 구조화된 API가 없는 경우에도 기존 JS API의 상자를 설명할 때 매우 표현력이 뛰어나다는 점에서 훌륭하다고 생각합니다. TypeScript가 getter가 항상 getter 유형의 엄격한 하위 집합인 유형을 반환한다는 것을 나타낼 수 있을 만큼 표현력이 뛰어나면 기존 API 모델링에 엄청난 가치가 추가되는 장면이라고 생각합니다. 돔!

신뢰할 수 있는 유형 은 DOM XSS와 싸우기 위한 새로운 브라우저 API 제안입니다. Chromium에서 이미 구현되어 있습니다(플래그 뒤). API의 대부분은 신뢰할 수 있는 유형을 허용하도록 다양한 DOM 속성의 설정자를 수정합니다. 예를 들어 .innerHTML 는 TrustedHTML | string 를 허용하지만 항상 string 를 반환합니다. TypeScript에서 API를 설명하려면 이 문제를 수정해야 합니다.

이전 주석과의 차이점은 이것은 쉽게 변경할 수 없는 브라우저 API(사용자 영역 라이브러리가 아님)라는 것입니다. 또한 Element.innerHTML any (현재 가능한 유일한 솔루션)로 변경하는 영향은 사용자 영역 라이브러리를 부정확하게 설명하는 것보다 큽니다.

이 pull-request가 다시 열릴 가능성이 있습니까? 아니면 내가 놓친 다른 솔루션이 있습니까?

참조: @mprobst , @koto.

TypeScript와 같은 유형 통합을 지원하는 언어에서 이 기능은 자연스럽고 판매 포인트입니다.

@RyanCavanaugh getter와 setter가 같은 유형을 가지고 있더라도 setter로 o.x === y 이후의 o.x = y #$0$#$가 값을 저장하기 전에 일부 정리를 수행할 수 있다는 보장은 없습니다.

element.scrollTop = -100;
element.scrollTop; // returns 0

@vrana의 두 번째 우려 사항입니다. 현재 동작으로 인해 Typescript에서 기존 API 중 일부를 모델링할 수 없습니다.

이것은 setter와 getter 유형이 다른 많은 Web API에 특히 해당됩니다. 실제로 웹 API 설정자는 모든 종류의 유형 강제 변환을 수행하며, 그 중 일부는 주어진 브라우저 기능에 대해 직접 지정되지만 대부분은 IDL 을 통해 암시적으로 수행됩니다. 많은 setter가 값도 변경합니다(예: 위치 인터페이스 사양 참조). 이것은 단일 개발자 실수가 아닙니다. 웹 개발자가 코딩하는 API 사양입니다.

getter 유형을 좁히면 Typescript가 해당 API를 나타낼 수 있지만 이제는 불가능합니다.

속성의 유형이 setter에 제공하거나 getter에서 가져올 수 있는 가능한 유형의 조합이라고 말하는 것이 정확하기 때문에 이러한 API를 나타낼 수 있습니다.

API를 그런 식으로 설명하는 것은 _효율적_이 아닙니다. 소비자가 가능한 유형을 좁히기 위해 getter를 사용하는 모든 인스턴스에서 유형 가드를 사용하도록 요구하고 있습니다.

많은 Web API가 사양에 잠겨 있기 때문에 항상 getter에서 축소된 유형을 반환하는 것을 공리적으로 만들지 않았어도 괜찮습니다.

그러나 그것을 잠시 제쳐두고 사용자 API에 대해 이야기하더라도 setter 에서 공용체 유형을 수락하는 강력한 사용 사례는 "스크립트"입니다. 우리는 우리가 실제로 원하는 유형으로 수용 가능하게 강제할 수 있는 이산 유형의 범위를 허용하기를 원합니다.

왜 허용합니까? 사용의 용이성.

자체 팀에서 사용하기 위해 내부적으로 개발 중인 API에는 중요하지 않을 수 있지만, 공개되고 일반화된 사용을 위해 설계된 API에는 중요할 수 있습니다.

TypeScript를 사용하여 일부 속성에 대해 허용되는 유형을 완화한 API를 정확하게 설명할 수 있다는 것은 멋진 일이지만, getter 반환 유형을 결정하기 위해 과도한 유형 검사/보호가 필요한 다른 쪽 끝의 마찰로 인해 그 이점이 손상됩니다. , _지정_하는 것이 좋습니다.

나는 그것이 @RyanCavanaugh가 가정하는 이상적인 경우와 다른 시나리오라고 주장하고 싶습니다. 이 경우는 지원 필드에도 동일한 공용체 유형이 있기 때문에 getter 및 setter가 항상 동일한 공용체 유형을 가져야 하며 항상 해당 값을 왕복하게 되며 유형을 변경하는 것은 무의미하다는 것을 의미합니다.

내 생각에는 이 사례가 더 이상화된 공용체 유형 사용을 중심으로 한다고 생각합니다. 즉, 생성된 유형을 처리하고 실제로 해당 연합 유형을 의미 단위로 취급하므로 별칭을 생성해야 합니다.

type urlRep = string | Url;

대부분의 것은 그냥 왕복하고 일반적인 소품만 다루며 경우에 따라 일부 유형 가드로 블랙박스를 깨뜨릴 것입니다.

나는 그것이 우리가 여기서 설명하는 것과는 완전히 다른 시나리오라고 주장하고 싶습니다. 우리가 설명하는 것은 특히 JavaScript와 같은 스크립팅 언어에서 사용하기 위한 일반/공용 API가 종종 의도적으로 setter에 허용되는 유형을 완화한다는 사실입니다. 그들은 그것을 모두 수용하는 삶의 질 향상으로 제공합니다.

API의 생산자이자 소비자인 경우 이러한 종류의 작업이 더 많은 작업을 수행하기 때문에 무의미해 보일 수 있지만 대량 소비를 위한 API를 설계하는 경우에는 많은 의미를 가질 수 있습니다.

그리고 나는 아무도 setter/getter가 _disjoint_ 유형을 갖기를 원하지 않을 것이라고 생각합니다. 여기서 논의되는 것은 API 생산자가 API 소비자에게 getter가 setter의 통합 유형의 엄격한 하위 집합인 유형을 가진 값을 반환할 것이라고 주장한다는 것입니다.

그리고 나는 누구도 setter/getter가 분리된 유형을 갖기를 원하지 않을 것이라고 생각합니다.

그것에 대한 반대 관점을 제공하기 위해서입니다. setter/getter에 대해 분리된 유형을 갖는 것이 자바스크립트에서 완전히 합법적이기 때문에 확실히 원할 것입니다. 그리고 제 생각에 주요 목표는 (적어도 .d.ts 수준에서) 자바스크립트에서 합법적인 모든 것을 올바르게 입력할 수 있을 정도로 유형 시스템을 표현력 있게 만드는 것이어야 한다고 생각합니다. 예를 들어 전역 객체나 함수 등과 같은 내장의 프로토타입을 변경하는 것은 좋은 습관이 아니라는 것을 이해합니다. 그러나 우리는 여전히 .d.ts 파일에 그런 것들을 잘 입력할 수 있으며 아무도 그것을 후회하는 것을 듣지 못했습니다. 우리는 그렇게 할 수 있습니다(비록 잘못 설계된 일부 유형 정의 파일이 확실히 유형이 지정된 파일에 표시되기는 하지만).

내가 제어할 수 없는 올바른 유형을 갖기 위해 이것이 기능이 필요한 상황에 봉착했습니다. setter는 getter에서 일관되게 반환할 수 있는 보다 자유주의적이고 보다 보수적인 유형으로 강제해야 합니다.

이런 기능이 있었으면 정말 좋겠습니다. JavaScript 코드를 TypeScript로 이식하고 있는데, 유형 안전성을 원할 경우 setter를 리팩토링해야 하는 것은 정말 큰 문제입니다.

예를 들어, 다음과 같은 것이 있습니다.

class Vector3 { /* ... */ }

type XYZ = Vector3 | [number, number, number] | {x: number, y: number, z: number}
type PropertyAnimator = (x: number, y: number, z: number, timestamp: number) => XYZ
type XYZSettables =  XYZ | PropertyAnimator

export class Transformable {
        // ...

        set position(newValue: XYZSettables) {
            this._setPropertyXYZ('position', newValue)
        }
        get position(): Vector3 {
            return this._props.position
        }

        // ...
}

상상할 수 있듯이 사용법은 매우 유연합니다.

const transform = new Transformable

// use an array
transform.position = [20, 30, 40]

// use an object
transform.position = {y: 30, z: 40} // skip `x` this time

// animate manually, a property directly
requestAnimationFrame((time) => {
  transform.position.x = 100 * Math.sin(time * 0.001)
})

// animate manually, with an array, which could be shared across instances
const pos = [10, 20, 30]
requestAnimationFrame((time) => {
  pos[2] = 100 * Math.sin(time * 0.001)
  transform.position = pos
})

// Animate with a property function
transform.position = (x, y, z, time) => [x, y, 100 * Math.sin(time * 0.001)]

// or a simple increment:
transform.position = (x, y, z) => [x, y, ++z]

// etc

// etc

// etc

4살입니다. 어떻게 여전히 해결되지 않습니까? 이 기능은 위의 의견에서 언급했듯이 중요합니다! 적어도 문제를 다시 여는 것을 고려하시겠습니까?

그리고 나는 @kitsonk 에 완전히 동의합니다.

@kitsonk 위의 의견에서 설득력 있는 사용 사례가 충분히 제공되었다고 생각합니다. 현재 디자인은 이 제한이 있는 대부분의 다른 유형 언어의 공통 패턴을 따르지만 Javascript 컨텍스트에서는 불필요하고 지나치게 제한적입니다. 설계에 의한 것이지만 설계가 잘못되었습니다.

TypeScript 3.6은 선언 파일에 접근자를 입력하기 위한 구문을 도입 하면서 getter와 setter의 유형이 동일해야 한다는 제한을 유지했습니다.

우리의 UI 툴킷은 자동 캐스팅 setter에 크게 의존하는데, 여기서 setter는 getter에서 반환된 단일 유형보다 더 많은 유형을 허용합니다. 따라서 TS가 이 패턴을 유형 안전하게 만드는 방법을 제공하면 좋을 것입니다.

@RyanCavanaugh 가 3년 전에 이 기능에 대해 가장 구체적인 반박을 한 것 같습니다. 최근에 보고된 DOM 사용 사례와 새로운 선언 구문의 가용성이 새로운 결정을 허용할 수 있는지 궁금합니다.

네, 그 새로운 기능을 보자마자 바로 이 기능 요청이 생각났습니다. 나는 또한 우리의 UI 프레임워크의 목적을 위해 그것을 원합니다. 이것은 실제 사용 사례입니다.

TSConf 2019 가 10월 11일 에 개최됩니다. 기회가 된다면 Q&A 세션에서 좋은 회상이 될 것 같아요 🤔

이 긴 스레드에서 이전에 말했을지 모르지만 반복해야 한다고 생각합니다.

TypeScript의 IMO 표현형 시스템은 두 가지 별개의 목적을 수행합니다. 첫 번째는 더 안전한 새 코드를 작성할 수 있도록 하는 것입니다. 그리고 그것이 유일한 목적이라면 아마도 이 시나리오를 허용하지 않으면 코드가 더 안전할 수 있으므로 이 사용 사례를 피할 수 있다는 주장을 할 수 있습니다.

그러나 두 번째 목적은 라이브러리의 동작 을 있는 그대로 캡처하는 것이며 DOM 및 JS 라이브러리에서 setter에서 자동 강제 변환되지만 getter에서 하나의 예상 유형을 반환하는 것이 합리적으로 일반적인 관행입니다. 유형 시스템에서 이를 캡처할 수 있도록 하면 기존 프레임워크 를 있는 그대로 더 정확하게 설명할 수 있습니다 .

적어도 Design Limitation 는 여기에서 제거할 수 있다고 생각합니다. 더 이상 관련이 없다고 생각합니다.

이것은 실제로 프록시도 수행하기 어렵게 만듭니다.
https://stackoverflow.com/questions/57948140/typescript-proxy-which-returns-a-different-type-from-get-than-it-takes-for-set

이것은 분명히 #33749 .style.display = ...something nullable... 더 이상 유형 검사를 하지 않는다는 사실에 대한 이유입니다. 이는 무효성 정확성 문제로 제시됩니다. 그건 좀 뻔뻔하지 않습니까? 버그 수정으로 잘못된 레이블이 지정되었을 때 새로운 주요 변경 사항을 파악해야 하는 것은 성가신 일입니다. 개인적으로, 나는 null 에 빈 문자열이 하는 것보다 "기본값 사용"이라는 특별한 동작이 있다는 것이 훨씬 덜 놀랍다는 것을 알았습니다. 그리고 typescipt 3.7까지는 null을 사용하여 캡처하는 것을 선호했습니다. 어떤 경우든 이 제한을 해결하기 위해 의도적으로 잘못된 유형 주석에 레이블을 지정하면 업그레이드 문제를 분류하는 시간을 절약할 수 있습니다.

또한 이를 위한 경로를 찾는 데 관심이 있습니다. 앰비언트 컨텍스트에서만 허용된다면 어떻게 될까요? @RyanCavanaugh 가 복잡성 문제를 해결하는 데 도움이 될까요?

이에 대한 나의 사용 사례는 프록시가 약속을 반환하지만 설정 작업이 약속을 설정하지 않는 API가 있다는 것입니다. 지금은 TypeScript에서 이것을 설명할 수 없습니다.

let post = await loadPost()
let user = await loadUser()
post.author = user // Proxy handles links these two objects via remote IDs
await save(post)

// Somewhere else in code
let post = await loadPost()
let author = await post.author

형식 수정 네이티브 기능이든, 일반적인 프록시이든, TypeScript는 이러한 유형의 기능이 실수였다는 입장인 것 같습니다.

그들은 이 목록에서 6번과 7번을 제거해야 합니다(https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals#goals).

내 문제

set 메서드에서 항목을 배열로 푸시하고 get 메서드에서 전체 배열을 가져오고 싶습니다. 지금은 잘 작동하는 set myArray(...value: string[]) 를 사용해야 합니다. 이 문제에 많이 부딪쳤습니다... 이 문제를 제거하는 것을 고려하십시오. 정보 또는 경고는 이에 대해 잘 작동합니다.

예(하고 싶은 것)

class MyClass {
   _myArray: string[] = [];

   set myArray(value: string) {
      this._myArray.push(value);
   }

   get myArray(): string[] {
      return this._myArray;
   }
}

예 (내가해야 할 일)

class MyClass {
   _myArray: string[] = [];

   set myArray(...value: string[]) {
      this._myArray.push(value[0]);
   }

   get myArray(): string[] {
      return this._myArray;
   }
}

내가 필요할 때 생각해낸 한 가지 해결책은 속성을 union type 로 설정하는 것이었습니다. 내 시간은 API에서 문자열로 입력되지만 내 UI에 대한 Moment 개체로 설정해야 하기 때문입니다.

나의 예

class TimeStorage {
    _startDate: string | Moment = ""
    _endDate: string | Moment = ""

    set startDate(date: Moment | string) {
        this._startDate = moment(date).utc()
    }
    get startDate(): Moment | string {
        return moment.utc(this._startDate)
    }

    set endDate(date: Moment) { 
        this._endDate = moment.utc(date)
    }
    get endDate() { 
        return moment.utc(this._endDate)
    }
}

나는 파티에 조금 늦었지만 최근에이 문제에 직면했습니다. 그것은 흥미로운 딜레마이므로 조금 만지작거리고 있습니다.

이것이 우리가 만들고자 하는 것이라고 가정해 봅시다. 문자열과 숫자(어떤 용도로든)를 허용하는 속성을 가지고 있지만 속성은 실제로 문자열로 저장되어 있는 간단한 클래스입니다.

class Foo {
    constructor() {
        this._bar = '';
        this.baz = '';
    }

    // error: 'get' and 'set' accessor must have the same type.(2380)
    get bar(): string {
        return this._bar;
    }

    // error: 'get' and 'set' accessor must have the same type.(2380)
    set bar(value: string | number) {
        this._bar = value.toString();
    }

    public baz: string;
    private _bar: string;
}

이것은 불가능하고 여전히 강력한 타이핑을 원하기 때문에 추가 코드가 필요합니다. 이제 누군가가 다음과 같은 속성 라이브러리를 만들었다고 예를 들어 보겠습니다.

/**
 * Abstract base class for properties.
 */
abstract class Property<GetType, SetType> {
    abstract get(): GetType;
    abstract set(value: SetType): void;
}

/**
 * Proxify an object so that it's get and set accessors are proxied to
 * the corresponding Property `get` and `set` calls.
 */
function proxify<T extends object>(obj: T) {
    return new Proxy<any>(obj, {
        get(target, key) {
            const prop = target[key];
            return (prop instanceof Property) ? prop.get() : prop;
        },
        set(target, key, value) {
            const prop = target[key];
            if (prop instanceof Property) {
                prop.set(value);
            } else {
                target[key] = value;
            }
            return true;
        }
    });
}

이 라이브러리를 사용하여 다음과 같이 클래스에 대한 typed 속성을 구현할 수 있습니다.

class Bar extends Property<string, string | number> {
    constructor(bar: string | number) {
        super();
        this.set(bar);
    }

    get(): string {
        return this._bar;
    }

    set(value: string | number) {
        this._bar = value.toString();
    }

    private _bar: string;
}

class Foo {
    constructor() {
        this.bar = new Bar('');
        this.baz = '';
    }

    public bar: Bar;
    public baz: string;
}

그런 다음 이 클래스를 사용하면 bar 에 대한 안전한 getter 및 setter 유형을 갖게 됩니다.

const foo = new Foo();

// use property's typed setter
foo.bar.set(42);
foo.baz = 'foobar';

// use property's typed getter
// output: 42 foobar
console.log(foo.bar.get(), foo.baz);

그리고 속성 setter 또는 getter를 더 동적으로 사용해야 하는 경우 proxify 함수를 사용하여 래핑할 수 있습니다.

const foo = new Foo();

// use proxified property setters
Object.assign(proxify(foo), { bar: 100, baz: 'hello world' });

// use property's typed getter
// output: 100 hello world
console.log(foo.bar.get(), foo.baz);

// use proxified property getters
// output: {"bar":"100","baz":"hello world"}
console.log(JSON.stringify(proxify(foo)));

면책 조항: 누군가 이 코드를 가져와서 라이브러리에 넣거나 원하는 대로 하고 싶다면 자유롭게 하십시오. 너무 게으르다.

몇 가지 추가 메모만 하면 이 긴 목록에 스팸 메일을 보내지 않겠다고 약속합니다!

이것을 상상의 라이브러리에 추가하면:

/**
 * Create a property with custom `get` and `set` accessors.
 */
function property<GetType, SetType>(property: {
    get: () => GetType,
    set: (value: SetType) => void
}) {
    const obj = { ...property };
    Object.setPrototypeOf(obj, Property.prototype);
    return obj;
}

우리는 원래 클래스에 조금 더 가까운 구현을 얻었고 가장 중요한 것은 this 에 액세스할 수 있다는 것입니다.

class Foo {
    constructor() {
        this._bar = '';
        this.baz = '';
    }

    public bar = property({
        get: (): string => {
            return this._bar;
        },
        set: (value: string | number) => {
            this._bar = value.toString();
        }
    });

    public baz: string;
    private _bar: string;
}

세상에서 가장 예쁜 것은 아니지만 효과가 있습니다. 누군가가 이것을 개선하고 실제로 멋진 것을 만들 수 있습니다.

이 스레드를 읽는 개인이 이 기능이 중요하다고 확신하지 못하는 경우 를 대비하여 Angular가 방금 소개한 이 엄청나게 추한 해킹을 알려드립니다.

여기에서 값 유형을 부울에서 부울|''로 변경하여 setter가 실제로 허용하는 값 ​​세트와 일치시키는 것이 이상적입니다. TypeScript는 getter와 setter가 모두 동일한 유형을 가져야 하므로 getter가 부울을 반환해야 하는 경우 setter는 더 좁은 유형으로 고정됩니다.... Angular는 @Input()에 대해 더 넓고 허용적인 유형 검사를 지원합니다. 입력 필드 자체에 대해 선언됩니다. 구성 요소 클래스에 ngAcceptInputType_ 접두사가 있는 정적 속성을 추가하여 이를 활성화합니다.

````
클래스 제출 버튼 {
private _disabled: 부울;

비활성화(): 부울 {
이것을 반환하십시오._disabled;
}

비활성화 설정(값: 부울) {
this._disabled = (값 === '') || 값;
}

정적 ngAcceptInputType_disabled: 부울|'';
}
````

이 문제를 해결해 주세요 .

네, 문자 그대로 Angular가 사용하려는 패턴을 지원하기 위해 이 추악함이 곳곳에 있습니다. 현재의 제한은 너무 독단적입니다.

TS가 웹 랜드에서 전체 라이브러리를 모델링하는 데 사용되기를 원한다면 덜 독단적인 노력을 기울여야 합니다. 그렇지 않으면 모든 디자인을 모델링하지 못할 것입니다.

이 시점에서 이 문제가 다시 열리지 않는 이유를 전달하는 책임은 기여자에게 있다고 생각합니다. 현시점에서도 이에 대해 강력하게 반대하는 기고위원이 있습니까?

W3C 사양과 일치하는 NodeJ용 DOM 라이브러리를 구축하고 있지만 이 Typescript 문제로 인해 불가능합니다. 모든 업데이트?

TypeScript의 핵심 팀 내 일부가 지구상에서 가장 많이 사용되는 JavaScript 라이브러리 중 하나인 DOM을 재생성하기 위해 필요한 기능에 반대한다는 사실이 저에게는 충격적입니다.

a) W3C DOM 사양의 많은 부분을 구현하는 동안 b) TypeScript의 유형 시스템을 사용하는 다른 방법은 없습니다 any

typescriptlang.org의 홈페이지는 현재 다음과 같이 정확하지 않습니다.

TypeScript는 일반 JavaScript로 컴파일되는 JavaScript의 유형이 지정된 상위 집합 입니다.

JavaScript의 DOM 사양을 다시 만들 수 없다는 것은 TypeScript가 여전히 상위 집합 이 아니라 자바스크립트의 하위 집합임을 보여줍니다.

이 기능을 구현하는 것과 관련하여 저는 @gmurray81 및 getter의 유형이 setter의 공용체 유형의 하위 집합이어야 한다고 주장한 많은 다른 사람들의 의견에 동의합니다. 이렇게 하면 연결되지 않은 입력이 발생하지 않습니다. 이 접근 방식을 사용하면 setter의 함수가 getter의 유형을 손상시키지 않고 입력을 정리할 수 있습니다(예: any 사용에 의존해야 함).

여기 내가 할 수없는 일이 있습니다. JS에서는 비슷한 작업을 수행했지만 TS에서는 할 수 없는 간단한 작업입니다.

실제로 구현할 수 있는 4년 문제.

export const enum Conns {
  none = 0, d = 1, u = 2, ud = 3,
  r = 4, rd = 5, ru = 6, rud = 7,
  l = 8, ld = 9, lu = 10, lud = 11,
  lr = 12, lrd = 13, lru = 14, lrud = 15,
  total = 16
}

class  Tile {
  public connections = Conns.none;

  get connLeft() { return this.connections & Conns.l; };

  set connLeft(val: boolean) { this.connections = val ? (this.connections | Conns.l) : (this.connections & ~Conns.l); }
}

지금 이 문제에 직면해 있습니다. 아래는 @calebjclark 를 인용하는 합리적인 해결책처럼 보입니다.

이 기능을 구현하는 것과 관련하여 저는 @gmurray81 및 getter의 유형이 setter의 공용체 유형의 하위 집합이어야 한다고 주장한 많은 다른 사람들의 의견에 동의합니다. 이렇게 하면 연결되지 않은 입력이 발생하지 않습니다. 이 접근 방식을 사용하면 setter의 기능이 getter의 유형을 파괴하지 않고 입력을 정리할 수 있습니다(즉, any를 사용해야 하는 경우).

getter가 setter 유형의 하위 집합이기 때문에 불필요하게 제한적이라고 생각합니다. 실제로 구현이 항상 getter 유형의 하위 유형을 반환하는 한 setter 유형은 이론적으로 말 그대로 무엇이든 될 수 있습니다. setter가 getter 유형의 상위 유형이 되도록 요구하는 것은 이 티켓에 제시된 몇 가지 사용 사례를 충족할 수 있지만 나중에 반드시 불만을 제기할 수 있는 일종의 이상한 제한입니다.

즉, 클래스는 암시적으로 인터페이스이기도 하며 getter 및 setter는 기본적으로 인터페이스에 표시되지 않는 구현 세부 정보입니다. OP의 예에서는 type MyClass = { myDate(): moment.Moment; } 로 끝납니다. 이 새로운 getter 및 setter 유형을 인터페이스의 일부로 어떻게든 노출해야 하지만 그것이 바람직한 이유를 개인적으로 알지 못합니다.

이 문제는 기본적으로 = 및 === 연산자 오버로딩의 덜 제한된 버전을 요구합니다. (Getter와 setter는 이미 연산자 오버로딩입니다.) 그리고 다른 언어로 연산자 오버로드를 처리한 사람으로서 저는 대부분의 경우 피해야 한다고 생각합니다. 물론 누군가는 데카르트 및 극점과 같은 수학적 예제를 제안할 수 있지만 TS를 사용하는 대부분의 경우(이 스레드의 예제 포함) 연산자 오버로딩이 필요한 것은 아마도 코드 냄새일 것입니다. API를 더 단순하게 만드는 것처럼 보일 수 있지만 그 반대의 경향이 있습니다. 앞에서 언급했듯이 다음이 반드시 사실이 아닌 것은 매우 혼란스럽고 직관적이지 않습니다.

foo.x = y;
if (foo.x === y) { // this could be false?

(내 생각에 합리적으로 보이는 setter를 사용하는 경우는 로깅과 객체에 "dirty" 플래그를 설정하여 다른 것이 필드가 변경되었는지 여부를 알 수 있도록 설정하는 경우뿐이라고 생각합니다. 이 둘 중 어느 것도 실제로 계약을 변경하지 않습니다. 물체.)

@MikeyBurkman

[...] 하지만 TS를 사용하는 대부분의 경우(이 스레드의 예제 포함), 연산자 오버로딩이 필요한 것은 아마도 코드 냄새라고 주장할 것입니다. [...]

 foo.x = y; 
 if (foo.x === y) { // this could be false?

따라서 유형이 일치하는 것만으로는 놀라운 동작을 방지할 수 없으며 실제로 el.style.display = ''; //so is this now true: el.style.display === ''? 는 이것이 이론적인 것도 아님을 보여줍니다. 평범한 오래된 필드의 경우에도 NaN에 대해서는 가정이 성립하지 않습니다.

그러나 더 중요한 것은 TS가 DOM과 같은 주요 변경 사항을 포함하여 기존 JS API와 상호 운용해야 하기 때문에 TS가 이러한 사항에 대해 의견을 제시 할 수 없다는 점을 무시한다는 것입니다. 따라서 API가 이상적인지 여부는 중요하지 않습니다. 중요한 것은 TS가 그러한 주어진 API와 깔끔하게 상호 운용할 수 없다는 것입니다. 이제 API가 내부적으로 사용하는 폴백 논리를 다시 구현하여 setter에 전달된 getter 유형 이외의 값을 강제 실행하여 속성을 getter 유형으로 입력 하거나 유형 검사를 무시하여 추가해야 합니다. 각 getters 사이트에서 쓸모없는 유형 어설션을 사용하므로 속성을 setters 유형으로 입력하십시오. 또는 더 나쁜 것은 TS가 이상적인지 여부 에 관계없이 DOM에 주석을 추가하기 위해 선택하는 모든 일을 수행하는 것입니다.

그 선택은 모두 나쁘다. 이를 피하는 유일한 방법은 JS API를 가능한 한 충실하게 표현해야 할 필요성을 받아들이는 것입니다. 여기에서는 가능한 것 같습니다 (이를 결정적으로 중요하지 않게 만들 수 있는 TS 내부에 대한 지식 없이도).

가능한 것 같습니다(이를 결정적으로 중요하지 않게 만들 수 있는 TS 내부에 대한 지식 없이는 인정함)

나는 그들이 더 최근에 활성화 한 새로운 유형 선언 구문 중 일부가 이전에 실현 가능하지 않았을 때 이것을 표현할 수 있다고 생각하므로 이 문제를 다시 여는 것을 실제로 고려해야 합니다... @RyanCavanaugh

이상적인 세계에서 TS는 모든 JS API와 상호 운용됩니다. 하지만 그렇지 않습니다. TS에 올바르게 입력할 수 없는 많은 JS 관용구가 있습니다. 그러나 나는 그들이 더 나쁜 것이 아니라 실제로 더 나은 프로그래밍 관용구로 이어지는 것을 수정하는 데 집중하고 싶습니다. 이것을 제정신으로 지원하는 것도 좋지만, 개인적으로 제한된 시간을 먼저 사용하는 것보다 훨씬 더 좋은 12가지가 있습니다. 이것은 그 목록에서 훨씬 아래에 있습니다.

@MikeyBurkman 우선순위 질문은 유효합니다. 제 주요 관심사는 @RyanCavanaugh 가 이 문제를 종료하고 삭제하기로 한 결정입니다. 이 스레드에서 지적한 모든 문제를 무시하는 것은 Typescript의 명시된 사명과 직접적으로 충돌합니다. 이는 Javascript의 "상위 집합"(하위 집합 대신)이 되는 것입니다.

예, 이 문제는 _아마도_ 결국 수정되어야 하는 문제이기 때문에 이 문제가 종료되어서는 안 된다는 데 동의할 수 있습니다. (사실 그렇게 될지는 의문이지만.)

이것을 제정신으로 지원하는 것도 좋지만, 개인적으로 제한된 시간을 우선적으로 사용하는 것보다 더 나은 수십 가지가 있습니다.

기존 DOM API와 기존 JS API를 더 안전하게 사용할 수 있도록 해준다는 점에서 TypeScript의 중요한 측면을 과소평가하고 있다고 생각합니다. 그것은 거품 내에서 자신의 코드 이상을 안전하게 유지하기 위해 존재합니다.

내 관점은 다음과 같습니다. 구성 요소 라이브러리를 빌드하고, 내 druthers에게 주어진 setter/getter 간의 불일치를 의도적으로 발생시키지는 않을 것입니다. 때때로 내 라이브러리가 제자리에서 다른 시스템과 인터페이스해야 하는 방식에 따라 강제로 손을 뗍니다. 예를 들어 Angular는 대상 유형에 대한 지식을 기반으로 유형 강제 변환을 수행하기보다는 마크업에서 오는 구성 요소의 모든 입력 속성을 문자열로 설정합니다(최소한 마지막으로 확인함). 그래서, 당신은 문자열을 받아들이기를 거부합니까? 유형을 사용하기 끔찍하게 만들더라도 모든 것을 문자열로 만드십니까? 아니면 TypeScript가 시키는 대로 하고 다음과 같은 유형을 사용합니까? string | 색상을 지정하지만 게터를 사용하면 끔찍합니다. 이것들은 모두 타입 시스템의 약간의 추가 표현이 도움이 되었을 때 안전성을 감소시키는 매우 끔찍한 옵션입니다.

문제는 이러한 문제를 일으키는 것이 Angular만이 아니라는 것입니다. Angular는 속성 집합에서 자동 강제 변환이 발생하는 DOM의 많은 시나리오를 반영하기 때문에 이러한 상황에서 문제가 발생하지만 getter는 항상 예상되는 단일 유형입니다.

참고로 Angular는 생각보다 훨씬 나쁩니다 .

나에게 그것은 일반적으로 키-값 쌍을 저장할 수 있는 일부 범용 저장소 주위에 래퍼를 만들고 사용자를 특정 키로 제한하려는 경우의 문제입니다.

class Store {
  private dict: Map<string, any>;

  get name(): string | null {
    return this.dict.get('name') as string | null;
  }

  set name(value: string) {
    this.dict.set('name', value);
  }
}

값이 이전에 설정되지 않았지만 null 로 설정할 수 없는 경우 사용자는 null 를 얻을 수 있습니다. 현재로서는 setter 입력 유형에 null 가 포함되어야 하므로 할 수 없습니다.

@fan-tom, 이 문제를 다시 열어야 하는 이유에 대한 훌륭한 사용 사례입니다! 계속 오세요.

이 문제는 매우 높은 투표 수를 가지고 있습니다!

이것은 TS팀의 프로젝트이기 때문에 원하는 대로 마음껏 즐길 수 있습니다. 그러나 외부 사용자 커뮤니티에 이 기능을 최대한 유용하게 만드는 것을 목표로 한다면 TS 팀이 커뮤니티의 높은 투표 수를 강력하게 고려할 수 있기를 바랍니다.

typescriptlang.org의 홈페이지는 현재 다음과 같이 정확하지 않습니다.

TypeScript는 일반 JavaScript로 컴파일되는 JavaScript의 유형이 지정된 상위 집합 입니다.

TypeScript는 일반 JavaScript로 컴파일되는 JavaScript _subset_의 유형이 지정된 _superset_입니다. : 스마일 :

TypeScript는 일반 JavaScript로 컴파일되는 JavaScript 하위 집합의 유형이 지정된 상위 집합입니다.

좀 더 외교적으로 말하자면, 팀이 유형 시스템 모델링에서 이런 종류의 독단적인 생략을 할 때 JavaScript의 독단적인 상위 집합이라고 말할 수 있습니다.

그들은 "우리가 하기 어렵기 때문에 우리는 이것을 모델링하지 않을 것이며, 어쨌든 당신이 해서는 안 된다고 생각합니다"라고 말합니다. 그러나 JavaScript는 _해서는 안 되는_ 일들로 가득 차 있으며 일반적으로 Typescript는 의지와 노하우가 있다면 이러한 일을 하는 것을 차단하지 않습니다. 왜냐하면 일반적인 전략은 JavaScript에 대해 독단적이지 않는 것 같기 때문입니다. Typescript로 실행할 수 있고 실행할 수 없습니다.

이것이 API가 setter 기반 강제 변환을 수행하지 않아야 한다는 믿음을 인용하면서 이 일반적인(DOM에서 사용되는) 시나리오를 모델링하는 것을 거부하는 것이 이상한 이유입니다.

현재 이것은 불가능한 것 같으며 다음과 같은 방법을 사용해야 합니다.

class MyClass {

    private _myDate: moment.Moment;

    get myDate(): moment.Moment {
        return this._myDate;
    }

    set myDate(value: moment.Moment) {
        assert.fail('Setter for myDate is not available. Please use: setMyDate() instead');
    }

    setMyDate(value: Date | moment.Moment) {
        this._myDate = moment(value);
    }
}

당신이 할 수 있는 최선은 생성자를 추가하고 거기에서 커스텀 setter 함수를 호출하는 것입니다. 만약 그것이 당신이 그 값을 설정하는 유일한 시간이라면.

constructor(value: Date | moment.Moment) {
    this.setMyDate(value);
}

값을 직접 할당할 때의 문제는 여전히 남아 있습니다.

5.5년이 지난 후 이에 대한 업데이트가 있습니까?

@xhliu 는 레이블에서 알 수 있듯이 너무 복잡하여 해결하기 어려운 설계 제한 사항이므로 문제가 종료되었습니다. 나는 업데이트를 기대하지 않을 것입니다. 닫힌 문제의 시간 길이는 일종의 관련이 없습니다.

다시 열어주세요. 또한 이것은 인터페이스 수준에서 추가되어야 합니다. 고전적인 예는 읽고 쓸 수 있는 것에 대해 완전한 유연성이 있는 프록시를 구현할 때입니다.

@xhliu ... 너무 복잡해서 다루기 어렵습니다...

https://ts-ast-viewer.com/#code/MYewdgzgLgBFCm0DyAjAVjAvDA3gKBkJgDMQQAuGAIhQEManKvAXzzwWXQDpSQg

const testObj = {
    foo: "bar"
}

testObj.foo

기호 foo는 다음과 같이 말합니다.

  foo
    flags: 4
    escapedName:"foo"
    declarations: [
      PropertyAssignment (foo)
    ]
    valueDeclaration: PropertyAssignment (foo)

여기에는 추가 정보를 위한 공간이 많이 있으며 이는 TS를 위한 훌륭한 디자인입니다. 이것을 설계한 사람은 아마도 미래에 추가 기능(심지어 큰 기능도 포함)을 가능하게 하기 위해 특별히 그렇게 했을 것입니다.

이 시점부터 추측:

의사 코드 예제의 경우 accessDelclaration: AccessSpecification (foo) 를 선언할 수 있으면 foo 기호와 해당 선언을 인식하는 PropertyAccessExpression 가 "accessDelclaration" 및 대신 입력을 사용하십시오.

accessDelclaration 속성을 "foo" 기호에 추가하는 구문이 있다고 가정하면 PropertyAccessExpression은 ts.createIdentifier("foo") 에서 가져오는 기호에서 "AccessSpecification"을 가져와서 다른 유형을 생성할 수 있어야 합니다.

ts.createPropertyAccess(
  ts.createIdentifier("testObj"),
  ts.createIdentifier("foo")
)

추측컨대, 이 문제의 가장 어려운 부분은 구문(또는 아마도 회사 철학?)과 관련된 자전거 사고의 양일 가능성이 높지만 구현 관점에서는 도구가 모두 있어야 합니다. ts.createPropertyAccess() 함수에 단일 조건이 추가되고 해당 조건과 그 효과를 나타내는 선언 클래스가 개체 속성의 기호에 추가되어야 합니다.

이것이 절실히 필요한 이유(특히 DOM 및 Angular의 경우)에 좋은 예가 많이 작성되었습니다.

string 를 window.location 에 할당하는 것이 작동하지 않고 as any 해결 방법을 수행해야 하는 TS로 이전 JS 코드를 마이그레이션할 때 오늘 이 문제를 겪었습니다. 😟

Window.location 읽기 전용 속성은 문서의 현재 위치에 대한 정보가 포함된 Location 개체를 반환합니다.

Window.location은 읽기 전용 Location 객체이지만 여기에 DOMString을 할당할 수도 있습니다. 이것은 대부분의 경우 위치가 문자열인 것처럼 작업할 수 있음을 의미합니다. location = ' http://www.example.com '은 location.href = ' http://www.example.com '의 동의어입니다. .
원천

string 를 window.location 에 할당하는 것이 작동하지 않고 as any 해결 방법을 수행해야 하는 TS로 이전 JS 코드 마이그레이션

좋은 예입니다.

TS는 이것이 필요합니다. 이것은 JavaScript의 매우 정상적인 부분입니다.

현재 문제가 종료되었음을 알 수 있습니다. 그런데 제가 알기로는 이 기능이 실현되지 않았습니까?

@AGluk , 이 문제를 다시 열어야 합니다.