-
Notifications
You must be signed in to change notification settings - Fork 75
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
support additional properties in RLC #2054
support additional properties in RLC #2054
Conversation
As, the VC interface in the below option1 and option2 has the same effect. interface C {
prop1: string;
prop2: boolean
}
// option 1
interface VC extends Record<string, C[]> {}
// option 2
interface VC {
[prop: string]: C[]
} And we are using type index like option 2 in current HLC. Also,the implementation of Record is actually defined to use type index in a way. type Record<K extends keyof any, T> = {
[P in K]: T;
}; I will use option 2 to express additional properties in the generated code. |
I would prefer we go with option 1, the main reason is documentation as it is more readable and self documenting than the indexer syntax. They are equivalent and shouldn't cause a breaking change if we move to Record |
I have no concern if they can express the same functionality. And no strong preference here, both work for me. |
model VegetableCarrot is Record<Carrots> { | ||
testProp: Carrots | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not sure if it's appropriate to generate Vegetables as
export interface Vegetables {
carrots: Record<string, Carrots>;
beans: Record<string, Beans>;
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@joheredi in the case of is keyword being used in record to express additional properties,
we currently just drop the model VegetableCarrot
generation, use the Record<string, Carrots>
to replace it. which has information loss about VegetableCarrot's own properties. And according to Timothee's comment here Azure/cadl-ranch#330 (comment) we should not treat extends and is as the same thing,
One possible solution here is to use indexer syntax here to express additional properties for is Record scenario. like we should generate model VegetableCarrot as
export interface VegetableCarrot {
[prop: string]: Carrots;
testProp: Carrots;
}
How do you think ? feel free to come up with different solutions here :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should still use Record when setting additional properties
export interface VegetableCarrot {
[prop: string]: Carrots;
testProp: Carrots;
}
is identical to
export interface VegetableCarrot extends Record<string, Carrots> {
testProp: Carrots;
}
But using records is better for documenting. If I understand correctly Timothee's comment is in the context of TypeSpec's is
vs extends
which I think makes sense in that context and will have implications when emitting OpenAPI, but I also think modeling the TypeScript interface extending record is the best way we can represent it for our customers.
When additional properties are not in the picture then if we saw
model Foo is Record<Carrots>;
we should generate
type Foo = Record<string, Carrots>;
and for
model Foo extends Carrots {
foo: string;
}
interface Foo extends Carrots {
foo: string
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's a little strange to handle is
differently based on whether there's extra properties in that model.
Another concern is, this is how we handle is
in normal model context.
model Foo is Carrots {
prop: string;
};
model Carrots {
prop1: numeric;
};
and we will not generate model Carrots, just generate model Foo like
interface Foo {
prop: string;
prop1: number;
}
It's kind of convey an idea to treat is
as spread when it's being used in models.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
approved.
fixes #2033
Also fix the boolean/number/string literal type error in the modular layer.