Clever Geek Handbook

Reinforced.Typings-詳細

こんにちは。

Reinforced.Typings-C＃アセンブリからTypeScriptグルーコードを生成するためのライブラリ、 以前の投稿で作成した簡単な紹介。 その後、私はすぐに多くの質問やコメントを受け取りました（ところで、Habrahabrだけでなく、興味のある人の多くは単に登録されていませんでした）。 もちろん、すべての人に感謝しますが、分析した情報に基づいて、1つの短い投稿ではどのように、どのように実装されているかを説明するには不十分であることに気付きました。 人々は「これはサポートされていますか？」という質問をします。そして、誰もが同じことを何度も説明しなければなりません。 そのため、この記事では、属性、流configurationsな構成に関する小さな虎の巻を作成し、追加機能について説明します。 一般的に、ようこそ。 注意、ロングライド、バックグラウンド！





前のシリーズ



Reinforced.Typingsについて最初に話したとき、さまざまな属性があり、あらゆる種類のカスタムプロパティがあり、コードジェネレーターがいくつかあり、TypeScriptビルドプロセスに関する何かがあることをさりげなく言及しました。 すべてがなんらかの形で面倒で、詳細はありません。 棚に置いてみましょう。 できる限り簡潔に説明しますが、さまざまな構成オプション、アセンブリスクリプト、すべてがどのように連携するのか、そしてどのように構築できるのかについて詳しく説明します。

一般に、この記事はReinforced.Typingsによる一種のマニュアル/トレーニングマニュアル/チートシートです。英語で完全なドキュメントを作成する時間とリソースがまだないためです。 もちろん、すべてがそんなに悲しいわけではありません-私はすでに勇気を集め、文書化計画全体を書きました。 しかし、より大きな（+ Habrahabrに関する記事）「ロシアの民主主義の父」では十分ではありませんでした。 行きましょう。

PS：私がまだ少し数えて、最後の記事が書かれてから過ぎた時間の間に、いくつかの機能をライブラリに追加し、バグを修正しました（バグなし）。 したがって、提示される資料はバージョン1.0.7から関連しています。



一般的にどのように機能しますか？



リラックスして満足し、 足元が温かく 、TypeScriptを使用してC＃とASP.NET MVCで記述します。 次のコマンドを使用して、Reinforced.TypingsをNuGetからインストールします。 



PM > Install-Package Reinforced.Typings


Reinforced.Typingsは、プロジェクトのすべてのビルドから開始して、アプリケーションのビルドプロセスにすぐに組み込まれます。 この瞬間は、プロジェクトのルートに追加されるReinforced.Typings.settings.xmlファイルから制御されます。これを「ビルド構成」と呼びます。 Reinforced.Typingsは、プロジェクトのアセンブリを読み込み、Reflectionを介してクロールします。 目的のTypeScriptグルーコード（たとえば、サーバーTransferObjectsに対応するTypeScriptインターフェース/クライアントに送信されるViewモデル）は、次の2つの要因に基づいて生成されます。



属性と流れるような構成を組み合わせることができます-これは禁止されていません。 基本的には平等な機会を提供しますが、柔軟性は異なります。

一般に、Reinforced.Typingsを使用するために必要なすべての秘密の知識は、その構成パラメーターをナビゲートすることです。 また、上記の3つの設定ポイントのみがあります-アセンブリ構成（Reinforced.Typings.settings.xml）、属性、および流れるような構成。 アセンブリ構成は、生成されたコードが書き込まれるファイル、ドキュメントをエクスポートするかどうか、接続するアセンブリなど、プロセス全体のグローバルパラメータを決定します。 属性と流fluentな構成により、生成するコードとタイプを決定します。



アセンブリ構成



Reinforced.Typingsは、プロジェクトをリビルドするたびに入力を生成します。 前述のように、プロジェクトのアセンブリプロセスに組み込まれています。 これは、バージョンNuGet 2.5で登場したパッケージから.targetsおよび.propsファイルを埋め込むメカニズムによって行われます 。

ちなみに
ジェネレーター自体は、含まれているRtCli MSBuildタスクを使用して起動されるrtcli.exeツールに移動します。 つまり、すべては、ビルド中にカスタムツールを呼び出すという最高の伝統に基づいています。 原則として、パッケージ自体の/ toolsディレクトリからrtcli.exeとReinforced.Typings.dllを大胆に引き裂いて、希望どおりに使用すること（および/build/Reinforced.Typings.Integrate.dllにあるRtCliタスク）を妨げるものは何もありません、しかし客観的にしましょう-実際にそれを行う人はほとんどいません



ジェネレーター起動の一部のパラメーターは、R​​einforced.Typings.settings.xmlファイルで作成されます。このファイルは、パッケージ自体の.targetsファイルに接続されているMSBuildスクリプトの一部です。 パッケージをインストールすると、Reinforced.Typings.settings.xmlがプロジェクトのルートに追加されます。 デフォルトでは、次のようになります 。 私はそれがうまく文書化されていると主張するつもりはありません（主に英語が壊れているため）、構成パラメータの説明を含むチートシートを用意します：

Reinforced.Typings.settings.xmlのパラメーター
RtTargetFile（文字列）

生成されたすべてのチップが書き​​込まれるファイルへのフルパス。 その中で（他のすべてのパラメーターと同様に）、Microsoft.Common.CurrentVersion.targetsに固有の変数を含むMSBuild変数を使用できます。 このパラメーターはキーであり、プロジェクトのチップを1つのファイルにドロップするだけの場合に必要ですが、生成されたコードを多数のファイルに分割する機能が有効になっている場合は使用されません（以下を参照）。 このファイルを手動でプロジェクトに追加することを忘れないでください！



RtConfigurationMethod（文字列）

Fluent構成を構築するために呼び出されるメソッドの完全修飾名を指定します。 たとえば、My.Assembly.Configuration.ConfigureTypings。 アセンブリを指定する必要はありません-Reinforced。Typingsは、プロジェクト自体のアセンブリまたはその参照でこのメソッドを見つけます。 メソッドは静的で、Reinforce.Typings.Fluent.ConfigurationBuilderタイプの単一のパラメーターを入力として受け入れる必要があります（パラメーター名は重要ではありません）。 流れるような設定を使用している場合でも、属性を使用する能力があることに注意してください。 ただし、同じメンバーに流で属性の構成がある場合は、流beが優先されることに注意してください。



RtWriteWarningComment（true / false）

ファイルが自動的に生成されるという警告の出力ファイルへの書き込みを制御します。 このパラメーターがtrueに設定されている場合、キャプション「//このコードはReinforced.Typingsツールによって生成されました。」何とか何とかが生成された各ファイルのヘッダーで誇示されます。 正直に言うと、このパラメーターが誰に役立つかはわかりませんが、そうです。



RtExportPureTypings（true / false）

RTに、通常のTypeScriptの代わりにTypeScriptタイプのティッピング（.d.ts）を生成させます。 この構成パラメーターを有効にすると、ライブラリーはその名前を正当化します（ただし、デフォルトでは無効になっています）。 そして、問題は.d.tsと.tsの構文がわずかに異なることです。 したがって、このパラメーターの存在の必要性。



RtDivideTypesAmongFiles（true / false）

このパラメーターがfalseの場合、生成されたすべてのチップは、RtTargetFileパラメーターで指定された単一のファイルに書き込まれます。 これは、たとえばSCMを使用しているときに巨大なマージを引き起こす可能性があるため、必ずしも便利ではありません。 このパラメーターをtrueに設定すると、生成されたTypeScriptは異なるファイル（クラスごとのファイル）に分散されます。 この場合、RtTargetFileは無視されます。 生成されたファイルは、表示されるときに手でプロジェクトに追加することを忘れないでください！

[TsFile] / fluent .ExportTo属性を使用して、何をどこに配置するかを構成できます。 RT自体が、この場合に使用される近隣の型への/// <reference ...>ディレクティブの追加を完全に理解することは注目に値します。 しかし、困難な場合には、属性[TsAddTypeReference] / fluent-callでいつでも彼を助けることができます。



RtTargetDirectory（文字列）

RtDivideTypesAmongFilesと組み合わせて使用​​して、生成されたすべてのファイルがダンプされるディレクトリを指定します。 RtDivideTypesAmongFilesを使用している場合は、必ずこのパラメーターを指定してください。



RtRootNamespace（文字列）

RtDivideTypesAmongFilesと組み合わせて使用​​することもできます。 実際のところ、Reflectionではアセンブリのルート名前空間を特定することはできません。 これがないと、生成されたファイルをディレクトリに分散させることはできません。



RtBypassTypeScriptCompilation（true / false）

TypeScriptは、プロジェクトをビルドするときに最初にビルドされます。 チップを生成する状況が発生し、プロジェクトのTypeScriptコードが比較できないものになることがあります。 これを修正するには、プロジェクトをリビルドしてタイピングを再生成する必要がありますが、タイムスクリプトが実行されないためプロジェクトが実行されないため、これを行うことはできません。 この悪循環を終了するには、RtBypassTypeScriptCompilationをtrueに設定します。 この設定は、プロジェクトをビルドする前にタイムスクリプトのアセンブリを無効にし、プロジェクトのビルド後にそれらを収集します。これにより、プロジェクトの.dllファイルが落ち着いてコンパイルされ、RT-それから新しいタイピングが生成されます。 問題が解決したら、このパラメーターをfalseに戻すことを忘れないでください。 そうしないと、収集されたJavaScriptの公開に問題がある可能性があります。



RtCamelCaseForMethods（true / false） （機能リクエストTremorを実装）

（従来の.NET PascalCaseの代わりに）すべてのメソッドの名前を強制的にcamelCaseに変換します。 javascriptの美学で使用されます。 また、CamelCase-ingは、TsFunction属性のShouldBeCamelCasedプロパティを使用して、メソッドごとに個別に制御できます。



RtCamelCaseForProperties（true / false） （機能リクエストTremorを実装）

RtCamelCaseForMethodsと同じ、プロパティのみ。 ShouldBeCamelCasedにはTsPropertyもあります。



RtGenerateDocumentation（true / false）

trueに設定すると、プロジェクトの設定でXMLでのドキュメント生成が有効になり、Reinforced.Typingsはビルドプロセス中にXMLDOCファイルへのパスを抽出し、生成されたファイルに追加するjsdocに変換します。 デフォルトでは、XMLドキュメントがエクスポートプロジェクトに含まれた後、コンパイラはドキュメント化されていないパブリッククラス/クラスメンバーで攻撃を開始します。 それが何らかの形で技術的に干渉したわけではなく、視覚的に腹を立てた。



Rtdisable（true / false）

Reinforced.Typingsを無効にします。 このパラメーターはtrueですが、チップを生成するプロシージャは呼び出されません。 ただし、RtBypassTypeScriptCompilationは引き続きアクティブです。



アイテムグループRtAdditionalAssembly

このアイテムグループに追加のアセンブリをドロップして、Reinforced.Typingsがエクスポート時に考慮する必要があります（読み取り：それらからもタイピンをエクスポートします）。 RTにはプロジェクトの参照へのフルパスがあるため、RtAdditionalAssemblyにはアセンブリの名前（.dllの前にあるもの）を含めることができます。





属性



エクスポートを成功させるには、1つのアセンブリ構成では不十分です。 また、生成されたTypeScriptファイルで見たいものを正確にRTに伝える必要があります。 これは、たとえば、エクスポートされた型（クラス、インターフェイス、列挙）およびそれらのメンバーに適切な属性を掛けることによって実行できます。 これを「属性構成」と呼びます。 流な構成もありますが、属性構成に完全に基づいており、さまざまな方法で繰り返すため、少し後で説明します。したがって、最初に属性構成について説明する方が教育的です。

奇妙なことに、すべてのReinforced.Typings属性はReinforced.Typings.Attributes名前空間にあり、新人（皮肉）を混乱させる可能性があります。 すべての属性を継承できます。 すべてのプロパティがオーバーロードされています。 利用可能な作業テクニックの1つとして、それらのいずれかから継承し、毎回パラメーターのパックをドラッグしないように属性を作成できます。

以下に、利用可能なすべての属性のチートシートを示します。 「必須属性」という表現は、この属性を設定しないと、対応するエンティティがTypeScriptにエクスポートされないことを意味します。



属性名 必要ですか？ 転倒の結果 エクスポート可能（患者）
TsInterface はい TypeScriptインターフェース クラス、インターフェース、構造
TsClass はい TypeScriptクラス クラス構造
TsProperty いや インターフェイス/クラスフィールド プロパティ、フィールド（クラス/構造）
機能 いや インターフェース/クラスメソッド（クラスの場合-本文はnullを返すようにエクスポートされます。メソッドがvoidではなく、voidの場合は空の場合） プロパティ、フィールド（クラス/構造）
TsEnum はい TypeScript列挙 明らかに列挙
TsValue いや TypeScript列挙の値の1つ enumの値は明らかではありません
TsParameter いや TypeScriptメソッドのパラメーター（仮引数） メソッドパラメータ、奇妙なことに
TsGeneric いや TypeScriptメソッド/クラス/何でもの型パラメーター パラメータタイプ
TsIgnore いや 患者はTypeScriptにエクスポートされません プロパティ、コンストラクター（！）、フィールド、メソッド、パラメーター


コンストラクターのエクスポートについて少し
TsBaseParam属性についても言及したいと思います。 RTは、クラスとそのコンストラクターをエクスポートできます。 相互にクラスを継承し、継承者のコンストラクターで先祖のコンストラクターを明示的に呼び出す場合：base（）-これに関する情報はReflectionから取得できません。 したがって、このような場合を正しくエクスポートするには、コンストラクターにTsBaseParam属性を配置できます。 コンストラクタが1つあり、TypeScript式を記述できる文字列の入力配列を受け取ります。 これはすべてTypeScriptスーパー（...）に書き込まれます。 実際には、私はこの属性の有用性についてほとんど考えていませんが、そうです。 この属性は、Reinforced.Typingsがいかにクールであるかを示すためにのみ存在すると考えられています。



それ以外の場合、[TsClass]属性の対応するプロパティによってコンストラクターのエクスポートを有効にすると、コンストラクターは正しくエクスポートされます。 つまり、デザイナーに特別な属性は提供されません。





属性のプロパティ



たくさんのプロパティがあるので、記事を詰まらせないように、リストをネタバレに変えました。 そこで、プロパティのリストで、プロパティの名前を括弧で囲んでプロパティのデフォルト値を示し、それが制御するものを説明します。 これは、XMLDOCで複製された英語のみの大部分の参照情報用です。 これによると-慎重に開きます。



フットクロステキスト
TsInterface


  • AutoI（true） -患者の名前の前に文字Iを自動的に配置するかどうか（そうでない場合）
  • AutoExportMethods（true） -すべての患者メソッドを自動的にエクスポートするかどうか。 そうでない場合は、自分でメソッドに[TsFunction]を追加します
  • AutoExportProperties（true） -上記と同じですが、プロパティおよび[TsProperty]
  • IncludeNamespace（true） -エクスポート時に患者をモジュールに入れるかどうか
  • 名前（null） -患者の名前を上書きします
  • 名前空間（null） -患者の名前空間を上書きします


TsClass


  • AutoExportProperties 、 AutoExportMethods 、 IncludeNamespace 、 Name 、 Namespace -TsInterfaceプロパティに似ています。 プラス：
  • AutoExportFields（true） -AutoExportPropertiesと同じですが、フィールド用
  • DefaultMethodCodeGenerator（null） -クラスのエクスポートされたすべてのメソッドのコードジェネレーターを一度にオーバーライドできます。


TsProperty


  • タイプ（null、タイプ名が置換されます） -TypeScriptの患者タイプの名前を上書きします。 文字列のように。 まあ、つまり、何でも書くことができます。 プロパティのタイプがTSに表示されていない場合（ある場合）、またはエクスポートされていないタイプへの参照を作成する必要がある場合に役立ちます。 例-jQueryで
  • StrongType（null、タイプ名は置換）はTypeと同じですが、.NETタイプを指定できます。 たとえば、デリゲートに便利です-StrongType = typeof（Func <int、bool>）と順序を書いたので、たくさんの括弧で入浴する必要はありません
  • 名前（null） -患者の名前を上書きします
  • ForceNullable（false） -フィールドを強制的にnull可能にするように指示します。 さて、つまり、field：booleanをfield ?: Booleanにする
  • ShouldBeCamelCased（false） -プロパティ名をcamelCaseに変換するかどうか（ Tremor機能要求が実装されます）


機能


  • Type 、 StrongType -TsPropertyプロパティに似ていますが、メソッドの戻り値の型をオーバーライドします
  • 名前（null） -患者の名前を上書きします
  • ShouldBeCamelCased（false） -メソッド名をcamelCaseに変換するかどうか（機能要求Tremorを実装）


TsEnum


  • IncludeNamespace 、 Name 、 Namespace -TsInterfaceプロパティに似ています。 これ以上パラメータはありません。


TsValue


  • 名前 -患者の名前を上書きします（enumの特定の値、つまり）


TsParameter


  • Type 、 StrongType -TsPropertyプロパティに似ていますが、メソッド引数のタイプをオーバーライドします
  • 名前（null） -患者の名前を上書きします
  • DefaultValue（null） -デフォルト値を示します。 パラメーターとして置換する場合：たとえば、boolean = false 。 注意、あなたは自分の足で撃つことができます。
  • ShouldBeCamelCased（false） -パラメーター名をcamelCaseに変換するかどうか（機能要求Tremorを実装）


TsGeneric


  • Type 、 StrongType -TsPropertyプロパティに似ていますが、パラメータータイプのタイプをオーバーライドします


TsBaseParam


  • 値は、TypeScript式を表す文字列の配列です。 TypeScriptクラスをエクスポートする場合、その内容はsuper（...）の呼び出しを生成するために使用されます


TsAddTypeReference


  • RawPath -/// <reference ...>ディレクティブに書き込まれるファイルへのパス。エクスポートされたタイプのファイルに追加されます。
  • タイプ -タイプ、エクスポートされたタイプのファイルへの/// <reference ...>ディレクティブに追加されるファイルへのパス




属性には小さな継承階層があるため、いくつかのプロパティはいくつかの属性にあり、ほぼ同じことを行います（たとえば、名前は、エクスポートされたクラス/インターフェイスの名前をオーバーライドしますが、メソッドまたはプロパティパラメータでも機能します）。



TypeScriptコードを複数のファイルにエクスポートする



この機能は、ビルド構成でRtDivideTypesAmongFilesがtrueに設定されている場合に有効になります。 デフォルトでは、追加の設定なしで、RTはOO言語の古き良き伝統に従ってすべてのクラスを分散します-別のファイルにクラス化し、名前空間に従ってサブディレクトリに入れさえします（この点で不要なディレクトリを損なわないために、使用することをお勧めしますアセンブリ構成パラメーターRtRootNamespace）。 また、微妙な違いが1つあります。スタジオは、.tsファイルで使用されているタイプが隣接するファイルにあるとは限らず、下線が無駄になるとは限りません。 この状況が発生しないようにするには、すべての.tsファイルに/// <reference path = "...">ディレクティブを追加します。 そのため、ほとんどの場合、RTは、プロパティ/フィールドタイプ、メソッドの戻り値、パラメータタイプなどを調べることにより、タイプの依存関係を検査することで、このディレクティブを正しく配置します。 残りについては、 MasterCard属性TsAddTypeReferenceがあります。 以下のネタバレでは、TypeScriptコードのさまざまなファイルへの分散に影響するその他の属性と同様に、それについて説明します。



別のテキスト
  • TsAddTypeReference-この属性を使用すると、患者用に生成されたコードが記述されるファイルに/// <reference ...>ディレクティブを追加できます。 これは、たとえば、エクスポートされたメンバーの文字列でTypeを再定義し、Reflectionを介した参照を検査できない場合に必要です。 この属性のコンストラクターパラメーターとして型を指定できます（たとえば、[TsAddTypeReference（typeof（AnotherExportedType））]）。 次に、RT自体がどのファイルにあるかを判断し、ディレクティブに対応するパスを生成します。 明示的なパスが指定されている場合（たとえば、[TsAddTypeReference（ "../../ jquery.d.ts"）]）、ディレクティブの追加に使用されます。 この属性は、クラス、インターフェース、および列挙にハングアップします。 数回使用できます。
  • TsFile-患者用に生成されたコードを配置するファイルを示します。 この属性は、アセンブリ構成のRtDivideTypesAmongFilesがtrueに設定されている場合にのみアクティブになります。 この属性のパスは、RtTargetDirectoryからの相対パスです
  • TsReference-参照の処理について話し始めたので、この属性に言及する必要があります。 これは、生成されたファイル（またはすべてのファイル）の指定されたパスに/// <reference ...>ディレクティブを追加する必要があることを示します。 特定のタイプへの参照なし。 この属性で指定された参照は、生成された各ファイルに追加されます。 jQueryのチップなど、参照を追加するのに便利です。 この属性はアセンブリに掛けられているため、[assembly：TsReference（ "〜/ Scripts / typings / jquery.d.ts"）]と記述する必要があります。 また、複数回使用することもできます。








CodeGenerator



ほとんどすべての属性は、TsAttributeBaseから継承されます。TsAttributeBaseは、TypeのCodeGeneratorTypeという1つのプロパティのみを定義します。 これは何ですか そしてこれは、クラスまたはタイプのメンバーにコードジェネレーターのタイプを指定する機能です。 コードジェネレーターは、R​​einforced.Typings.Generators.ITsCodeGenerator <>インターフェイスをパラメーター化して実装する必要がある特別なクラスです。



ITsCodeGenerator <>は、1つのプロパティ（Settings）のみを定義します。これは、自動プロパティおよび1つのメソッドとして実装するのに十分であり、入力を受け取るGenerate：



RTには、クラス、インターフェイス、列挙、フィールドパラメーター、メソッド、およびプロパティ用の既製のジェネレーターがいくつかあります。これらはすべてReinforced.Typings.Generators名前空間にあり、それらから継承できます。もちろん、ITsCodeGenerator <>インターフェイスを直接実装することで、コードジェネレーターを作成することを妨げるものは何もありません。

コードジェネレーターを作成したら、ジェネレーターからtypeofの対応する属性のCodeGeneratorTypeプロパティを設定して、コードジェネレーターを使用することを指定する必要があります。残念ながら、ここには型安全制御はありません。つまり、CodeGeneratorType = typeof（string）を指定した場合、IntelliSenseは何かが間違っているとは言いません。ただし、Fluent構成（.WithCodeGenerator <>メソッド）でも同じ機能が提供されており、そこで間違ったコードジェネレーターを指定することはできません。



しかし、例えば
..., , Reinforced.Typings.Generators.MethodCodeGenerator, ActionInvokeGenerator, glue-code MVC WebAPI promise. , TypeScript [TsClass(AutoExportMethods = false)], — [TsFunction(CodeGeneratorType = typeof(ActionInvokeGenerator))]. . .





流configurationな設定



エクスポートされた型に属性を配置することは必ずしも便利ではありません。たとえば、特定の名前空間から何百ものタイプをエクスポートする必要がある場合、特定のプロパティをそれらから引き裂き、それらの特定のエクスポート構成を規定する場合、属性の配置は少し退屈で単調になります。また、ソースコードにアクセスできないエンティティにエクスポート属性を配置することはできません。この状況を克服するために、バージョン1.0.5では、流れるような構成の機能が追加されました。次の2つの簡単な手順で、属性とともに使用を開始できます。

  1. 別のクラスを作成し、Reinforced.Typings.Fluent.ConfigurationBuilder型の単一のパラメーターを使用して、そのクラスでパブリック静的メソッドを宣言します。たとえば、次のように： 

     using Reinforced.Typings.Fluent; namespace TestProject.App_Start { public class TypingsConfiguration { public static void ConfigureTypings(ConfigurationBuilder builder) { //    fluent- } } }


  2. ビルド構成で、使用する流れるような方法を指定します。 たとえば、次のように： 

     <RtConfigurationMethod>TestProject.App_Start.TypingsConfiguration.ConfigureTypings</RtConfigurationMethod>




それだけですこれで、このメソッドは、taipingを再生成するたびに呼び出され（プロジェクトの再構築時）、エクスポート構成を準備します。流れるような構成により、同じタイプのインターフェイスとクラスのバンドルを同じタイプの構成でエクスポートするのは非常に簡単です（わずかに異なる形式ではありますが、Tremor機能要求が実装されます）。また、明確なプラスは、私の意見では、強く型付けされたコードジェネレーターの指示です。これにより、プロパティのメソッドにコードジェネレーターを誤って使用することはありません。



あなたの許可があれば、ConfigurationBuilderのすべてのメソッド（およびネストされたすべてのBuilder）を詳細に説明することはしません。これらは直感的にわかりやすく、XMLDOCも優れているからです。以下に、流れるような構成コードのほんの一部を示します。

コードの一部 
 using Reinforced.Typings.Fluent; namespace TestProject.App_Start { public class TypingsConfiguration { public static void ConfigureTypings(ConfigurationBuilder builder) { builder.ExportAsInterface<ILoginInformation>() .WithPublicProperties() .WithProperty(c => c.Email).Type<int>(); builder.ExportAsInterface<ILoginPage>() .WithPublicProperties() .WithPublicMethods() .WithMethod(c => c.FillIn(Ts.Parameter<ILoginInformation>(o => o.Type<string>()))) .Returns<string>(); builder.ExportAsInterface<ILoginPage>() .WithMethod(c => c.AddOrders(Ts.Parameter<OrdersColelction>())); builder.ExportAsInterfaces( new[] { typeof (ILoginPage), typeof (ILoginInformation), typeof(IOrder) }, c => c.ExportTo("login.ts").WithAllMethods(m => m.CamelCase())); } } }




読者はこの構成が何をするのかを簡単に理解できると思います。しかし、私はいくつかの発言に抵抗することはできません。

注釈時間：TsBaseParamとTsGenericは、属性としてのみ利用可能です。これらのポイントを設定するための美しい流approachなアプローチを思い付くことができませんでした。一方、私はこれを流な構成に削除することはやややり過ぎだと考えています。つまり、そのようなボトルネックに属性を使用します。

Ts.ParameterとTryLookupDocumentationForAssemblyメソッドには2つの説明があります。個別の説明が必要です。

Ts.Parameterは、メソッドパラメーターのFluent-Configuration Builderを入力として使用できる特別な静的メソッドです。つまり、メソッドパラメーターの構成を設定する場合は、次のように言うだけです。 

 builder.ExportAsInterface<MyClass>() .WithMethod(m => m.MyMethod( Ts.Parameter<int>(p => p.OverrideName("apple").Type<string>()) )) .Returns<object>();


TypeScriptに入る 

 export IMyClass { MyMethod(apple:string):any; } /*    class MyClass { public int MyMethod(int a) { return 0; } } */


私の意見では、便利でエレガントな方法です。

TryLookupDocumentationForAssemblyは、ConfigurationBuilder自体のメソッドであり、アセンブリ自体の隣にある指定されたアセンブリのxmlドキュメントファイルを検索するようRTに指示します。オーバーロードが1つあり、ファイル名を直接指定することができます（この方法は、検索するディレクトリを決定するためだけにアセンブリが使用されます）。別のアセンブリからドキュメントをエクスポートする必要が生じたときに、このメソッドを追加する必要が生じました。

こっち確かに。



おわりに



記事は非常に大きく、原則として、プロジェクトのドキュメントが完全になく、作成者としての自由な時間がないカテゴリで、多少詳細なマニュアルを作成するという私の目標に対応していました。私はまだ十分な使用例がありませんでしたが、次の記事を彼らに捧げ、githubに例を追加してコミットしようとします。ピアニストを撃たないでください-時間があるときに彼は書きます。

いつものように、提案、提案、その他のフィードバックを受け付けています。使用中にバグを見つけた場合は、プロジェクトのgithubに問題を送信してください。また、予期しないプルリクエストにも非常に満足しています。

プロジェクトのNuGetパッケージは、それがあった場所にあります。


More articles:


All Articles