Shared State: File Storage, Part 2

Episode #276 • Apr 22, 2024 • Subscriber-Only

It’s incredible how easy @Shared makes it to persist complex data types to the file system, but currently it completely ruins our ability to test features that use it. Let’s fix that, and we will also explore what it means to derive a small piece of shared state from a bigger piece of shared state.

Previous episode
Shared State: File Storage, Part 2
Next episode
Locked

Unlock This Episode

Our Free plan includes 1 subscriber-only episode of your choice, plus weekly updates from our newsletter.

Sign in with GitHub

Introduction

Brandon

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.

Stephen

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.

Making file storage testable


Downloads

Get started with our free plan

Our free plan includes 1 subscriber-only episode of your choice, access to 64 free episodes with transcripts and code samples, and weekly updates from our newsletter.

View plans and pricing