Früher habe ich immer meine Objektparameter wie folgt dokumentiert:Dokument destructured Funktionsparameter in JSDoc
/**
* Description of the function
*
* @param {Object} config - The configuration
* @param {String} config.foo
* @param {Boolean} [config.bar] - Optional value
* @return {String}
*/
function doSomething (config = {}) {
const { foo, bar } = config;
console.log(foo, bar);
// do something
}
Aber ich bin nicht sicher, was der beste Ansatz mit desctructured Funktionsparameter ist. Ignoriere ich das Objekt einfach, definiere es irgendwie oder wie dokumentiere ich es am besten?
/**
* Description of the function
*
* @param {String} foo
* @param {Boolean} [bar] - Optional value
* @return {String}
*/
function doSomething ({ foo, bar } = {}) {
console.log(foo, bar);
// do something
}
Ich fühle mich wie mein Ansatz oben macht es nicht offensichtlich, dass die Funktion erwartet eine object
und nicht zwei verschiedene Parameter.
Eine andere Möglichkeit, die ich mir vorstellen könnte, würde @typedef
verwenden, aber das könnte am Ende eine riesige Sauerei sein (besonders in einer größeren Datei mit vielen Methoden)?
/**
* @typedef {Object} doSomethingConfiguration
* @property {String} foo
* @property {Boolean} [bar] - Optional value
*/
/**
* Description of the function
*
* @param {doSomethingConfiguration}
* @return {String}
*/
function doSomething ({ foo, bar } = {}) {
console.log(foo, bar);
// do something
}
denke ich, der erste Ansatz noch in Ordnung ist. Niemand kümmert sich darum, ob das Objekt in Ihrem Code "config" heißt oder überhaupt einen Namen hat. – Bergi
In WebStorm habe ich gefunden, dass, wenn ich nur die Parameter (nach der Destrukturierung) beschreibe und die Destrukturierung ignoriere, es meistens funktioniert, außer für seltenere Fälle. Beschreibe in deinem Beispiel zwei Parameter 'foo' und' bar'. Es ist keine endgültige Lösung, aber jeder Ansatz mit einem Objekt ergab Inspektionsfehler - und Inspektionen und Autovervollständigungen von der IDE ist mir am wichtigsten. –