問題タブ [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.

0 投票する
1 に答える
2366 参照

javascript - JSDoc のサイドバーにネストされたメソッド

ここにある答えに感謝します:

https://stackoverflow.com/a/19336366/592495

私の JavaScript ドキュメントはよく整理され、適切にフォーマットされています。各名前空間は、含まれるメソッドの「親」です。ただし、ナビゲーションは私が望むほど細かくはありません。

簡単なコマンド ( ) で node.js ツールを使用してコンパイル/レンダリングした後jsdoc file1.js file2.js、ドキュメントはデフォルトのテンプレートに生成されます。このデフォルト テンプレートでは、サイドバー ナビゲーションに自分の名前空間が表示されますが、それぞれに含まれるメソッドは表示されません。

@class各メソッドにディレクティブを追加することで、メソッドのリストを偽装できますが、ご存知のように、それらは実際にはクラスではありません。

次のようなサイドバー ナビゲーションが見たいです。

私が見落としたドキュメンテーションへの指示は、非常に高く評価されます。


[編集して追加:]

実験で@classは、私が望むことをほぼ正確に行いますが、いくつかの例外があります:

  • 名前空間の上にクラスをリストします。名前空間はいわば「親」であるため、私はそれが好きではありません。

  • JavaScript にはその意味でのクラスはありません。その命名法で「クラス」と呼ばれるものではありません。ドキュメントを読んで「クラス」のリストを表示すると、奇妙な切断が発生します。

  • 「新しい」演算子が自動的に追加されます。すべてのメソッドがコンストラクターを持っているわけではありません...問題を確認できます!


[編集: サンプルコード]

というわけで現在の構造です。JSDoc コメントで注釈を付ける前に、基本的なアプローチを次に示します。

したがって、オブジェクト リテラル表記を使用すると、トップ レベルはアプリケーション全体の「名前空間」ですが、その中にはさまざまな目的のサブ名前空間があります。ここには、ユーティリティに固有のサブ名前空間と、レンダリングに固有のサブ名前空間があります。それぞれがプロパティを持つことができますが、さらに重要なことは、それぞれに関数が含まれていることです。サイドバーに表示されるのはこれらの機能です。次に、JSDoc の現在のパターンで具体化します。

0 投票する
0 に答える
69 参照

angularjs - NGDOC - トップダウン階層

NGDOC で文書化されている大規模な AngularJS プロジェクトがあります。多くのフォームがあり、特定のディレクティブは特定のフォームにのみ含めることができます。これは現在、依存関係として文書化されています。各ディレクティブには、コメント内に @require my.directive:myFormContainerBlaBla が含まれています。このディレクティブ用に生成されたドキュメントには、依存関係セクションの myFormContainerBlaBla への適切なリンクが含まれています。

ただし、myFormContainerBlaBla のドキュメントには、その内部で使用できるディレクティブへの参照は含まれていません。文書化されたディレクティブのメニュー リストもフラットです。それを行う方法はありますか:

1) myFormContainerBlaBla のドキュメントには、@require するすべてのディレクティブへのリンクが含まれています。

2) 文書化されたディレクティブのメニュー リストは、階層的に配置されています。

0 投票する
0 に答える
538 参照

javascript - JSDoc - 別ファイルでカスタム型を作成する適切な方法

たとえば、 Rzslider angular repositorycustom-types.js見つけた方法で、という名前の別のファイルでコード補完を行うために、カスタムタイプを作成したいと思います。

これは、独自の型を文書化する適切な方法ですか? JSDocコメントでコードをできるだけ汚染しないように、別のファイルにすることが重要です。JSDoc 3Intellij 14 にバインドされたプラグインを使用しています。ご協力いただきありがとうございます。

0 投票する
1 に答える
505 参照

javascript - IIFE に渡された exports オブジェクトを含む JSDoc CommonJS

更新: @spenibus のおかげで、これは JSDoc 自体の問題である可能性があるという結論に達しました。GitHub のこの未解決の問題に調査結果を追加しました。@spenibus は解決策を見つけましたが、IIFE のわずかに変更されたバージョンが必要です

CommonJS モジュールで IIFE を使用して、CommonJS を操作し、module.exports が存在しない場合はウィンドウ オブジェクトにインターフェイスを割り当てるようにフォールバックできるようにしています。渡された exports オブジェクトが module.exports として扱われるように、これを適切に文書化するにはどうすればよいですか?

0 投票する
3 に答える
16555 参照

node.js - JSDocs: Node.js エクスプレス ルートのドキュメント化

JSDocs で router.get 呼び出しを文書化するのに苦労しています。ルーター呼び出し自体にドキュメントを追加しようとすると、ドキュメントをページに正しく表示できません。

それを解決するために、関数に名前を付けました。

これは機能しますが、最初の方法を機能させる方法を見つけたいと思っています。最初の例を文書化する方法はありますか? 使えそうなキーワード?

0 投票する
2 に答える
309 参照

javascript - プロトタイプ メソッドも持つ Object.create で作成されたオブジェクトをドキュメント化するにはどうすればよいですか

私は、jsdoc3をクロージャー辞書で使用して、jsdocするための最良の方法を見つけようとしています。以下のコードは、私が望むほとんどのものを文書化していますが、@classタグは文書に新しいキーワードを追加し、実際にはクラスではないため、クラス定義を使用することにも不安があります。

@namespace@param元々はより良​​い選択のように見えましたが、疑似コンストラクターでの文書化などは許可されていません。どんな助けでも大歓迎です。