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

Allow separate read and write types for index signatures to support Proxies #45887

Closed
5 tasks done
muzam1l opened this issue Sep 15, 2021 · 3 comments
Closed
5 tasks done
Labels
Duplicate An existing issue was already created

Comments

@muzam1l
Copy link

muzam1l commented Sep 15, 2021

Suggestion

Es6 Proxy is one of the most powerful and sweet features of JavaScript, it can particularly give JavaScript programmers ability to have different setter/getter behaviors on index properties. But TypeScript just ruins the experience, despite similar practices found largely in DOM Api's.

If Typescript can't infer Proxy types, at least provide more powerful index signatures typing, allowing getter setter to have different types.

📃 Motivating Example

/*
interface TargetObj<S extends object> {
  [K in keyof S]: Wrapper<S[K]> // wrapper object just stores that value, with type from generic
}
targetObj: TargetObj<skipping S signature> = {
  key1:  new Wrapper(1)
  key2: new Wrapper('string')
}
obj = new Proxy(targetObj , {
  get(target, prop) return  target[prop].value
  set(target, prop, value) {
    obj[prop] = new Wrapper(value)
  }
})
obj.key1 // -> Wrapper { value: 1 }
obj.key1 = 5
obj.key2 = 'another string'
obj.key1 // -> Wrapper { value: 5 }
obj.key2 // -> Wrapper { value: 'another string' }

Now TypeScript wont allow this and I can't even set index signatures with varying signatures of getter and setter.

⭐ Suggestion

Infer Proxy types or at least support different getter/setter for index signatures like this.

interface TargetObj<S extends object> {
  get [K in keyof S]: Wrapper<S[K]> // wrapper object just stores that value
  set [K in keyof S]: S[K]
}

🔍 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 and help provide feedback.

Proxy type inferring, different getter/setter signatures on index properties, etc

✅ Viability Checklist

My suggestion meets these guidelines:

  • This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • This wouldn't change the runtime behavior of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions
  • This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.

💻 Use Cases

Proxy support.

@jcalz
Copy link
Contributor

jcalz commented Sep 15, 2021

Either this is a duplicate of #43662, or #43662 is a prerequisite for this. Also while I understand that you might feel strongly about this topic, the current title doesn't convey much except frustration. Perhaps "allow Proxy objects to have different getter/setter types" would be more informative and less inflammatory?

@andrewbranch andrewbranch changed the title Typescript is useless when using Proxy Allow separate read and write types for index signatures to support Proxies Sep 15, 2021
@andrewbranch andrewbranch added Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript labels Sep 15, 2021
@KaelWD
Copy link

KaelWD commented Oct 1, 2021

Duplicate of #43826

@andrewbranch andrewbranch added Duplicate An existing issue was already created and removed Suggestion An idea for TypeScript Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature labels Oct 4, 2021
@andrewbranch
Copy link
Member

Thank you @KaelWD 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

No branches or pull requests

4 participants