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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support arbitrary additional fields as map or dictionary type #2928

Open
4 of 7 tasks
Chriscbr opened this issue Jul 26, 2021 · 1 comment
Open
4 of 7 tasks

Support arbitrary additional fields as map or dictionary type #2928

Chriscbr opened this issue Jul 26, 2021 · 1 comment
Assignees
Labels
feature-request A feature should be added or improved. module/jsii Issues affecting the `jsii` module. p1

Comments

@Chriscbr
Copy link
Contributor

馃殌 Feature Request

Affected Languages

  • TypeScript or Javascript
  • Python
  • Java
  • .NET (C#, F#, ...)
  • Go

General Information

  • JSII Version:
  • Platform:
  • I may be able to implement this feature request
  • This feature might incur a breaking change

Description

By default, empty interfaces in TypeScript allow adding any arbitrary properties. In addition, it is possible to allow arbitrary properties in interfaces with existing fields through index signatures:

export interface Foo {
  readonly myRequiredProp: string;
  readonly myOptionalProp?: string;
  readonly [key: string]: any;
}

Currently, neither method of supporting arbitrary fields are transliterated to Python (or other languages AFAIK). So if the interface is empty, than no properties can be added in the constructor (even though it's possible in TypeScript). This limitation came up in cdk8s-team/cdk8s-cli#33.

Proposed Solution

In Python, these interfaces should probably be transliterated into parameters with the **kwargs syntax. For other languages, I'm not sure if there are as clean equivalents. For example in Java, it might be necessary to have some reserved keyword for use in interfaces like extraFields which is simply typed as a mapping from strings to objects.

This obviously presents some questions about runtime and type safety, so if that is an issue, or the feature isn't feasible for other technical reasons, perhaps it's worth adding some kind of optional validation as part of jsii that checks that index signatures are used in publicly exported interfaces? This part I'm not as sure about.


If this feature/issue has already been reported somewhere please let me know!

@Chriscbr Chriscbr added feature-request A feature should be added or improved. needs-triage This issue or PR still needs to be triaged. labels Jul 26, 2021
@NGL321 NGL321 added p1 module/jsii Issues affecting the `jsii` module. and removed needs-triage This issue or PR still needs to be triaged. labels Jun 3, 2022
@henrysachs
Copy link

i'm not sure about this one. Its P1 but for now more than 2 Years. Is there some movement in that area? I tripped about it just today again :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request A feature should be added or improved. module/jsii Issues affecting the `jsii` module. p1
Projects
None yet
Development

No branches or pull requests

4 participants