Current Behavior
The Angular @T decorator does not function as expected with an instanceConfig parameter because that results in an asynchronous getter. Which is not valid JavaScript.
Expected Behavior
The addInstance call is a Promise.
Promises are not valid inside of getters.
Since the addInstance promise is not awaited, the call to translationService.translate with the instanceConfig.alias is not going to use the instance added since the translate call happens in synchronous code, but the addInstance call is asynchronous.
Additionally the test for this code path is flawed and does not produce an actual test.
Using a setTimeout (asynchronous code) inside a synchronous test does not function correctly. Because the current ng test configuration is setup to run only a single time the setTimeout with 1000 millisecond delay is silently dropped to no effect. You can confirm this by observing that the test execution time of ng test is less than one second execution time:
Chrome Headless 112.0.5615.49 (Mac OS 10.15.7): Executed 57 of 57 SUCCESS (0.185 secs / 0.155 secs)
Steps to Reproduce
Changing the expectation inside the setTimeout to one that should fail does not result in any failures during the test run.
Possible Solution
Require that instances be added before the decorator is used. This is probably difficult to actually achieve in practice.
Possible Implementation
I will be removing the asynchronous parts of this feature in #186 in a future push to this branch.
Current Behavior
The Angular
@Tdecorator does not function as expected with aninstanceConfigparameter because that results in an asynchronous getter. Which is not valid JavaScript.Expected Behavior
The
addInstancecall is a Promise.Promises are not valid inside of getters.
Since the
addInstancepromise is not awaited, the call totranslationService.translatewith theinstanceConfig.aliasis not going to use the instance added since thetranslatecall happens in synchronous code, but theaddInstancecall is asynchronous.Additionally the test for this code path is flawed and does not produce an actual test.
Using a
setTimeout(asynchronous code) inside a synchronous test does not function correctly. Because the currentng testconfiguration is setup to run only a single time the setTimeout with 1000 millisecond delay is silently dropped to no effect. You can confirm this by observing that the test execution time ofng testis less than one second execution time:Steps to Reproduce
Changing the expectation inside the
setTimeoutto one that should fail does not result in any failures during the test run.Possible Solution
Require that instances be added before the decorator is used. This is probably difficult to actually achieve in practice.
Possible Implementation
I will be removing the asynchronous parts of this feature in #186 in a future push to this branch.