We have now made some incredible improvements to the library. We have a .fileStorage
persistence strategy that sits right alongside the .appStorage
strategy we created last episode. Where .appStorage
is great for persisting tiny bits of simple data in a lightweight way, .fileStorage
is great for persisting large, complex data structures. And we’ve even built in some niceties in the strategy such as debouncing save tasks so that we don’t thrash the file system with disk writes, and we are even listening for changes on the disk so that we can detect external writes and update our shared state accordingly.
But what about testing? We saw with .appStorage
we had to do a little bit of extra work to make sure that shared state didn’t bleed out from test to test, and I would imagine the same is true of .fileStorage
. After all, the file system is a large, global, mutable blob of data that anyone can access and write to at any time. Surely that is going to complicate testing.
Let’s take a look.