Typescript: 모듈이 인터페이스를 구현하도록 허용

이것이 외부 모듈과 어떻게 작동합니까? 사람들이 내부 용으로 사용할 수있게되면 외부 용으로도 사용하기를 원할 것입니다.

그건 좋은 질문이야. 어떤 구문이 가장 좋을지 모르겠지만 여기에 몇 가지 제안이 있습니다.

implements Showable; // I would prefer this one.
module implements Showable;
export implements Showable;

내보내기 할당을 사용하는 경우 내보내는 항목이 이미 다른 위치에 implements 을 (를) 가질 수 있으므로 내보내기 할당을 사용하지 않는 외부 모듈에서만 허용되어야합니다.

승인되었습니다. 우리는 구문을 선호합니다.

export implements Showable;

export = 파일 할당에는 이것이 필요하지 않다는 데 동의했습니다.

몇 가지 추가 질문 :

• 모듈이 선언 사이트에서 유형을 가질 수 있도록 허용하고 있으므로 사용 사이트에서도 유형을 갖도록 허용해서는 안됩니다. 예 :

declare module "Module" implements Interface { }

import i : Interface = require("Module");

• 병합 된 선언으로 무엇을합니까? 모든 선언의 집합에 인터페이스를 적용해야합니까? 가시성이 일치하지 않으면 어떻게됩니까?
  예 :

module Foo {
    export interface IBar {
        (a:string): void;
    }

    export module Bar implements IBar {  // should this be an error?
        export interface Interface {}
    }    

    function Bar(a: string) : void { }  // not exported
}

var bar: Foo.IBar = Foo.Bar;

주변 외부 모듈에서 허용되어야합니다. 이 모듈의 경우 두 가지 구문이 제 생각에 허용되어야합니다.

declare module "first" implements Foo { }
declare module "second"  {
  interface Bar { }
  export implements Bar; // this syntax is necessary, with the first syntax you can't reference Bar.  
}

아니면 Bar가 { 전에 구현 절의 범위에 있어야합니까?

유형 정보를 모듈 자체에 추가 할 수 있기 때문에 import 문에 유형 정보를 추가하는 것은 제 생각에는 실제로 유용하지 않습니다.

그리고 병합 된 선언의 경우 구현 절을 포함하는 모듈 블록이 인터페이스를 구현해야합니다. 또한 가시성 문제를 방지합니다.

이것이 # 2159와 어떤 관련이 있습니까? 네임 스페이스는 인터페이스를 구현합니까?

@jbondc 이것을 가지고 있다면 네임 스페이스에도 적용될 것입니다. 내부 모듈과 네임 스페이스는 동형으로 생각해야합니다.

"네임 스페이스"가 인터페이스를 구현할 수있는 구현 경로로 이동 하시겠습니까?

오 와우, 이것은 꽤 오랫동안 승인되었습니다. @RyanCavanaugh , @DanielRosenwasser , @mhegazy 당신이 두 번째 생각이나 조정이 없다면 나는 아마도 이것을 곧 구현할 것입니다.

나는 이전의 회의론을 철회하고 실제로 그것이 가져올 새로운 구조적 가능성을 위해 퇴장했습니다.

이에 따라 구현을 선언하는 블록 대신 인터페이스 집합체의 인터페이스를 시행하는 것을 고려하십시오. 네임 스페이스 / 모듈의 특성은 분산되어 있고 사소하지 않은 많은 구성 요소를 포함하는 것입니다. 이것을 사용하고 싶지만 동일한 파일에 전체 네임 스페이스 / 모듈을 정의하고 싶지는 않습니다. 이 경우 클래스를 사용하지 않는 이유는 무엇입니까?

@ Elephant-Vessel 모듈, 네임 스페이스, 패키지 또는 기능에 대해 이야기하고 있는지 잘 모르겠습니다.

@aluanhaddad 무슨 말이야?

이 토론이 시작된 시점에 모듈이 오늘날 의미하는 바가 아니었다는 것을 의미합니다. 이제 네임 스페이스라는 용어를 사용하여 OP에서 모듈로 설명 된 것을 참조하는 반면 모듈은 더 정확하고 호환되지 않는 의미를 취했습니다. 따라서이 구현에 참여하는 여러 파일에 대해 이야기 할 때 네임 스페이스 또는 모듈을 언급하고 있습니까?

나는 네임 스페이스를 언급하고있다. 이 스레드의 역사를 따르고 싶었 나봐요. 느슨해지지 않아서 미안합니다. 시스템에서 특정 고급 기능을 제공하기 위해 조립 된 하위 구성 요소 하지만 '네임 스페이스'만 사용하면 괜찮습니다.

그래서 typescript의 구조적 개념 네임 스페이스 를 활용하여 다른 [_generic modules_] 또는 클래스를 포함 할 수있는 [_generic modules_]에 대한 제약과 기대치를 설명하고 적용 할 수 있기를 원합니다.

제 희망은 우리가 시스템에서 더 높은 수준의 구조적 기대치를 더 잘 표현할 수 있다는 것입니다. 클래스는 잘 확장되지 않고 시스템의 원자 구성 요소로도 괜찮지 만 인스턴스화되고 상속되도록 설계되었으므로 시스템의 상위 수준 조직 구조를 클래스로 표현하는 것이 좋지 않다고 생각합니다. . 너무 bloaty입니다.

시스템의 고차 구조를 간단하고 깔끔하게 설명 할 수 있으면 좋겠습니다. 바람직하게는 선택적인 방향 가시성 제약이 유일한 소란입니다. _MySystem.Infrastructure_에서 _MySystem.ClientApplication_을 참조하는 것은 불가능하지만 그 반대의 경우에는 괜찮습니다. 그런 다음 우리는 흥미로운 곳으로 가기 시작합니다.

@ Elephant-Vessel을 명확히 해주셔서 감사합니다. 나는 이것이 매우 가치 있고 클래스 유형이 여기서 올바른 접근 방식이 아니라는 데 동의합니다. 네임 스페이스는 라이브러리 수준에서 개념적으로 단일 항목을 나타 내기 때문에 인스턴스화에 대해 이야기 할 때 머리를 찔렀다 고 생각합니다. 이것이 강제 될 수는 없지만 여러 인스턴스화를 _imply_하지 않는 무언가를 갖는 것이 개념적으로 유용 할 것입니다.

@ Elephant-Vessel에 동의합니다. 모든 제약이 단일 클래스 구조로 표현되는 다른 Java로 TypeScript를 착각하기 쉽지만 TS는 훨씬 더 광범위한 "Shape"개념을 가지고 있으며 이는 매우 강력하고 의미 적 왜곡을 제거합니다. 안타깝게도 모듈에 제약을 적용 할 수 없기 때문에 개발자는 모듈로 훨씬 더 잘 표현할 수있는 클래스 패턴으로 되돌아 가게됩니다.

예를 들어, 단위 테스트의 경우 특정 실행 컨텍스트에 대한 대체 구현을 제공 할 수 있도록 모듈에 "모양"(즉, 제약 조건)을 표현할 수 있으면 매우 유용합니다. 이제 구조 / 확인 된 방식으로이를 수행하는 유일한 방법은 클래스 기반 DI (La Spring)로 돌아가 모든 것을 클래스로 만드는 것입니다 (따라서 인스턴스화 가능).

어쨌든, 나는 @ Elephant-Vessel을 의역하고 있지만 TS에 대한 하나의 소원이 있다면 이것은 이것 일 것입니다.

이 새에 대한 말은? 이 문제도 있습니다

soooo, uhh, 다음과 같은 간단한 경우가 아닐까요?

export {} as IFooBar;

그 구문에 무슨 문제가 있습니까? 구문이 이미 승인 된 것 같습니다.

export implements IFooBar

어쨌든 그것을 기대

아직 입학 / 착륙 했습니까? 이것은 멋진 기능이 될 것입니다

어떻게 진행할 수 있습니까? 믿을 수 없을 정도로 강력합니다. 도와 드리겠습니다!

이 birb에 어떤 worb? 현재 한 가지 질문은 기본 내보내기에 대한 인터페이스를 어떻게 선언 할 수 있는가입니다. 예를 들면 :

export default {}

내가 할 수 있다고 생각합니다.

const x: MyInterface = {}
export default x;

대부분의 TS 파일에서 작동 할 것입니다. 문제는 JS를 먼저 코딩하고 나중에 TS로 전환 할 계획이라면 잘 작동하지 않는다는 것입니다.

내가 생각하고 있던 또 다른 것은 구현하는 네임 스페이스는 어떻습니까? 다음과 같은 것 :

export namespace Foo implements Bar {

}

Bar는 _abstract_ namespace lol idk가 될 것 같습니다.

이 질문이 너무 많이 떠오르는 것을 보았고 우리 모두가 한 가지를 찾고 있다고 생각합니다.
인터페이스에서 정적 멤버를 지원합니다.
그럴 경우 정적 멤버와 인터페이스가있는 클래스를 사용할 수 있습니다. 여기에서하려는 것과 거의 똑같죠?

어느 쪽이든 인터페이스에 정적 지원을 추가하거나 모듈에 대한 인터페이스 지원을 추가해야합니다.

@shiapetel 아니에요.

우리는 할 수있어:

export default <T>{
  foo: Foo,
  bar: Bar
}

그러나 그것은 우리가 찾고있는 것이 아닙니다. 우리는 구체적으로 다음을 찾고 있습니다.

export const foo : Foo = {};
export const bar : Bar = {};

그러나 현재 모듈이 foo와 bar를 내보내도록 강제하는 메커니즘은 없습니다. 사실 모듈이 올바른 기본값을 내보내도록 강제하는 메커니즘도 없습니다.

인터페이스가 정적 멤버를 지원하는 경우 다음에서 상속 된 정적 foo / bar가있는 클래스를 사용할 수 있습니다.
인터페이스 ILoveFooBar {
정적 foo : FooType;
정적 막대 : BarType;
}

권리?
그게 제가 의미하는 바입니다. 당신의 상황에 도움이 될 것 같습니다. 제게 확실히 도움이 될 것입니다.

@shaipetel 인터페이스의 정적 멤버는 확실히 유용 할 수 있지만이 사용 사례에는 적합하지 않을 수 있습니다.

이 문제는 누군가가 구현할 때까지 기다리고 있습니까?

한 가지 사용 사례는 애플리케이션 시작시 모듈에 대한 디렉토리를 스캔하는 프레임 워크 및 도구로, 해당 모듈이 모두 특정 형태를 내보낼 것으로 예상합니다.

예를 들어 Next.js는 페이지 모듈에 대해 ./pages/**/*.{ts,tsx} 을 스캔하여 파일 이름을 기반으로 경로를 생성합니다. 각 모듈이 올바른 항목을 내보내는 지 확인하는 것은 사용자의 몫입니다 (기본 내보내기로 NextPage 및 config 라는 선택적 PageConfig 내보내기).

import { NextPage, PageConfig } from 'next'

interface Props { userAgent?: string }

const Home: NextPage<Props> = ({ userAgent }) => (<main>...</main>)

Page.getInitialProps = async ({ req }) => {
  const userAgent = req ? req.headers['user-agent'] : navigator.userAgent
  return { userAgent }
}

export default Page

export const config: PageConfig = {
  api: { bodyParser: false }
}

대신 implements NextPageModule<Props> 와 같이 전체 모듈의 내보내기 형태를 상단 근처에 한 줄로 선언 할 수 있다면 좋을 것입니다.

또 다른 생각 : TypeScript 구성에 특정 패턴과 일치하는 모든 파일 (예 ./pages/**/*.{ts,tsx} )이 특정 내보내기 형태를 구현해야한다는 것을 지정하는 방법이 있다면 흥미로울 것입니다. 따라서 모듈은 내보내기 유형을 가질 수 있습니다. 예를 들어 pages 디렉토리 내에 있기 때문에 순전히 확인되었습니다. 그러나이 접근법에 대한 선례가 있는지 확실하지 않으며 혼란 스러울 수 있습니다.

인터페이스를 구현하는 간단한 모듈이 필요한 경우 Singleton 클래스를 만들고 싶은 유혹을 자주 느낍니다. 이 문제를 해결하는 가장 좋은 방법이 있습니까?

트윗 담아 가기
이 문제를 해결하고 싶습니다. 해결책에 대한 몇 가지 팁이나 둘러 볼 곳을 알려주시겠습니까?

2020 관점에서 이것에 대해 생각 나는 경우 대신 궁금해 export implements Showable 우리 재사용 type 허용 export 식별자로? 오늘날 이것은 잘못된 구문 이므로 다른 사람의 기존 코드베이스를 밟을 가능성이 거의 없습니다.

그런 다음 가져 오기 구문을 얻습니다.

// Can re-use the import syntax
type export = import("webpack").Config

선언은 작성하기 쉽습니다.

// Can use normal literals
type export = { test: () => string, description: string }

// Generics are easy
type export = (props: any) => React.SFC<MyCustomModule>

JSDoc 등가물도 다음과 같이 생각할 가치가 있습니다.

/** <strong i="17">@typedef</strong> {import ("webpack").Config} export */

^에 몇 가지 메모가 있습니다. 회의에서 나온 한 가지 흥미로운 점은 유스 케이스가 아닌 유스 케이스 인 좀 더 일반적인 도구를 만들 수 있다는 아이디어였습니다.

예를 들어 유형 호환성을위한 유형 어설 션 연산자가있는 경우 모듈 내보내기에 사용할 수 있으며 일반적으로 유형이 원하는 방식과 일치하는지 확인하는 데 사용할 수 있습니다. 예를 들면 :

type assert is import("webpack").Config

const path = require('path');

export default {
  entry: './src/index.js',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'bundle.js'
  }
};

목표가 없다는 것은 최상위 범위에 적용하는 것을 의미합니다. 상황에 맞는 타이핑을 제공하는 데 사용할 수 있습니다 (예 : export default { en| 에서 자동 완성 됨).

그러나 자신의 유형을 검증하는데도 유용 할 수 있습니다.

import {someFunction} from "./example"

type assert ReturnType<typeof someFunction> is string

JSDoc 등가물도 다음과 같이 생각할 가치가 있습니다.
js /** <strong i="7">@typedef</strong> {import ("webpack").Config} export */

@module 이 JSDoc에 해당한다고 생각합니다. 파일 상단에는 다음이 있어야합니다.
js /** <strong i="12">@module</strong> {import("webpack").Config} moduleName */

참조 : https://jsdoc.app/tags-module.html

Storybook v6은 Component Story Format 이라고하는 구조화 된 모듈을 기반으로하는 접근 방식으로 변경되었습니다. 코드베이스의 모든 .stories.js/ts 모듈에는 Meta 유형의 기본 내보내기가 포함되어야합니다.

기본 내보내기를 입력하는 기존의 결함 과 결합하여 이러한 기대를 글로벌 방식으로 표현할 방법이 없기 때문에 Storybook v6를 TypeScript와 함께 사용하는 것이 가능한 것보다 훨씬 덜 부드러운 경험이됩니다.

수출, @jonrimmer의 포인트에 추가 할 수있는 default 이며 그 어떤 type 복제하는 module 나무 - 진탕 문제가 발생할 것입니다.

Webpack에는 import * as Foo 흔들리는 문제 트리가 없습니다. 그러나 모든 정적 멤버에 대해 export default const = {} 또는 export default class ModuleName { 로 동일한 작업을 수행하려고하면 사용하지 않는 가져 오기가 제거되지 않습니다.