Nice catch about only assigning to UserOptions_I, that was a typo introduced by my posting, VSCode wonât let me get away with that :).
Sorry to put you thru my naming style, I am aware of the JS/TS conventions but I am stubborn like a goat when it comes to naming anything including other environments like writing dates in the following format YYYYMMDD on checks, tax return, applications :).
I have hard time making sense of things and at least initially, I like to name them what they are and match their case with their types: Storage : Storage (it hasnât bit me too much).
- UserOptions is my object/data
- UserOptions_I is an interface to my object
- UserOptions_P is a promise of my object
I donât like it when I am cornered to name the same thing two different ways just to avoid the naming space. So, I prefer if it is all Preferences, UserSettings or all UserOptions and from there I have:
- UserOptionsPage
- UserOptionsService
- etcâŚ
I dislike very much case-sensitive languages and environments (Unix included), but welcome case aware ones. Case sensitivity made sense like 40 years ago when compilers/computers where slow and memory was scarce. Today, I feel itâs ridiculous and causes more harm than benefits. Thatâs just my opinion.
Ideally, with a case-insensitive language/OS/FileSystem, a language-aware IDE would infer types and could show them as pseudo suffix or prefixes pined or on mouse hover. All based on user settings, the same goes for tabs, indentation and identifier capitalization (source code would be stored in some standard and rendered in IDE) Rendering it in this forum would meet your settings camelCase, PascalCase, etc⌠Of course I will long gone before this happens
Again, thank you for putting up with my convention. Back to our topicâŚ
In order to handle initialization when there is no UsersOptions in the storage I unwrapped your single liner
into the following
which causes the following flow of events, notice how GlobalService promise somehow resolves to undefined before UserOptionsService one
However, when I code/guess it like the following:
Then, the flow of events makes sense and GlobalService accesses a defined copy of the already resolved UserOptions from UserOptionsService
If there is a better way to code it let me know .
Finally, I tested when no data is present in the storage, and the service loads a default object {}. Again things look OK and resolve nicely.
At the moment, it looks like itâs working well and all clients retrieve the promise from the service as a resolved object even if it just initialized to {}.
Earlier, I tried to initialize the service promise member with something like:
UserOptions_P: Promise<UserOptions_I> = new Promise<UserOptions_I>((resolve) => { resolve() });
Without handling in the .then(( but it did not seem to work.
Earlier, due to my lack of knowledge of JS/TS, I was chasing the wrong thought that somehow, the code was failing because the storage had some members of the User Option structure but not others. That was not the case.
I know I have to re-visit Promises in more depth as I only have a shallow understanding.
Thanks again.