問題タブ [jsdoc3]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
javascript - JSDoc のサイドバーにネストされたメソッド
ここにある答えに感謝します:
https://stackoverflow.com/a/19336366/592495
私の JavaScript ドキュメントはよく整理され、適切にフォーマットされています。各名前空間は、含まれるメソッドの「親」です。ただし、ナビゲーションは私が望むほど細かくはありません。
簡単なコマンド ( ) で node.js ツールを使用してコンパイル/レンダリングした後jsdoc file1.js file2.js
、ドキュメントはデフォルトのテンプレートに生成されます。このデフォルト テンプレートでは、サイドバー ナビゲーションに自分の名前空間が表示されますが、それぞれに含まれるメソッドは表示されません。
@class
各メソッドにディレクティブを追加することで、メソッドのリストを偽装できますが、ご存知のように、それらは実際にはクラスではありません。
次のようなサイドバー ナビゲーションが見たいです。
私が見落としたドキュメンテーションへの指示は、非常に高く評価されます。
[編集して追加:]
実験で@class
は、私が望むことをほぼ正確に行いますが、いくつかの例外があります:
名前空間の上にクラスをリストします。名前空間はいわば「親」であるため、私はそれが好きではありません。
JavaScript にはその意味でのクラスはありません。その命名法で「クラス」と呼ばれるものではありません。ドキュメントを読んで「クラス」のリストを表示すると、奇妙な切断が発生します。
「新しい」演算子が自動的に追加されます。すべてのメソッドがコンストラクターを持っているわけではありません...問題を確認できます!
[編集: サンプルコード]
というわけで現在の構造です。JSDoc コメントで注釈を付ける前に、基本的なアプローチを次に示します。
したがって、オブジェクト リテラル表記を使用すると、トップ レベルはアプリケーション全体の「名前空間」ですが、その中にはさまざまな目的のサブ名前空間があります。ここには、ユーティリティに固有のサブ名前空間と、レンダリングに固有のサブ名前空間があります。それぞれがプロパティを持つことができますが、さらに重要なことは、それぞれに関数が含まれていることです。サイドバーに表示されるのはこれらの機能です。次に、JSDoc の現在のパターンで具体化します。
angularjs - NGDOC - トップダウン階層
NGDOC で文書化されている大規模な AngularJS プロジェクトがあります。多くのフォームがあり、特定のディレクティブは特定のフォームにのみ含めることができます。これは現在、依存関係として文書化されています。各ディレクティブには、コメント内に @require my.directive:myFormContainerBlaBla が含まれています。このディレクティブ用に生成されたドキュメントには、依存関係セクションの myFormContainerBlaBla への適切なリンクが含まれています。
ただし、myFormContainerBlaBla のドキュメントには、その内部で使用できるディレクティブへの参照は含まれていません。文書化されたディレクティブのメニュー リストもフラットです。それを行う方法はありますか:
1) myFormContainerBlaBla のドキュメントには、@require するすべてのディレクティブへのリンクが含まれています。
2) 文書化されたディレクティブのメニュー リストは、階層的に配置されています。
javascript - JSDoc - 別ファイルでカスタム型を作成する適切な方法
たとえば、 Rzslider angular repositoryでcustom-types.js
見つけた方法で、という名前の別のファイルでコード補完を行うために、カスタムタイプを作成したいと思います。
これは、独自の型を文書化する適切な方法ですか? JSDoc
コメントでコードをできるだけ汚染しないように、別のファイルにすることが重要です。JSDoc 3
Intellij 14 にバインドされたプラグインを使用しています。ご協力いただきありがとうございます。
javascript - IIFE に渡された exports オブジェクトを含む JSDoc CommonJS
更新: @spenibus のおかげで、これは JSDoc 自体の問題である可能性があるという結論に達しました。GitHub のこの未解決の問題に調査結果を追加しました。@spenibus は解決策を見つけましたが、IIFE のわずかに変更されたバージョンが必要です
CommonJS モジュールで IIFE を使用して、CommonJS を操作し、module.exports が存在しない場合はウィンドウ オブジェクトにインターフェイスを割り当てるようにフォールバックできるようにしています。渡された exports オブジェクトが module.exports として扱われるように、これを適切に文書化するにはどうすればよいですか?
node.js - JSDocs: Node.js エクスプレス ルートのドキュメント化
JSDocs で router.get 呼び出しを文書化するのに苦労しています。ルーター呼び出し自体にドキュメントを追加しようとすると、ドキュメントをページに正しく表示できません。
それを解決するために、関数に名前を付けました。
これは機能しますが、最初の方法を機能させる方法を見つけたいと思っています。最初の例を文書化する方法はありますか? 使えそうなキーワード?
javascript - プロトタイプ メソッドも持つ Object.create で作成されたオブジェクトをドキュメント化するにはどうすればよいですか
私は、jsdoc3をクロージャー辞書で使用して、jsdocするための最良の方法を見つけようとしています。以下のコードは、私が望むほとんどのものを文書化していますが、@class
タグは文書に新しいキーワードを追加し、実際にはクラスではないため、クラス定義を使用することにも不安があります。
@namespace
@param
元々はより良い選択のように見えましたが、疑似コンストラクターでの文書化などは許可されていません。どんな助けでも大歓迎です。