The reason I made the decorator is because if you want to save more than 1 or 2 values in Storage, you have now polluted every single view - every single provider - with the boilerplate async code and after awhile it gets hard to read.
There’s no avoiding the fact that this process is asynchronous but there is a distinct reason that async/await were invented instead of saying “everyone should use Promises because you don’t want to cover up that it’s async!”
Sync patterns are much easier to reason about, and again, sure 1 or 2 times is fine but once you start doing this 6, 7, 15 times you will want the framework to help you manage it. Thus why I created the decorator. And it doesn’t at all avoid the fact that this is async - it simply allows your view to do 1 thing, and you listen for an event that tells you that the data you need is ready and do something useful with it.
Same code, but compartmentalized so that managing it is easier. In fact this pattern is by far the easiest way out - I no longer pay any attention to this issue in my apps.
In your example you have tightly bound: a) the source of the data, b) the fact that the data is stored async, and c) the navigation model of the view. If any ONE of those changes you now have to update that everywhere in your app. Instead, it is better to reason about the data itself, not how it is stored.