A partial update needs an explicit rule for a field that is omitted, supplied empty or deliberately cleared. Define those meanings before choosing an optional TypeScript property. Otherwise, a form that edits one customer detail can unintentionally erase another value simply because it was not included in the request.
YourBiz appears in the TypeScript collection. Its official site describes customer and repair records, making record updates a concrete context for this discussion. The examples are proposed contract designs, not claims about the product's private API.
Write the update semantics in plain language
Take a fictional customer record with a display name, phone number and internal note. Decide what should happen when a request changes only the name. The untouched fields should follow a documented rule rather than whatever a generic object merge happens to do.
Next, specify how an authorised user clears the note. A missing property may mean leave unchanged, while an explicit marker means remove the stored value. Choose a representation suitable for the API and keep it consistent across form submission, validation and persistence.
Avoid treating whitespace, an empty string and a missing value as interchangeable unless the field's domain explicitly permits that simplification.
Understand what the compiler option changes
TypeScript's exactOptionalPropertyTypes reference distinguishes an optional property being absent from it being assigned undefined, unless the type explicitly allows that value. This can make source-level intentions clearer.
The option does not decide your API's business semantics or validate incoming JSON. Document the wire representation separately and check it at runtime. A compile-time improvement is useful only when the application agrees on what the accepted data means.
Before enabling the option in an existing project, inspect errors as modelling questions. Adding undefined to every affected type may restore the build while avoiding the very distinction you intended to introduce.
Keep form defaults separate from saved values
A blank input shown while data loads should not automatically become a request to clear the database field. Track whether the original record has been loaded and which values the user actually changed.
Use a test where the user edits one field while a second field is absent from the visible form. Compare the resulting saved record field by field. Include validation failure and retry, because an error path can rebuild a payload differently from the successful path.
Consider concurrent edits as well. If another authorised user changes the note while the first edits the name, decide whether the update should preserve the independent change or require a version check.
Migrate through representative payloads
Collect sanitised examples of existing request shapes and describe their expected effects. Add cases for omission, explicit clearing, invalid values and unknown fields. Run them against an isolated data fixture before changing production handlers.
If older clients remain active, plan how the server recognises their existing contract. A shared package update does not instantly update every deployed browser session or external integration.
Review the final record and its explanation
After a successful update, show the saved result and retain the relevant audit context according to the application's policy. The response should make it possible to tell that one intended field changed and unrelated data survived.
For workflows with several named stages, combine these field rules with the discriminated-union state guide. Partial update semantics answer what a mutation changes; explicit states answer when that mutation is valid. Keeping both questions visible makes later refactoring safer.
