-
-
Notifications
You must be signed in to change notification settings - Fork 132
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
fix(*): expose model util methods, remove redundant type lookup #469
fix(*): expose model util methods, remove redundant type lookup #469
Conversation
Signed-off-by: Simon Stone <[email protected]>
@@ -393,13 +393,7 @@ class ModelFile { | |||
} | |||
} | |||
else { | |||
// check whether type is defined in another file | |||
const fqn = this.resolveImport(type); |
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.
Here, we get the FQN of the type. For import { Thing } from org.example
and import org.example.Thing
this is simple, as all the information to identify that the FQN of Thing
is org.example.Thing
.
For wildcard imports import org.example.*
(which we want to drop), we have to visit the model manager and look through all wildcard imports for the namespace that contains the type we want.
Either way, we end up with the FQN of the type or we throw an error as the type cannot be resolved.
const modelFile = this.getModelManager().getModelFile(ModelUtil.getNamespace(fqn)); | ||
if (!modelFile) { | ||
return null; | ||
} | ||
return modelFile.getLocalType(fqn).getFullyQualifiedName(); |
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.
All of this code is seemingly redundant - we use the FQN that we already have to locate the model file of the type, then we get the type, and then we get the FQN of the type (which we already know!) and return that.
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.
Maybe worth adding the motivation for this actually - yes, it will have a small performance benefit, but it actually enables you to get fully qualified names out of a ModelFile
instance without having to have the imported models present in your ModelManager
now that we have versioned imports and are looking at dropping wildcard imports.
Changes
ModelUtil
methods and correct the TypeScript types forparseNamespace
ModelFile.getFullyQualifiedTypeName
Author Checklist
--signoff
option of git commit.master
fromfork:branchname