You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Support non-null assertion for destructuring #17390
Currently if we want to retrieve a value nested inside a nullable property using destructuring, we have to split a single destructuring statement into two even if we know that the nullable property would always be non-null in under that branch.
For example:
interfaceFoo{bar?: {bia: number;pia?: number;};}letfoo: Foo= ...;// Currently we have to write something like this:let{bar}=foo;let{bia, pia}=bar!;// But ideally we should be able to write something like:let{bar!: {
bia,
pia,},}=foo;// Or even:let{bar!: {
bia,
pia!,// <--},}=foo;
let{bar: {
bia,
pia =0,}={}asRecord<string,any>// Or Partial<Bar> if we have a Bar type,}=foo;
What's bothering me, is that we have to have an explicit type assertion on the default value in order to being able to destruct it. It would be better if the default-value type would be inferred to be Partial, or other - destructuring supporting - type.
General opinion from the design meeting was that the destructuring syntax is already overly complex and hard to follow, so we'd prefer to not add any new syntax there unless it's absolutely necessary.
Reacted by Théo LUDWIG
Reacted by Matt Maduzia, andreas divaris, Param Singh, Wesley Reitzfeld, Sophie McCarrell, Barrett Harber, Eric Ferreira, Florian Pagnoux, c32hedge, Isaiah Taylor and 35 more
Reacted by Roman Nuritdinov, Scott Rippey, Matt Maduzia, Param Singh, Han Seoul-Oh, Wesley Reitzfeld, Carsten Dietzel, Joel Mun, falsandtru, Michał and 18 more
Hey guys, it's been a few years on this one. I understand the original opinion that the destructuring syntax is complex. However, I believe the syntax is now hardened and solidified such that it's not going anywhere and is best practice. I think TypeScript should affirm that best practice with type checking. As it is, we resort to much more complex patterns due to the lack of this feature.
interfaceOffice{company: {name : string;industry?: string;address?: {street: string;city: string;}}}// How it should befunctiondoOffice(office: Office){const{company: { name, industry,address?: { street, city }}}=office;
...
// explicit null checksif(!street||!city){//do something}}// How it is nowfunctiondoOffice(office: Office){const{company: { name, industry, address }}=office;if(!address){//do something}const{ street, city }=address;}
As objects grow in complexity, this becomes tedious and very hard to read. Thanks for considering TS team!
Reacted by Salim Semaoune, Santi Albo, Nate Moore, timmydoza, Kenneth, Andrew Rempe, Johann Payer, jonathanhamel4, Jacob Ley, nilsdnz and 44 more
also i don't think "becoming too complex" is valid reason not to do it, because that will only mean stagnation of the tool
JS each year becomes "more and more complex", and if you will follow same ideology, then that would mean you will ignore new langauge features
Reacted by Julian Jarecki, dhorkin, Tomer Moran, Bogdan Kostyuk, Philippe Aubertin and Sean Alunni
Please reconsider.
writing something simple and very easily readably as
const { user } = auth
becomes useless, if i have to check it for null, or need an extra line.
imho that defeats the purpose of the most simple use case for destructuring there is.
Reacted by Denys Ivanchuk, akivastr, Seweryn, SparkElf, Salaheldin Akl, Elichai Turkel, Tomer Moran, Bogdan Kostyuk, Elle Mundy, Amrit Kahlon and 9 more
Activity
Shlomibo commentedon Sep 14, 2017
Could be achieved with (or with better typings):
What's bothering me, is that we have to have an explicit type assertion on the default value in order to being able to destruct it. It would be better if the default-value type would be inferred to be Partial, or other - destructuring supporting - type.
RyanCavanaugh commentedon Oct 30, 2017
General opinion from the design meeting was that the destructuring syntax is already overly complex and hard to follow, so we'd prefer to not add any new syntax there unless it's absolutely necessary.
isaiahtaylorhh commentedon Feb 20, 2020
Hey guys, it's been a few years on this one. I understand the original opinion that the destructuring syntax is complex. However, I believe the syntax is now hardened and solidified such that it's not going anywhere and is best practice. I think TypeScript should affirm that best practice with type checking. As it is, we resort to much more complex patterns due to the lack of this feature.
As objects grow in complexity, this becomes tedious and very hard to read. Thanks for considering TS team!
Hulkmaster commentedon Nov 18, 2022
Ryan Cavanaugh (@RyanCavanaugh) sorry for bumping old thread, but i just encountered same situation and i agree with Isaiah Taylor (@isaiahtaylorhh) , and, guessing from all these upvotes, same goes for plenty of people
also i don't think "becoming too complex" is valid reason not to do it, because that will only mean stagnation of the tool
JS each year becomes "more and more complex", and if you will follow same ideology, then that would mean you will ignore new langauge features
IARI commentedon Mar 17, 2023
Please reconsider.
writing something simple and very easily readably as
becomes useless, if i have to check it for null, or need an extra line.
imho that defeats the purpose of the most simple use case for destructuring there is.