mergesort / Boutique

✨ A magical persistence library (and so much more) for state-driven iOS and Mac apps ✨
https://build.ms/boutique/docs
MIT License
899 stars 43 forks source link

Access to Bodega's createdAt and updatedAt in Boutique #35

Closed garyphilipp closed 1 year ago

garyphilipp commented 1 year ago

Either make storageEngine a non-private property in Store<> or provide access functions in Boutique in access Bodega's StorageEngine's createdAt and updatedAt. Since they are part of the StorageEngine protocol, they are guaranteed to be available. Otherwise, there would be a need to create redundant properties in our own models if we need those dates. Why recreate when they are already available, just locked away? Not urgent, but no reason not to, and it would be helpful since date info is very common to include in data models.

mergesort commented 1 year ago

Thanks for the suggestion @garyphilipp, I really appreciate the thought you put into your answer. My inclination would actually be to do the opposite of what you suggested and remove the createdAt and updatedAt from the StorageEngine protocol, which is why I'd prefer to not bubble them up to Boutique.

A little history: The createdAt and updatedAt requirements were added while Bodega was a standalone framework, solely focused on reading and writing files from disk. They're not even used internally, they're exposed for users if because there was a desire to sort on those fields, which wasn't easily possible because Bodega vends Data rather than a model. Bodega still exists as a standalone framework and these functions can be helpful in that context, but they shouldn't be necessary or won't necessarily even be correct when using Boutique.

For example if you have an app that's backed by a server, and a user were to create an object on January 1st, then download the app on January 2nd, Bodega's createdAt would be incorrect.

Boutique users don't interact with the StorageEngine directly, the StorageEngine is an implementation detail and the models are the source of truth like in the example above. A Boutique user should never have to think in terms of StorageEngines or databases, they aren't exposed to the underlying storage mechanism after initialization. Because those functions are still necessary for Bodega I've chosen to leave them in Bodega, but not expose them to Boutique's Store.

Please let me know if that makes sense, and if perhaps there's a better way to think about this!

garyphilipp commented 1 year ago

Thank you for responding. And yes, all of your points make perfect sense, especially your comment about Bodega being an "implementation detail." (This is why I made my second suggestion of having Boutique itself provide the information instead of making storageEngine accessible and therefore, accessing the implementation detail. But I definitely understand where you are coming from and have no disagreement.

As part of my own, personal, standard practice, every model I create has the concept of creation date and modification date. Since this information was already available, I thought it helpful to have access to it. It goes back to my own favorite mantra: the best code I write is the code I don't write. ;)