Tslint: interface-over-type-literal은 권장되지 않습니다.

죄송합니다. 무슨 말씀이신지 모르겠습니다. 이것은 기능 요청입니까 아니면 버그 보고서입니까?

Recommended.ts에서 interface-over-type-literal의 기본값은 true입니다. 나는 그것이 거짓이어야 한다고 믿습니다. 그것이 기능 요청인지 버그인지 확실하지 않습니다 :-)

결국 권장되는 사전 설정은 독단적입니다. 위에 게시한 것과 같은 모범 사례와 제안 사항이 통합되어 있습니다.
사전 설정을 확장할 때 권장 사항을 무시하고 필요에 맞게 구성을 조정할 수 있습니다.

어쨌든 규칙을 비활성화하면 주요 변경 사항이 됩니다. 따라서 다음 주 버전 이전에 변경 사항을 기대하지 마십시오.

명확히 하자면: interface-over-type-literal 는 유형 별칭 선언에 대해서만 불평합니다.

type Foo = {foo: number}; // The rule disallows this
interface Foo {foo: number} // and fixes it to this

let obj: {foo: number}; // This is still allowed

유형 별칭과 인터페이스는 (거의) 서로 바꿔서 사용할 수 있으므로 유형 별칭을 선호하는 이유를 모르겠습니다.

관련 참고 사항: 유형 별칭과 같은 익명 유형이 계속 사용되도록 다시 계산되는 동안 인터페이스가 캐시되는 데 사용되었습니다. 따라서 유형 별칭을 사용하면 컴파일 시간이 크게 늘어날 수 있습니다.
그 성능 격차는 다음 타이프스크립트 버전에서 거의 사라질 것입니다.

나는 그것을 무시할 수 있다는 것을 알고 있지만 권장 사항이 올바르지 않다고 매우 강하게 느낍니다.

여기 내 견해가 있습니다. 유형 별칭에 대해 인터페이스를 사용할 수 없는 경우가 많습니다. 인터페이스를 사용하여 개체 리터럴을 입력할 수만 있습니다. 권장되는 모범 사례를 따르려면 여러 유형 별칭이 있을 수 있는 특정 클래스 파일에서 일부는 유형 별칭이 되고 일부는 인터페이스가 됩니다. 이 클래스를 우연히 발견한 누군가는 도대체 무슨 일이 일어나고 있는지 그리고 내가 인터페이스를 어딘가에 구현/확장할 의도인지, 또는 적어도 그것이 가능성이 있기를 기대하고 있는지 궁금해 할 것입니다.

인터페이스에 몇 가지 추가 기능이 있기 때문에 어떤 경우에는 다른 하나를 대체하는 것보다 유형 별칭에 유형 별칭을 사용하고 인터페이스에 인터페이스를 사용하는 것이 훨씬 더 깨끗할 것입니다. 원하는 모든 것이 유형 별칭인 경우).

타이프스크립트 문서에 대한 문제를 작성해야 한다고 가정하고, 그렇게 할 것입니다. 하지만 문서에서 해야 한다고 해서 규칙을 구현하는 것보다 여기에 약간의 공학적 판단을 적용할 수 있다고 생각합니다.

내 생각에는 구조에 대해 인터페이스 키워드를 사용하는 것은 정말 권장되지 않습니다. 이 규칙은 정반대이므로 지옥에서 이것이 모범 사례로 간주될 수 있는 방법은 없습니다.

이것은 내 생각에 typescript가 잘못한 것 중 하나입니다. 이것은 내가 사용한 다른 모든 typesafe 언어의 의미가 "메소드/함수/호출 가능한 것의 모음"을 의미하는 인터페이스 개념을 개체 서명/과 혼동합니다. 오리형. 인터페이스 사용은 더 제한적이어야 하며 TSLint 규칙 "interface-must-declare-only-functions" 또는 덜 제한적인 "interface-must-declare-at-least-one-function"을 환영합니다.

순수 구조는 유형 연산자를 사용하여 선언하고 & 연산자를 사용하여 확장해야 합니다. 그리고 이름은 "T"로 시작해야 합니다 :-)

@navels 귀하의 의견에 동의합니다 tslint:recommended 는 다음 주요 버전의 주요 변경 사항으로 이 지나치게 의견이 많은 규칙 구성을 제거해야 한다고 생각합니다.

이 옵션을 어떻게 무시할 수 있습니까?

tslint.json 의 @sibelius "rules" false 표시하십시오.

{
    "extends": ["tslint:recommended"],
    "rules": {
        "interface-over-type-literal": false
    }
}

이 문제는 권장 규칙 집합의 규칙 비활성화를 추적하고 있습니다. TSLint에 대한 일반적인 질문이 있는 경우 StackOverflow 또는 Gitter를 사용하세요.

여기 누군가가 이 주제에 대해 이야기합니다. https://medium.com/@martin_hotell/interface -vs-type-alias-in-typescript-2-7-2a8f1777af4c

덮어쓰기 규칙에 대해 인터페이스 대신 유형을 사용하도록 하는 옵션을 선호하거나 반응에서 Props 또는 State 를 정의하는 경우에만 유형을 사용하도록 강제하는 옵션을 선호합니다. 요소.

현재 프로젝트에서 전혀 사용하지 않을 정도로 OOP 코드를 점점 더 적게 작성하고 있습니다.
나는 초보자가 그것에 대해 넛지하는 것을 원하지 않습니다.

@dandrei 와 저는 기능을 설명하고 싶을 때 인터페이스만 사용합니다(OOP도 사용하지 않음).

예, 이것은 확실히 잘못된 것이고 IMO는 권장 사항의 일부가 아니거나 최소한 자동 수정되어서는 안 되므로 우리 유형을 방해하기 전에 비활성화할 수 있습니다.

권장 사항은 실제로 코드를 중단합니다. 고려하다:

type Foo = {
  foo: string
}

interface IndexedObject {
  [key: string]: string
}

function useIndexedObject(object: IndexedObject) {}

const foo: Foo = {foo: "foo"}
useIndexedObject(foo)

위의 코드가 작동합니다. tslint --fix 가 적용되고 type Foo 가 interface Foo 로 변경될 때까지 마지막 줄에서 오류가 발생합니다.

Argument of type 'Foo' is not assignable to parameter of type 'IndexedObject'.
  Index signature is missing in type 'Foo'.

IMO, 코드를 깨는 모든 규칙은 권장 사항이 되어서는 안 됩니다. 젠장, 코드를 깨뜨릴 가능성이 있다면 규칙이 되어서도 안 됩니다.

뿐만 아니라 "인터페이스는 'I'로 시작해야 함" 규칙이 발생합니다.

error TS2344: ...
Index Signature is missing in type 'SOME INTERFACE'.

그래서 type 을 사용해야 합니다.

앱에 type 사용량이 많으면 SOLID 원칙 위반의 좋은 지표입니다.

#4811에 따라 Type: Breaking Change 레이블을 제거합니다. 지금 PR을 받고 있습니다!

그렇다면 InterfaceScript라는 이름을 지정해야 할 때 TypeScript라고 불리는 이유는 무엇입니까? 🤣