Easier destructuring with type annotations on binding patterns
<!-- π¨ STOP π¨ π¦π§π’π£ π¨ πΊπ»πΆπ· π¨ Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Please read the FAQ first, especially the "Common Feature Requests" section. --> ## Search Terms <!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily --> type inference destructuring syntax conflict ## Suggestion <!-- A summary of what you'd like to see added or changed --> It's currently not possible to destructure a value in Typescript and provide types for each of the values due to the syntax clash with destructuring and renaming at the same time. You can see exactly this issue in the Typescript FAQs at: https://github.com/Microsoft/TypeScript/wiki/FAQ#why-cant-i-use-x-in-the-destructuring-function-f-x-number------ This is frustrating when programming in React where it's very common to see this pattern: ```typescript const MyComponent = ({ a, b }) => { // ... } ``` But in Typescript a and b are untyped (inferred to have type `any`) and type annotation must be added (either to aid in type safety or to avoid compiler errors, depending on the state of the user's strict flags). To add the correct type annotation it feels natural to write: ```typescript const MyComponent = ({ a : string, b : number }) => { // ... } ``` but that's not what the user thinks due to the aforementioned syntax clash. The only valid syntax in Typescri
Posted by Richiban on Jan 22, 2019, 4:34 PM
Tags
Related issues
- [BUG] Cowork (Windows): all Plan9 shares fail with "Plan9 mount failed: invalid argument" after Windows update KB5124008 (26200.9445) β uninstalling the KB fixe
- Feature Request: Auto-resume CLI session when usage limit resets
- Please deobfuscate the Python
- [Bug] MLX version of Gemma 4 26B fails to load: "Model type gemma4 not supported" (macOS)
- # 233 Developers Discussed Abandoning the Office Add-in Platform β An Open Letter on the Office.js Stability, Security & Trust Crisis
- [FEATURE] Allow users to configure which shell the Bash tool uses or inherit initial shell
Raise real-world problems, find people facing the same issue, and discuss solutions.4,000 issues0 comments
reliability (Software)
[BUG] Cowork (Windows): all Plan9 shares fail with "Plan9 mount failed: invalid argument" after Windows update KB5124008 (26200.9445) β uninstalling the KB fixe
Feature Request: Auto-resume CLI session when usage limit resets
Please deobfuscate the Python
[Bug] MLX version of Gemma 4 26B fails to load: "Model type gemma4 not supported" (macOS)
# 233 Developers Discussed Abandoning the Office Add-in Platform β An Open Letter on the Office.js Stability, Security & Trust Crisis
[FEATURE] Allow users to configure which shell the Bash tool uses or inherit initial shell
Admin Materials and Surfaces
AMD Support
Easier destructuring with type annotations on binding patterns
<!-- π¨ STOP π¨ π¦π§π’π£ π¨ πΊπ»πΆπ· π¨ Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Please read the FAQ first, especially the "Common Feature Requests" section. --> ## Search Terms <!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily --> type inference destructuring syntax conflict ## Suggestion <!-- A summary of what you'd like to see added or changed --> It's currently not possible to destructure a value in Typescript and provide types for each of the values due to the syntax clash with destructuring and renaming at the same time. You can see exactly this issue in the Typescript FAQs at: https://github.com/Microsoft/TypeScript/wiki/FAQ#why-cant-i-use-x-in-the-destructuring-function-f-x-number------ This is frustrating when programming in React where it's very common to see this pattern: ```typescript const MyComponent = ({ a, b }) => { // ... } ``` But in Typescript a and b are untyped (inferred to have type `any`) and type annotation must be added (either to aid in type safety or to avoid compiler errors, depending on the state of the user's strict flags). To add the correct type annotation it feels natural to write: ```typescript const MyComponent = ({ a : string, b : number }) => { // ... } ``` but that's not what the user thinks due to the aforementioned syntax clash. The only valid syntax in Typescri
Comments (0)
No comments yet. Start the discussion.