How to handle changes to hydrated state schema with existing app installs?

[mpiparo]

Apologies if this was asked before...

I'm using HydratedCubit to persist state and wanted to get feedback on how to handle changes to the state schema with existing installed apps.

The first question is does hydrated state data persist between app re-installs (updates)? Meaning if I publish a new version of the app and the user installs, will it attempt to load the existing state data from local storage set by the previous version of the app?

If so, the issue for me is that if the new version of the app for example added a new field to the state, the fromJson will fail since this new field wouldn't exist in the state data in local storage.

One solution is to make my fields nullable so the fromJson doesn't fail, but that doesn't solve other changes, such as changes to existing fields types, etc..

Just curious if anyone has dealt with this scenario and has some suggestions.

thanks!

[zmoshansky]

While trying to handle this scenario, I also ran into the following issue... #3243

@mpiparo
To handle schema changes historically in mobile apps, I've successfully leveraged an approach where:

Ephemeral State:

• Breaking changes to a schema wipe out the local state (knowing it'll be re-fetched from the server/re-generated)
  -- While simple, this is a remarkably effective and easy strategy that works quite well.

Non-ephemeral state:

• Migrations; I've preferred to migrate state such that it is compatible with all current requirements, add default values for non-nullable fields, etc prior to initializing the data-layer in the application. This approach ensures all validations/serialization/etc for the data layer operate as they should, without losing null safety or having lots of code throughout just to handle migrations. It's also quite compatible with freezed and similar, without needing to write custom (de)serialization code

For example:
1.) Check if app has been updated on launch (This can be done by saving/checking the app version that last ran); Perhaps there's a plugin/hook to help.
2.) Use Hive to directly open the HydratedStorage box, perform migrations, close box (This part can get ugly/brittle since it requires knowledge of the underlying storage mechanism.
3.) Call HydratedStorage.build
4.) As far as all your blocs are concerned, the data is exactly as expected, and always has been 😄

There are downsides to this approach: In step 2; You'd likely be manipulating JSON stringified data and you can't often use your existing classes as-is to help (Unless they can be extended and their serialization logic re-used to accommodate fields that have changed). Likewise, changes to HydratedStorage may cause breaking changes more frequently as you're essentially using a "private API" by manipulating its data.