Rust Patterns • Patch Type
Stop confusing absent fields with null values
Welcome to the first post in my Rust Patterns series — a collection of small, practical patterns I’ve found invaluable in real-world Rust projects.
These aren’t complex abstractions or clever tricks, but rather simple & proven solutions to common problems I’ve stumbled upon.
In this post, we’ll explore a simple yet powerful type called Patch that we use extensively when handling data from users or external integrations.
Throughout my projects and contracting work, I’ve repeatedly encountered the same issue: incorrectly assuming that a missing field is equivalent to an explicitly null value.
I’ve seen this cause confusion and unexpected side effects countless times — yet it’s easily solved by wrapping these distinct states in a dedicated type.
Enter the Patch type:
At first glance, you’ll notice it closely resembles Option<T> — and that’s intentional. In our projects, it shares most of the same methods.
This similarity also makes conversion between the two types straightforward:
But where Patch really shines is at the API boundary — when deserializing user input:
This gives us precise control over UPDATE & PATCH semantics — we can finally distinguish between “clear this field” and “leave it unchanged”:
That’s the Patch type — simple, but it saves you from a lot of headaches when handling partial updates.
If you’re interested in using this type in your projects, check out value-extra.
It’s the only type in the library for now, but more are coming — types we use across our projects.
Have a different approach or questions? I’d love to hear about it in the comments.
Feel free to share this with anyone who might find it useful,
and if you found it interesting, consider subscribing!
Thanks for reading!