Initial State isn't merged -- undefined is not assignable to type

[mxmtsk]

I have the following store setup:

export const createStore = (): RootStoreModel => {
  const app = AppModel.create({});
  const auth = AuthModel.create({});
  const organizations = OrganizationsStore.create({});

  const rootStoreInstance = RootStore.create(
    {
      app,
      auth,
      organizations,
    },
  );

  persist('persistedRootStore', rootStoreInstance, {
    storage: AsyncStorage,
    jsonify: true,
    whitelist: ['auth', 'organizations'],
  }).then(() => {
    console.log('💦', 'App hydrated');
    rootStoreInstance.app.setHydrated(true);
  });

  return rootStoreInstance;
};

This throws the following error on hydration:

Error: [mobx-state-tree] Error while converting {"auth":{"user":null,"token":null},"organizations":{"list":[]}} to RootStore:

at path "/app" value `undefined` is not assignable to type: `AppModel` (Value is not a plain object).

Error: [mobx-state-tree] Error while converting {"auth":{"user":null,"token":null},"organizations":{"list":[]}} to RootStore:

When I remove the whitelist so that the whole store is persisted it works fine. Am I doing anything wrong? I'm on mobx-state-tree@^3.15.0. and mst-persist@^0.1.3.

[agilgur5]

Hi @mxmtsk ! Apologies for the brief response, I'm out of the country till next week.

So when whitelist is not set, every key will be persisted. When it is set, only the keys listed will be persisted. In this case, app is not in the whitelist, so it's hydrated as undefined. But your RootStoreModel is typed such that app must exist (not a types.maybe or types.optional), so this will error.

So this isn't an mst-persist bug. But you might be getting confused by the fact that app is undefined instead of the initial state set during create. This is because mst-persist currently does not merge keys during hydration, it does a hard set, overwriting the initial state. There's an open issue for configurable merge strategies at #5 . Please up-vote that if that's what you're looking for.

[mxmtsk]

@agilgur5 Thanks for the quick reply. I found #5 aswell and thought it might be related. Your explanation makes me understand it more though and I found a way to workaround this - thank you!