Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design Meeting Notes, 8/28/2020 #40309

Closed
DanielRosenwasser opened this issue Aug 28, 2020 · 3 comments
Closed

Design Meeting Notes, 8/28/2020 #40309

DanielRosenwasser opened this issue Aug 28, 2020 · 3 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

Key Mapping in Mapped Types

#12754

  • "Key mapping" is really 3 features:

    • String concatenation types
    • A name clause for keys in mapped types
    • 4 new type operators - haven't done these
  • String concat types

    • Thanks to recursive conditionals, you can now (cleanly) write a Join operator that takes a bunch of literals and separates them by a delimiter.
      • Join<["a", "b", "c"], "," -> "a,b,c"
      • You can write Split using inference; string splitting uses non-greedy matching.
        • Split<"a,b,c", ","> -> ["a", "b", "c"]
  • Name clause for mapped types

    type Foo<T> = { [K in keyof T as `get_${K}` ]: () => T[K] };
    //                            ^^^^^^^^^^^^^
    // Current syntax
    • Naming breaks the special-casing for array-like types where it just maps over the indexes.
    • Interestingly, you can map to more or fewer keys in these clauses!
      • Map to never, and that removes a key
      • Map to multiple keys, and they'll all have the same type.
      • When multiple mapped keys overlap at any point, and they'll be unioned.
        I * Have to make sure that's the behavior (bug in current implementation)
        • This is currently already possible when you have the numeric key 0 and the string key "0".
  • Operators: uppercase, lowercase, capitalize, uncapitalize

    • Locale?
      • Locale-neutral (?)
    • Eventually, people will want to go to/from kebab-case, camelCase, snake_case, etc.
  • Previously had an error on large unions.

    • 100K constituents.
    • Had to enforce the same for string concatentation and spreads.
      • Can't do `${Digit}${Digit}${Digit}${Digit}${Digit}`
  • Can imagine a prefix in these strings the same way find/replace works in editors

    • \u${SomeType}
    • But conflicts with strings
    • We like how we're not conflating the operations with the strings
    • Also, like [[something from C# - @rbuckton fill this in]].
  • How do we feel about as in key mapping?

    • as looks like it is doing something with the constraint of the mapped type (the right side of the in)
    • Most other people on the team seem okay with it.

customDescriptionGenerator

https:/microsoft/vscode-js-debug/blob/a04cff2e4c2b39616d4e1b813f41a40643b9fa76/OPTIONS.md#customdescriptiongenerator-1

@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Aug 28, 2020
@DanielRosenwasser
Copy link
Member Author

#40308 for the PR utilizing customDescriptionGenerator

@bodinsamuel
Copy link

bodinsamuel commented Mar 9, 2021

I saw that there is now helpers for Uppercase, Lowercase, etc...
Is there any push to do this kebab-case, camelCase, snake_case?

This would be handy for Database types

@DanielRosenwasser
Copy link
Member Author

DanielRosenwasser commented Sep 12, 2023

Linking to #40505, #40336.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

2 participants