Repository navigation
Combining destructuring with parameter properties #5326
Description
Today, we can take advantage of parameter properties to reduce the boilerplate, e.g:
class Person {
constructor(public firstName: string, public lastName: number, public age: number) {
}
}Since 1.5, we can also use destructuring, e.g:
class Person {
firstName: string;
lastName: string;
age: number;
constructor({ firstName, lastName, age } : { firstName: string, lastName: string, age: number }) {
this.firstName = firstName;
this.lastName = lastName;
this.age = age;
}
}I've tried in many ways to combine both features, but had no success. So:
- Is it possible to combine them nowadays, and if yes, how?
- If not, could it be an improvement to a future TypeScript version? E.g:
class Person {
constructor(public { firstName, lastName, age } : { firstName: string, lastName: string, age: number }) {
}
}
// the code above would possibly transpile to:
var Person = (function () {
function Person(_a) {
var firstName = _a.firstName, lastName = _a.lastName, age = _a.age;
this.firstName = firstName;
this.lastName = lastName;
this.age = age;
}
return Person;
})();
Activity
xLama commentedon Oct 20, 2015
I like this.
DanielRosenwasser commentedon Oct 20, 2015
Vitor Buzinaro (@buzinas) I originally had this working in #1671, but didn't take it in (check out #1541). I think the issue was that it was relatively dense in semantics. I don't necessarily agree, but maybe someone else on the team can weigh in.
danquirk commentedon Oct 20, 2015
Note that in those proposals the parameter property modifier applied to the entire binding pattern (simpler) as opposed to the original suggestion here which in theory supports different visibility modifiers per destructured element (not sure that level of specificity would be worth it).
buzinas commentedon Oct 20, 2015
Dan Quirk (@danquirk) For me, if it's easier for you to do the other way, I don't really care. In fact, that was my first try (e.g
public {firstName, lastName, age}), and as soon as it didn't work, I tried to use on each property, and it didn't work too.It would be great if we could support both (since not always we want to create properties for all the parameters, and when we want, it would be simpler to use
public/privateonly once), but if it's easier to support only one approach, it will be great already.Probably it's something that people will use more and more, since destructuring is awesome.
robianmcd commentedon Nov 26, 2015
just ran into this. I think either approach would satisfy most use cases. Hope to see this in a future version.
laurelnaiad commentedon Dec 23, 2015
The first thing I tried was:
Something like this would be a nice-to-have.
jack-guy commentedon Feb 26, 2016
Definitely +1 this. The alternative tends to be... bulky.
albertywu commentedon Mar 23, 2016
👍
hrundik commentedon Apr 19, 2016
👍
aliatsis commentedon Apr 27, 2016
+1
lekev commentedon May 13, 2016
+1
andriilazebnyi commentedon Jun 13, 2016
+1
yjaaidi commentedon Aug 9, 2016
👍
98 remaining items
awlayton commentedon Apr 15, 2024
Yes that is true Michael Harrington (@kibiz0r). My solution is only helpful for very specific cases. Language support for it would be much better.
kibiz0r commentedon Apr 16, 2024
Worth noting that the
this.propspattern suggested by Rodrigo de Oliveira Gonzalez (@rodrigolive) has suffered some bit rot since they posted it.A class like this will break if you're using the ES2022 syntax for class fields, which is the default for target ES2022 or higher, including ESNext. For this to work, you'd need to set
useDefineForClassFieldstofalsein your tsconfig.HasanMothaffar commentedon Jul 24, 2024
We still want this in 2024
a-tarasyuk commentedon Jul 24, 2024
Hasan Mothaffar (@HasanMothaffar) #44912 (comment)
Akxe commentedon Jul 24, 2024
Oleksandr Tarasiuk (@a-tarasyuk) Where is the discussion happening? I want to follow that thread.
a-tarasyuk commentedon Jul 24, 2024
Adam Eisenreich (@Akxe) you can find the details on why the PR aiming to resolve this issue was closed here #44912 (comment). Alternatively, you can ask Ryan Cavanaugh (@RyanCavanaugh) or Daniel Rosenwasser (@DanielRosenwasser) for more detailed explanations...Akxe commentedon Jul 24, 2024
Oleksandr Tarasiuk (@a-tarasyuk) The comment above is in reaction to your [comment in #44912]. (#44912 (comment)). My question is where the mentioned discussion is happening. This thread is almost dead yet there seems to be a lot of interest for this specific feature in the community. If you think that the other leading members should add to this discussion, please welcome them here, or we could even schedule some kind of "meeting" to discuss this.
sukima commentedon Dec 18, 2024
What are the blockers to this suggestion? How can we get Parameter Properties support with Named Arguments?
k41n commentedon Mar 11, 2025
👍
RoyTinker commentedon Sep 19, 2025
It's strange to look for and find an open issue based on something I'm currently working on, and then see that I voted for it like 8 years ago
Akxe commentedon Sep 19, 2025
The biggest blocker is that this is purely a TS problem. Native JS have no problem with destructuring of this kind since they do not have the public/private/private keywords. That means that there would have to be a proposal backed by someone in the TS inner circle.
My opinion: (Take it as you want, correct me if I am wrong...)
Currently, the TS team does not want to add anything to the TS that will not be added to JS. They do not want to get into the same troubles as they got into with decorators, or import mismatched behaviours. They also do not want to make new keywords to prevent possible collisions with new future JS keywords.
Here is an overview of what was proposed (chronologically):
If I forgot anyone, I am sorry; it is over 100 messages with very similar-looking responses a lot of the time.
ianldgs commentedon Sep 19, 2025
Adam Eisenreich (@Akxe) worth noting that my initial proposal linked has a conflict with existing JS syntax, as pointed out in this comment:
#5326 (comment)
My revised proposal:
#5326 (comment)
This one is also interesting:
#5326 (comment)
Edit: my current workaround:
#5326 (comment)
RyanCavanaugh commentedon Sep 19, 2025
This is basically correct. The odds we'd add destructuring to parameter properties is very, very low at this point. A proposal for something like this really needs to be taken to the TC39 committee in some form or another (not sure how since visibility is not a JS concept, but since parameter properties don't work with
#anyway, you could imagine just forgetting aboutprotected).Akxe commentedon Sep 19, 2025
If public/protected/private properties have not been implemented, would you be in favour of implementing them at all nowadays? If so, I feel like the reason not to extend their functionality is counterintuitive.
Anyhow, given the fact that TC39 will never see private/protected/public, it is an opportunity to add something to the language that will never have the problem of conflicting with TC39's future intentions with JS.
RyanCavanaugh commentedon Sep 22, 2025
The visibility modifiers on property declarations, yes.
Parameter properties, absolutely not.
The relevant idiom here is "if you're in a hole, the first step is to stop digging"