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;

アンビエント外部モジュールで許可する必要があります。 これらのモジュールでは、私の意見では2つの構文を許可する必要があります。

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をimplements句のスコープに含める必要がありますか？

型情報をモジュール自体に追加できるので、インポートステートメントに型情報を追加することは私の意見ではあまり役に立ちません。

また、マージされた宣言の場合、implements句を含むモジュールブロックはインターフェイスを実装する必要があります。 これにより、可視性の問題も防止されます。

これは＃2159とどのように関連していますか？ 名前空間はインターフェースを実装しますか？

@jbondcこれがあれば、名前空間にも適用されます。 内部モジュールと名前空間は同形であると考える必要があります。

「名前空間」がインターフェースを実装できる実装パスをたどってよろしいですか？

うわー、これはかなり長い間承認されています。 @ RyanCavanaugh 、 @ DanielRosenwasser 、 @ mhegazyは、考え直したり微調整したりしない限り、おそらくすぐに実装します。

私は以前の懐疑論を撤回し、それがもたらす新しい構造的可能性のために実際に退出しました。

それに沿って、実装を宣言するブロックだけでなく、インターフェースの集合体のインターフェースを強制することを検討してください-名前空間/モジュールの性質は分散され、多くの重要なコンポーネントが含まれます。 これを使用できるようにしたいのですが、名前空間/モジュール全体を同じファイルで定義したくないのは確かです。 その場合、なぜクラスを使用しないのですか？

@ Elephant-Vesselモジュール、名前空間、パッケージ、機能、または...について話しているのかどうかはわかりません。

@aluanhaddadどういう意味ですか？

つまり、このディスカッションが開始された時点では、モジュールは今日の意味を意味していませんでした。 現在、名前空間という用語を使用して、OPでモジュールとして記述されているものを指しますが、モジュールはより正確で互換性のない意味を持っています。 それで、この実装に参加している複数のファイルについて話すとき、名前空間またはモジュールを参照していますか？

名前空間について言及しています。 私はこのスレッドの歴史に準拠したかったのだと思います。緩まないようにして申し訳ありません:)または、考えてみると、頭の中に「モジュール」という一般的な用語があり、セットで構成される高レベルのユニットを表しています。システムに特定の高レベルの機能を提供するために組み立てられたサブコンポーネントの。 しかし、私は「名前空間」を使用するだけで大​​丈夫です。

したがって、typescriptの構造概念の名前空間を利用して、他の[_genericmodules_]またはクラスを含むことができる[_genericmodules_]を記述し、制約と期待を設定できるようにしたいと思い

私の希望は、システムでより高いレベルの構造的期待をより適切に表現できるようになることです。 クラスは拡張性が低く、システムのアトミックコンポーネントとしては問題ありませんが、システム内の高レベルの組織構造は、インスタンス化および継承されるように設計されているため、クラスで表現するのは適切ではないと思います。 。 ふわふわすぎます。

大騒ぎせずに、システムの高次構造を説明するためのシンプルでクリーンな方法をいただければ幸いです。 できれば、オプションの方向性の可視性の制約だけが大騒ぎになります。 _MySystem.Infrastructure_から_MySystem.ClientApplication_を参照できないようにするのと同じですが、その逆は問題ありません。 それから私たちはどこかエキサイティングな場所に行き始めます。

@ Elephant-明確にしてくれてありがとう。 これは非常に価値があり、クラスタイプはここでは適切なアプローチではないことに同意します。 名前空間は、ライブラリレベルで概念的にシングルトンであるものを表すため、インスタンス化について話すときは頭に釘付けになると思います。 これを強制することはできませんが、概念的には、複数のインスタンス化を「暗示」しないものがあると便利です。

@ Elephant-Vesselに同意します。 TypeScriptを別のJavaと間違えやすいのですが、すべての制約が単一のクラス構造で表現されていますが、TSには、非常に強力でセマンティックなゆがみを排除する、はるかに広い「形状」の概念があります。 残念ながら、モジュールに制約を課すことができないと、開発者はモジュールとしてより適切に表現されるもののクラスパターンに戻ることを余儀なくされる傾向があります。

たとえば、単体テストの場合、特定の実行コンテキストに代替実装を提供できるように、モジュールにいくつかの「形状」（つまり制約）を表現できると非常に役立ちます。 さて、構造/チェックされた方法でそれを行う唯一の方法は、クラスベースのDI（la Springなど）に戻り、すべてをクラスにする（したがってインスタンス化できる）ことです。

とにかく、私は@ Elephant-Vesselを言い換えていますが、TSに対する単一の願いがあれば、それはこれになります。

この鳥について何か言葉はありますか？ 私もこの問題を抱えています

すっごく、うーん、それは単純なケースではないでしょうか：

export {} as IFooBar;

その構文の何が問題になっていますか？ 構文はすでに承認されていると思います。

export implements IFooBar

とにかくそれを楽しみにしています

これはもう入学/上陸しましたか？ これはクールな機能になるでしょう

どうすればこれを進めることができますか？ その信じられないほど強力です。 喜んでお手伝いします！

このバーブにヴォルプはありますか？ 今のところ私が持っている質問の1つは、デフォルトのエクスポート用のインターフェイスをどのように宣言できるかということです。 例えば：

export default {}

私はただできると思います：

const x: MyInterface = {}
export default x;

これはほとんどのTSファイルで機能しますが、問題は、最初にJSをコーディングしていて、後でTSに移行することを計画している場合、これはあまりうまく機能しないことです。

私が考えていたもう1つのことは、実装する名前空間についてはどうでしょうか。 何かのようなもの：

export namespace Foo implements Bar {

}

Barは_abstract_名前空間だと思いますlolidk

この質問が何度も出てくるのを見て、私たちは皆、ただ1つのことを探していると思います。
インターフェイスで静的メンバーをサポートします。
その場合は、静的メンバーとインターフェイスを備えたクラスを使用できます。これは、ここで実行しようとしていることとほぼ同じです。

いずれにせよ、インターフェイスに静的サポートを追加するか、モジュールのインターフェイスサポートを追加する必要があります。

@shiapetelいやそうじゃない。

できるよ：

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

しかし、それは私たちが探しているものではありません。 私たちは特に探しています：

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

しかし、現在、モジュールにfooとbarをエクスポートするように強制するメカニズムはありません。 実際、モジュールが正しいデフォルト値をエクスポートするように強制するメカニズムもありません。

インターフェイスが静的メンバーをサポートしている場合は、以下から継承した静的foo / barを持つクラスを使用できます。
インターフェースILoveFooBar {
static foo：FooType;
静的バー：BarType;
}

正しい？
それが私が意味したことです、私はそれがあなたの状況で役立つと思います-私はそれが私の中で間違いなく役立つことを知っています。

インターフェイスの@shaipetel静的メンバーは間違いなく役立つかもしれませんが、おそらくこのユースケースではそうではありません。

この問題は、誰かが実装に取り​​掛かるのを待っているだけですか？

1つのユースケースは、アプリケーションの起動時にディレクトリをスキャンしてモジュールを探し、それらのモジュールすべてが特定の形状をエクスポートすることを期待するフレームワークとツールの場合です。

たとえば、 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>ように、モジュール全体のエクスポート形状を上部近くの1行で宣言できると便利です。

別の考え：TypeScript構成で、特定のパターン（ ./pages/**/*.{ts,tsx} ）に一致するすべてのファイルが特定のエクスポート形状を実装する必要があることを指定する方法があれば興味深いでしょう。たとえば、 pagesディレクトリ内にあるという理由だけでチェックしました。 しかし、このアプローチの前例があるかどうかはわかりません。混乱する可能性があります。

インターフェイスを実装する単純なモジュールだけが必要な場合、シングルトンクラスを作成したくなることがよくあります。 これに対処するための最善のヒントはありますか？

@RyanCavanaugh @DanielRosenwasser
この問題に取り組みたいと思います。 解決策のヒントや見回す場所を教えてください。

2020年の観点から、この考える、私は、ifの代わりに、不思議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 */

^にはいくつかの注意事項があります。会議から出てきた興味深い点の1つは、これが唯一のことではなく、ユースケースであるより一般的なツールを構築できるというアイデアでした。

たとえば、型の互換性のために型アサーション演算子がある場合、それをモジュールのエクスポートの両方に使用でき、一般的に、型が希望どおりに一致することを確認できます。 例えば：

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 ：

Storybook v6は、 Component StoryFormatと呼ばれる構造化モジュールに基づくアプローチに変更されました。 コードベース内のすべての.stories.js/tsモジュールには、タイプMetaデフォルトのエクスポートが含まれていると予想されます。

この期待をグローバルな方法で表現する方法がなく、デフォルトのエクスポートを入力する際の

@jonrimmerのポイントに追加するには、 moduleを複製する特定のtype defaultをエクスポートすると、ツリーの揺れに問題が発生します。

Webpackはimport * as Foo揺さぶる問題はありません。 ただし、すべての静的メンバーを使用してexport default const = {}またはexport default class ModuleName {で同じことを実行しようとしても、未使用のインポートは削除されません。