Document destructured function parameter in JSDoc
Previously I've always documented my object parameters as follows:
/**
* 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
}
But I am unsure what the best approach is with desctructured function parameter. Do I just ignore the object, define it somehow or what is the best way of documenting it?
/**
* Description of the function
*
* @param {String} foo
* @param {Boolean} [bar] - Optional value
* @return {String}
*/
function doSomething ({ foo, bar } = {}) {
console.log(foo, bar);
// do something
}
I feel like my approach above doesn't make it obvious that the function expects an object and not two different parameter.
Another way I could think of would be using @typedef, but that might end up being a huge mess (especially in a larger file with many methods)?
/**
* @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
}
arguments ecmascript-6 jsdoc destructuring
add a comment |
Previously I've always documented my object parameters as follows:
/**
* 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
}
But I am unsure what the best approach is with desctructured function parameter. Do I just ignore the object, define it somehow or what is the best way of documenting it?
/**
* Description of the function
*
* @param {String} foo
* @param {Boolean} [bar] - Optional value
* @return {String}
*/
function doSomething ({ foo, bar } = {}) {
console.log(foo, bar);
// do something
}
I feel like my approach above doesn't make it obvious that the function expects an object and not two different parameter.
Another way I could think of would be using @typedef, but that might end up being a huge mess (especially in a larger file with many methods)?
/**
* @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
}
arguments ecmascript-6 jsdoc destructuring
1
I think the first approach is still fine. Nobody cares whether the object is namedconfigin your code or does have any name at all.
– Bergi
Jun 10 '16 at 13:36
In WebStorm I have found that if I just describe the (after-destructuring) parameters and ignore the destructuring it mostly works except for less-common cases. So in your example, describe two parametersfooandbar. It's not a final solution, but any approach using an object yielded inspection errors - and inspections and autocompletions from the IDE is what I care about most.
– Mörre
Jun 11 '16 at 10:52
add a comment |
Previously I've always documented my object parameters as follows:
/**
* 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
}
But I am unsure what the best approach is with desctructured function parameter. Do I just ignore the object, define it somehow or what is the best way of documenting it?
/**
* Description of the function
*
* @param {String} foo
* @param {Boolean} [bar] - Optional value
* @return {String}
*/
function doSomething ({ foo, bar } = {}) {
console.log(foo, bar);
// do something
}
I feel like my approach above doesn't make it obvious that the function expects an object and not two different parameter.
Another way I could think of would be using @typedef, but that might end up being a huge mess (especially in a larger file with many methods)?
/**
* @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
}
arguments ecmascript-6 jsdoc destructuring
Previously I've always documented my object parameters as follows:
/**
* 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
}
But I am unsure what the best approach is with desctructured function parameter. Do I just ignore the object, define it somehow or what is the best way of documenting it?
/**
* Description of the function
*
* @param {String} foo
* @param {Boolean} [bar] - Optional value
* @return {String}
*/
function doSomething ({ foo, bar } = {}) {
console.log(foo, bar);
// do something
}
I feel like my approach above doesn't make it obvious that the function expects an object and not two different parameter.
Another way I could think of would be using @typedef, but that might end up being a huge mess (especially in a larger file with many methods)?
/**
* @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
}
arguments ecmascript-6 jsdoc destructuring
arguments ecmascript-6 jsdoc destructuring
asked Apr 28 '16 at 13:52
morkromorkro
1,89122133
1,89122133
1
I think the first approach is still fine. Nobody cares whether the object is namedconfigin your code or does have any name at all.
– Bergi
Jun 10 '16 at 13:36
In WebStorm I have found that if I just describe the (after-destructuring) parameters and ignore the destructuring it mostly works except for less-common cases. So in your example, describe two parametersfooandbar. It's not a final solution, but any approach using an object yielded inspection errors - and inspections and autocompletions from the IDE is what I care about most.
– Mörre
Jun 11 '16 at 10:52
add a comment |
1
I think the first approach is still fine. Nobody cares whether the object is namedconfigin your code or does have any name at all.
– Bergi
Jun 10 '16 at 13:36
In WebStorm I have found that if I just describe the (after-destructuring) parameters and ignore the destructuring it mostly works except for less-common cases. So in your example, describe two parametersfooandbar. It's not a final solution, but any approach using an object yielded inspection errors - and inspections and autocompletions from the IDE is what I care about most.
– Mörre
Jun 11 '16 at 10:52
1
1
I think the first approach is still fine. Nobody cares whether the object is named
config in your code or does have any name at all.– Bergi
Jun 10 '16 at 13:36
I think the first approach is still fine. Nobody cares whether the object is named
config in your code or does have any name at all.– Bergi
Jun 10 '16 at 13:36
In WebStorm I have found that if I just describe the (after-destructuring) parameters and ignore the destructuring it mostly works except for less-common cases. So in your example, describe two parameters
foo and bar. It's not a final solution, but any approach using an object yielded inspection errors - and inspections and autocompletions from the IDE is what I care about most.– Mörre
Jun 11 '16 at 10:52
In WebStorm I have found that if I just describe the (after-destructuring) parameters and ignore the destructuring it mostly works except for less-common cases. So in your example, describe two parameters
foo and bar. It's not a final solution, but any approach using an object yielded inspection errors - and inspections and autocompletions from the IDE is what I care about most.– Mörre
Jun 11 '16 at 10:52
add a comment |
2 Answers
2
active
oldest
votes
This is how it's intended, as described in the 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
}
So, your first example is pretty much correct.
Another example with some deeper nesting:
/**
* 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;
I don't see how JSDoc unambiguously works when you have multiple destructured arguments, likefunction ({a}, {a}) {}. The JSDoc I guess would be@param {object} param1, @param {*} param1.a, @param {object} param2, @param {*} param2.a, and rely on ordering of the@paramtags?
– ZachB
Apr 25 '18 at 23:52
@ZachB:function ({a}, {a}) {}is invalid syntax, sinceais defined twice, there.
– Cerbrus
Apr 26 '18 at 5:38
1
Oops.({a: b}, {a}))or({a}, {b})-- point was that JSDoc@paramtags are orderless AFAIK and the keys can be ambiguous were JSDoc to try to match using property names. The next version of VSCode is going to use positional lookup to resolve this scenario.
– ZachB
Apr 26 '18 at 10:23
add a comment |
See JSDoc's "Documenting a parameter's properties":
/**
* 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) {
// ...
};
(Google Closure compiler type checking, that was based on but diverted from JSDoc, also allows @param {{x:number,y:number}} point A "point-shaped" object.)
2
Isn't he already doing that? He is asking what to do now that there is noemployeevariable in the function any more.
– Bergi
Jun 10 '16 at 13:35
7
This doesn't answer the question - this example does not use destructuring! With destructuring you have no parent object.
– Mörre
Jun 11 '16 at 10:50
Actually his same link, right after his example gives a relative example with the same exact jsdoc comments forProject.prototype.assign = function({ name, department }). Prior to the example they say, "If a parameter is destructured without an explicit name, you can give the object an appropriate one and document its properties."
– notacouch
Oct 28 '18 at 20:59
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f36916790%2fdocument-destructured-function-parameter-in-jsdoc%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
This is how it's intended, as described in the 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
}
So, your first example is pretty much correct.
Another example with some deeper nesting:
/**
* 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;
I don't see how JSDoc unambiguously works when you have multiple destructured arguments, likefunction ({a}, {a}) {}. The JSDoc I guess would be@param {object} param1, @param {*} param1.a, @param {object} param2, @param {*} param2.a, and rely on ordering of the@paramtags?
– ZachB
Apr 25 '18 at 23:52
@ZachB:function ({a}, {a}) {}is invalid syntax, sinceais defined twice, there.
– Cerbrus
Apr 26 '18 at 5:38
1
Oops.({a: b}, {a}))or({a}, {b})-- point was that JSDoc@paramtags are orderless AFAIK and the keys can be ambiguous were JSDoc to try to match using property names. The next version of VSCode is going to use positional lookup to resolve this scenario.
– ZachB
Apr 26 '18 at 10:23
add a comment |
This is how it's intended, as described in the 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
}
So, your first example is pretty much correct.
Another example with some deeper nesting:
/**
* 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;
I don't see how JSDoc unambiguously works when you have multiple destructured arguments, likefunction ({a}, {a}) {}. The JSDoc I guess would be@param {object} param1, @param {*} param1.a, @param {object} param2, @param {*} param2.a, and rely on ordering of the@paramtags?
– ZachB
Apr 25 '18 at 23:52
@ZachB:function ({a}, {a}) {}is invalid syntax, sinceais defined twice, there.
– Cerbrus
Apr 26 '18 at 5:38
1
Oops.({a: b}, {a}))or({a}, {b})-- point was that JSDoc@paramtags are orderless AFAIK and the keys can be ambiguous were JSDoc to try to match using property names. The next version of VSCode is going to use positional lookup to resolve this scenario.
– ZachB
Apr 26 '18 at 10:23
add a comment |
This is how it's intended, as described in the 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
}
So, your first example is pretty much correct.
Another example with some deeper nesting:
/**
* 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;
This is how it's intended, as described in the 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
}
So, your first example is pretty much correct.
Another example with some deeper nesting:
/**
* 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;
edited Nov 25 '18 at 0:54
answered Mar 20 '17 at 8:36
CerbrusCerbrus
49.4k1091114
49.4k1091114
I don't see how JSDoc unambiguously works when you have multiple destructured arguments, likefunction ({a}, {a}) {}. The JSDoc I guess would be@param {object} param1, @param {*} param1.a, @param {object} param2, @param {*} param2.a, and rely on ordering of the@paramtags?
– ZachB
Apr 25 '18 at 23:52
@ZachB:function ({a}, {a}) {}is invalid syntax, sinceais defined twice, there.
– Cerbrus
Apr 26 '18 at 5:38
1
Oops.({a: b}, {a}))or({a}, {b})-- point was that JSDoc@paramtags are orderless AFAIK and the keys can be ambiguous were JSDoc to try to match using property names. The next version of VSCode is going to use positional lookup to resolve this scenario.
– ZachB
Apr 26 '18 at 10:23
add a comment |
I don't see how JSDoc unambiguously works when you have multiple destructured arguments, likefunction ({a}, {a}) {}. The JSDoc I guess would be@param {object} param1, @param {*} param1.a, @param {object} param2, @param {*} param2.a, and rely on ordering of the@paramtags?
– ZachB
Apr 25 '18 at 23:52
@ZachB:function ({a}, {a}) {}is invalid syntax, sinceais defined twice, there.
– Cerbrus
Apr 26 '18 at 5:38
1
Oops.({a: b}, {a}))or({a}, {b})-- point was that JSDoc@paramtags are orderless AFAIK and the keys can be ambiguous were JSDoc to try to match using property names. The next version of VSCode is going to use positional lookup to resolve this scenario.
– ZachB
Apr 26 '18 at 10:23
I don't see how JSDoc unambiguously works when you have multiple destructured arguments, like
function ({a}, {a}) {}. The JSDoc I guess would be @param {object} param1, @param {*} param1.a, @param {object} param2, @param {*} param2.a, and rely on ordering of the @param tags?– ZachB
Apr 25 '18 at 23:52
I don't see how JSDoc unambiguously works when you have multiple destructured arguments, like
function ({a}, {a}) {}. The JSDoc I guess would be @param {object} param1, @param {*} param1.a, @param {object} param2, @param {*} param2.a, and rely on ordering of the @param tags?– ZachB
Apr 25 '18 at 23:52
@ZachB:
function ({a}, {a}) {} is invalid syntax, since a is defined twice, there.– Cerbrus
Apr 26 '18 at 5:38
@ZachB:
function ({a}, {a}) {} is invalid syntax, since a is defined twice, there.– Cerbrus
Apr 26 '18 at 5:38
1
1
Oops.
({a: b}, {a})) or ({a}, {b}) -- point was that JSDoc @param tags are orderless AFAIK and the keys can be ambiguous were JSDoc to try to match using property names. The next version of VSCode is going to use positional lookup to resolve this scenario.– ZachB
Apr 26 '18 at 10:23
Oops.
({a: b}, {a})) or ({a}, {b}) -- point was that JSDoc @param tags are orderless AFAIK and the keys can be ambiguous were JSDoc to try to match using property names. The next version of VSCode is going to use positional lookup to resolve this scenario.– ZachB
Apr 26 '18 at 10:23
add a comment |
See JSDoc's "Documenting a parameter's properties":
/**
* 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) {
// ...
};
(Google Closure compiler type checking, that was based on but diverted from JSDoc, also allows @param {{x:number,y:number}} point A "point-shaped" object.)
2
Isn't he already doing that? He is asking what to do now that there is noemployeevariable in the function any more.
– Bergi
Jun 10 '16 at 13:35
7
This doesn't answer the question - this example does not use destructuring! With destructuring you have no parent object.
– Mörre
Jun 11 '16 at 10:50
Actually his same link, right after his example gives a relative example with the same exact jsdoc comments forProject.prototype.assign = function({ name, department }). Prior to the example they say, "If a parameter is destructured without an explicit name, you can give the object an appropriate one and document its properties."
– notacouch
Oct 28 '18 at 20:59
add a comment |
See JSDoc's "Documenting a parameter's properties":
/**
* 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) {
// ...
};
(Google Closure compiler type checking, that was based on but diverted from JSDoc, also allows @param {{x:number,y:number}} point A "point-shaped" object.)
2
Isn't he already doing that? He is asking what to do now that there is noemployeevariable in the function any more.
– Bergi
Jun 10 '16 at 13:35
7
This doesn't answer the question - this example does not use destructuring! With destructuring you have no parent object.
– Mörre
Jun 11 '16 at 10:50
Actually his same link, right after his example gives a relative example with the same exact jsdoc comments forProject.prototype.assign = function({ name, department }). Prior to the example they say, "If a parameter is destructured without an explicit name, you can give the object an appropriate one and document its properties."
– notacouch
Oct 28 '18 at 20:59
add a comment |
See JSDoc's "Documenting a parameter's properties":
/**
* 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) {
// ...
};
(Google Closure compiler type checking, that was based on but diverted from JSDoc, also allows @param {{x:number,y:number}} point A "point-shaped" object.)
See JSDoc's "Documenting a parameter's properties":
/**
* 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) {
// ...
};
(Google Closure compiler type checking, that was based on but diverted from JSDoc, also allows @param {{x:number,y:number}} point A "point-shaped" object.)
edited Jun 10 '16 at 13:10
answered Jun 10 '16 at 13:04
Jakub HolýJakub Holý
3,04911926
3,04911926
2
Isn't he already doing that? He is asking what to do now that there is noemployeevariable in the function any more.
– Bergi
Jun 10 '16 at 13:35
7
This doesn't answer the question - this example does not use destructuring! With destructuring you have no parent object.
– Mörre
Jun 11 '16 at 10:50
Actually his same link, right after his example gives a relative example with the same exact jsdoc comments forProject.prototype.assign = function({ name, department }). Prior to the example they say, "If a parameter is destructured without an explicit name, you can give the object an appropriate one and document its properties."
– notacouch
Oct 28 '18 at 20:59
add a comment |
2
Isn't he already doing that? He is asking what to do now that there is noemployeevariable in the function any more.
– Bergi
Jun 10 '16 at 13:35
7
This doesn't answer the question - this example does not use destructuring! With destructuring you have no parent object.
– Mörre
Jun 11 '16 at 10:50
Actually his same link, right after his example gives a relative example with the same exact jsdoc comments forProject.prototype.assign = function({ name, department }). Prior to the example they say, "If a parameter is destructured without an explicit name, you can give the object an appropriate one and document its properties."
– notacouch
Oct 28 '18 at 20:59
2
2
Isn't he already doing that? He is asking what to do now that there is no
employee variable in the function any more.– Bergi
Jun 10 '16 at 13:35
Isn't he already doing that? He is asking what to do now that there is no
employee variable in the function any more.– Bergi
Jun 10 '16 at 13:35
7
7
This doesn't answer the question - this example does not use destructuring! With destructuring you have no parent object.
– Mörre
Jun 11 '16 at 10:50
This doesn't answer the question - this example does not use destructuring! With destructuring you have no parent object.
– Mörre
Jun 11 '16 at 10:50
Actually his same link, right after his example gives a relative example with the same exact jsdoc comments for
Project.prototype.assign = function({ name, department }). Prior to the example they say, "If a parameter is destructured without an explicit name, you can give the object an appropriate one and document its properties."– notacouch
Oct 28 '18 at 20:59
Actually his same link, right after his example gives a relative example with the same exact jsdoc comments for
Project.prototype.assign = function({ name, department }). Prior to the example they say, "If a parameter is destructured without an explicit name, you can give the object an appropriate one and document its properties."– notacouch
Oct 28 '18 at 20:59
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f36916790%2fdocument-destructured-function-parameter-in-jsdoc%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
I think the first approach is still fine. Nobody cares whether the object is named
configin your code or does have any name at all.– Bergi
Jun 10 '16 at 13:36
In WebStorm I have found that if I just describe the (after-destructuring) parameters and ignore the destructuring it mostly works except for less-common cases. So in your example, describe two parameters
fooandbar. It's not a final solution, but any approach using an object yielded inspection errors - and inspections and autocompletions from the IDE is what I care about most.– Mörre
Jun 11 '16 at 10:52