This solves the problem with optional fields in SettingsSchema in TypeScript.

In general I think we should avoid specifying default values in Pydantic models that are part of the HTTP API because the semantics are unclear. If you have something like:

class Settings(RefStudioModel):
    a: str = 'alice'
    b: str = 'bob'

@settings_api.put("/")
async def update_settings(req: SettingsSchema) -> SettingsSchema:
    ...

Then if the users hits the PUT endpoint with {"a": "archer"}, presumably their intention is to just set "a" to "archer" and not also set "b" to "bob".

Highlights:

• I "flattened" the settings schema like we talked about last week. The new model is FlatSettingsSchema and it has no Optional fields or fields with default values.
• I found this decorator to be the best way to make an all-optional version of a Pydantic model. This is like Partial<T> in TypeScript. I used this to define a FlatSettingsSchemaPatch model. This might be a useful pattern going forward. But if the update type is something more complicated (say you want to drop an id field that can't be updated) then maybe just writing out the two models explicitly is the way to go.
• Since the settings.json format has changed, I wrote a migration function.
• With a flat settings structure, the getDotNotation from tauri-settings isn't useful anymore and we can replace it with something much simpler. In fact, we can get rid of tauri-settings altogether! 🎉