Auparavant, j'ai toujours documenté mes paramètres d'objet comme suit:
/**
* 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
}
Mais je ne sais pas quelle est la meilleure approche avec le paramètre de fonction déstructuré. Dois-je simplement ignorer l'objet, le définir d'une manière ou d'une autre ou quelle est la meilleure façon de le documenter?
/**
* Description of the function
*
* @param {String} foo
* @param {Boolean} [bar] - Optional value
* @return {String}
*/
function doSomething ({ foo, bar } = {}) {
console.log(foo, bar);
// do something
}
J'ai l'impression que mon approche ci-dessus ne montre pas clairement que la fonction attend un object
paramètre différent et non deux.
Une autre façon de penser serait de l'utiliser @typedef
, mais cela pourrait finir par être un énorme gâchis (en particulier dans un fichier plus volumineux avec de nombreuses méthodes)?
/**
* @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
}
config
dans votre code ou s'il a un nom du tout.foo
etbar
. Ce n'est pas une solution finale, mais toute approche utilisant un objet a généré des erreurs d'inspection - et les inspections et les autocomplétions de l'EDI sont ce qui m'importe le plus.Réponses:
C'est ainsi que cela est prévu, comme décrit dans la documentation .
/** * My cool function. * * @param {Object} obj - An object. * @param {string} obj.prop1 - Property 1. * @param {string} obj.prop2 - Property 2. */ var fn = function ({prop1, prop2}) { // Do something with prop1 and prop2 }
Donc, votre premier exemple est à peu près correct.
Un autre exemple avec une imbrication plus profonde:
/** * Nesting example. * * @param {object} param * @param {number} param.a - First value * @param {object} param.b - Wrapper * @param {number} param.b.c - Second value * @return {number} sum a and b */ letters = ({a, b: {c}}) => a + c;
la source
function ({a}, {a}) {}
. Le JSDoc, je suppose, serait@param {object} param1, @param {*} param1.a, @param {object} param2, @param {*} param2.a
, et s'appuie sur la commande des@param
balises?function ({a}, {a}) {}
est une syntaxe invalide, car ellea
est définie deux fois, là.({a: b}, {a}))
ou({a}, {b})
- le fait est que les@param
balises JSDoc sont AFAIK sans ordre et que les clés peuvent être ambiguës si JSDoc essaie de faire correspondre en utilisant des noms de propriétés. La prochaine version de VSCode va utiliser la recherche positionnelle pour résoudre ce scénario.J'utilise personnellement celui-ci:
/** * @param {{ a: number b: number }} param0 * @returns {number} The sum */ const func = ({ a, b }) => a + b;
Créez simplement l'objet ici.
Je profite également de TypeScript , et déclarerais obtional
b
commeb?
oub: number | undefined
comme JSDoc autorise également les unionsla source
Voir "Documenter les propriétés d'un paramètre" de JSDoc :
/** * Assign the project to an employee. * @param {Object} employee - The employee who is responsible for the project. * @param {string} employee.name - The name of the employee. * @param {string} employee.department - The employee's department. */ Project.prototype.assign = function(employee) { // ... };
( La vérification du type du compilateur Google Closure , qui était basée sur JSDoc mais détournée de JSDoc, permet également
@param {{x:number,y:number}} point A "point-shaped" object.
)la source
employee
variable dans la fonction.Project.prototype.assign = function({ name, department })
. Avant l'exemple, ils disent: "Si un paramètre est déstructuré sans nom explicite, vous pouvez donner à l'objet un nom approprié et documenter ses propriétés."