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
Hi, I like the convenience of destructuring, but I'm confused as to why FindAllRefs (via Shift+F12 in the TypeScript Playground and other editors) doesn't work as I expected it to in this scenario:
class A {
foo: string; // type Shift+F12 inside foo here.
}
class B {
syntax1(a: A): void {
let { foo } = a; // F12 doesn't see this. Why not?
}
syntax2(a: A): void {
let { foo: foo } = a; // F12 sees this.
}
}
My understanding is that the syntax1 destructuring is just sugar for that in syntax2. The reference info is clearly available as shown in syntax2, so the current behavior may be intentional, suggesting that the compiler internally considers foo in syntax1 to just be the local identifier and ignores it.
However, if that's the case, I think there's an argument to be made that the syntax1 foo visually represents both the local identifier as well as the source property to developers. From this perspective, it's a surprising and misleading omission from the references list for the A.foo property.
So is this a bug or intentional? Is there really a good reason not to expose these (implicit-ish?) references to developers? Maybe it involves issues with renaming or similar behavior I haven't considered completely yet? Anyway, destructuring suddenly seems much less useful in light of this issue IMO.
Regards,
Robert
The text was updated successfully, but these errors were encountered:
Thanks for the quick reply, Ryan! That makes sense. Do you think it's close enough that we should close this issue then? Either way, it's nice to know it's not the intentional behavior and is therefore likely to work in the future :)
Hi, I like the convenience of destructuring, but I'm confused as to why FindAllRefs (via Shift+F12 in the TypeScript Playground and other editors) doesn't work as I expected it to in this scenario:
My understanding is that the syntax1 destructuring is just sugar for that in syntax2. The reference info is clearly available as shown in syntax2, so the current behavior may be intentional, suggesting that the compiler internally considers
foo
in syntax1 to just be the local identifier and ignores it.However, if that's the case, I think there's an argument to be made that the syntax1
foo
visually represents both the local identifier as well as the source property to developers. From this perspective, it's a surprising and misleading omission from the references list for theA.foo
property.So is this a bug or intentional? Is there really a good reason not to expose these (implicit-ish?) references to developers? Maybe it involves issues with renaming or similar behavior I haven't considered completely yet? Anyway, destructuring suddenly seems much less useful in light of this issue IMO.
Regards,
Robert
The text was updated successfully, but these errors were encountered: