I would get rid of providedIn: 'root'. It seems like a neat idea at first, but it really limits your flexibility to mock services out for testing and debugging. Then, I would reevaluate what, how, and when you’re storing.
I treat storage like the “hibernation” feature of laptops, where state is saved in preparation for a situation where everything might be lost, and upon resumption we read back our saved state and the rest of the app never knows anything happened. This has a few implications:
- only read from storage at fixed times: at app startup or resumption, or at first request
- no need to ever bother waiting on storage writes
- don’t rely on storage to communicate amongst parts of a running app, just use live copies of data residing in services for this
I prefer Ionic Storage to Capacitor Storage here, because it’s a front for localForage, meaning it degrades gracefully to IndexedDB in browsers, and because it handles typed marshalling and unmarshalling automatically.
The data structure you describe in your question is rather unusual, in that it’s a one-element array. The best fit for NoSQL-type storage engines like the ones we’re working with here is a bunch of relatively small independent objects that can be easily identified by a unique index. The obvious candidate here is name: is that guaranteed to be globally unique?
I vastly prefer having services like this deal strictly in business-layer objects in their public interfaces, and I really dislike the way any is being abused here. So I would instead have a public face that looks like:
interface Destination {
name: string;
country: string;
photos: string[];
}
class DestinationService {
loadDestination(name: string): Promise<Destination> {...}
saveDestinaton(d: Destination): void {...}
}