Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Please see #203 for the overall issue. I'll summarize changes here:
propMetadata
Previously class property metadata was not being inherited by child classes from parents. For example:
If you requested
propMetadata
for class B, you would only getbar
. The first commit of this overlays all parent properties. A simpleObject.assign
should suffice, because we should expect all parent keys to typically be different from the child keys.parameters
Previously class constructor decorators were being initialized with their parent constructor parameters.
Reflect.getMetadata
will return the parent class stored item if the child does not yet exist in the cache. Because of this, the ParamDecorator would get the parent array reference for the first time seeing a child class. It would then manipulate the same reference, and set it back in Reflect with the child's class key.After all decorates were processed, the Reflect cache would end up with the same constructor decorator array reference for a parent and all it's children, albeit it may be stored at different keys (AConstructor, BConstructor, CConstructor, etc...). This means that any class within a hierarchy has ultimately added to an ever growing single set of decorators. A child could end up with 5 or 6 different @Inject tokens on a single parameter.
After thinking about it for a while, I don't think initializing with the parent is correct. The constructor of a child could be expressed in a completely different layout from the parent.
It seems more appropriate to store the class by itself, and if the constructor was empty, it does access it's parents.