I’ve discussed why I make this choice several times here. This thread is probably the most comprehensive.
The main point of it is to ensure that storage is ready before you try to read from it. Failure to do this is the iceberg upon which many ships on these forums have sunk, with the final distress call from their doomed captains sounding “everything worked fine on the browser, but when we deployed it to a particular FrobozzCo phone, storage stopped working”. But it also makes your code more efficient and aligns it to a rule of mine that you may not like very much at this point, now that I reread your OP:
I really discourage doing this. See here for a case study on why. The aforementioned rule:
Never use
Storageto communicate within runs of an app. Use it only to talk to the future and listen to the past.
So in my previous post I was assuming that you were using Storage as basically an offline cache.
Storage is a “NoSQL” system, meaning it’s just keys and values. I was trying not to be too disruptive to your existing code, which seemed to me to be storing all media in an array. So I preserved that, with the difference that your getMediaById hits storage every single call, whereas mine defers all storage interaction to the service constructor, so there is only one storage read each app run. After the read from storage has finished, library$.then will trigger immediately, because the Promise has already resolved, so performance will be improved.
I’m not sure where “on the network” comes in, because storage is just grabbing stuff from on-device memory. One option would be to store each media object separately in storage, but unless you have hundreds or maybe even thousands of media (which would probably make other UI aspects of your app more pressing concerns than storage performance) I highly doubt that would be a worthwhile endeavour. Certainly not a road I would travel unless profiling indicated necessity.