fix: createActions should not garble baseclass metadata #1127
Conversation
Essence of this is that the target property of the metadata is not changed in-place.
| @@ -125,7 +131,7 @@ describe('controller inheritance', () => { | |||
| expect(storage.controllers[0].route).to.be.eq('/derivative'); | |||
| expect(storage.controllers[1].target).to.be.eq(AutonomousController); | |||
| expect(storage.controllers[1].route).to.be.eq('/autonomous'); | |||
| expect(storage.actions[0].target).to.be.eq(DerivativeController); | |||
| expect(storage.actions[0].target).to.be.eq(AbstractControllerTemplate); | |||
There was a problem hiding this comment.
Is it intentional that the abstract controller is registered too? Seems like it wasn't the case before
There was a problem hiding this comment.
Indeed it is; the actions in the storage are actually the base data (ActionMetadataArgs) and are shared amongst all deriving classes. If it were altered (as a previous change introduced), only the first derived class 'gets' the actions; the action from the storage is used to create the ActualMetadata in createActions(), and only at that place, the controller.target is filled in as target for the action (which is not the action metadata that is subject of this unit test).
There was a problem hiding this comment.
Sorry, you are right. Seems like we had an incorrect reference mutation, the fix was just obscured a bit by the structure change :).
Thanks for the contribution!
…estack#1127) (#18) Co-authored-by: wamasimba <[email protected]>
|
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Description
A more concise re-implementation of the
createActions()method. Essence of this is that thetargetproperty of the metadata is not changed in-place, which hindered using a base class multiple times.Checklist
Update index.md)develop)npm run prettier:checkpassesnpm run lint:checkpassesFixes
fixes #1124