feat: infer types from field initializers #15
Conversation
|
As this is still subject to review, I didn't update the fixtures yet, but I did commit the test output for your perusal |
| @@ -19,8 +19,16 @@ export function createField(node) { | |||
| /** | |||
| * Add TS type | |||
| * @example class Foo { bar: string = ''; } | |||
| */ | |||
| if(node.type) { | |||
| */ | |||
There was a problem hiding this comment.
Lets extract this into a separate handler (see handlers.js) that we can reuse in multiple places, something like handleTypeInference(fieldTemplate, node):
switch(node?.initializer?.kind) {
case ts.SyntaxKind.TrueKeyword:
case ts.SyntaxKind.FalseKeyword:
doc.type = { text: "boolean" }
break;
case ts.SyntaxKind.StringLiteral:
doc.type = { text: "string" }
break;
case ts.SyntaxKind.NumericLiteral:
doc.type = { text: "number" }
break;
case ts.SyntaxKind.NullKeyword:
doc.type = { text: "null" }
break;
case ts.SyntaxKind.ArrayLiteralExpression:
doc.type = { text: "array" }
break;
case ts.SyntaxKind.ObjectLiteralExpression:
doc.type = { text: "object" }
break;
}
| return v === 'true' || v === 'false'; | ||
| } | ||
|
|
||
| export function isAsConst(initializer) { |
There was a problem hiding this comment.
Does TS have other as somethings? I think we may need to think of a more generic approach of handling this, we collect types in a lot of other places as well. I want to avoid handling as const in one place, but not in another place.
Maybe we should separate handling as whatever in a different PR, and focus this PR on inferring types?
There was a problem hiding this comment.
i checked before adding these functions
as const is the type
There was a problem hiding this comment.
oh sorry i misunderstood the question, I read it as "does ts api have other isFoo`
as const is a special case, I'm not aware of any other keyword assertions
|
closed in favor of #53 I added you as co-author to that PR We still need to adress |
See #12