Implement parsing fallback logic in @arborjs/json

[drborges]

Often times, it's useful to rename classes to make their intent more clear as your application design evolves along with new requirements.

In order to allow applications to smoothly transition their serialized data model to new versions, it would be interesting to support parsing fallback logic that would allow @arborjs/json to deserialize data mapping it to the correct data type even when the serialized type is no longer available in runtime, due to renaming.

Ideas:

@serializableWithFallback("MyTodo", "NewTodo")
class Todo {
}

We could also look into providing a more generic decorator that would support various configuration options:

@serialize({
  as: "Todo",
  from: ["MyTodo", "NewTodo"]
})
class Todo {
}

[drborges]

After some discussion with @gbmoretti, we feel like moving towards something like the following might provide an interesting DX while allowing applications to "migrate" stale and outdated serialized data to new versions of the state "schema".

Similar to how IndexedDB handles schema upgrades, we'd allow developers to provide @arborjs/json a migrate frunction that is responsible to migrate an outdated serialized state to the new format/schema:

function migrate(version, data) {
    if (version === 0) {
      return new TodoList(Object.values(data.todos))
    }
    
    if (version === 1) {
      return new TodoList(data.todos)
    }
    
    throw new Error(`Unable to migrate TodoList from version ${version}`)
}

@serializableAs("TodoList", {
  fallbackKeys: ["Todos", "AppTodos"],
  version: 2,
  migrate,
})
class TodoList extends Array<Todo> {

}

There are a few interesting things happening in the code snippet above:

1. The @serializableAs decorator would now receive a second argument responsible to configure the migration process responsible to handle that migration;
   1.1. fallbackKeys: Array of fallback keys that @arborjs/json would try to fallback to in order to find the key to extract the data from the serialized state in case the "official" serialization key TodoList is not found;
   1.2. version: A version used to determine if the serialized data matches the version defined in the decorator. In case they match, @arborjs/json knows the serialized data is compatible with the current application schema and deserialization can proceed normally. Otherwise, the migration process is triggered so the data can be deserialized by the provided migration logic;
   1.3. migrate: A migration function that takes the current version of the serialized data, this version is encoded in the serialized data itself (serialization format is yet to be defined but it could be as simple as { version: 1, data: { ... } }) and the actual serialized data to be migrated. The migration function then is responsible to compare versions and decide the best course of action to deserialize the given data.