MMKV Plugin Multiple MMKV Id instances

[markmccoid]

I have a simple app that allows a person to create multiple users.

When logging in as a user, I use the userId as a MMKV Instance ID so that each "users" data is stored in a separate instance.

I'm having difficulty in understanding how to clear the observable variables when I switch.

It seems that if I empty the observable state, it clears the persisted state that I'm trying to load.

const onAuthChange = () => {
 // Get the MMKV id to persist to
  const currentUserId = authManager?.currentUser?.id || 'placeholder';
  const customMMKVConfig = new ObservablePersistMMKV({ id: `${currentUserId}` });
  const syncObs = syncObservable(tags$, {
    persist: {
      plugin: customMMKVConfig,
      name: 'tags',
    },
  });
// placeholder means we have logged out.
// I thought this would be the place to clear the observable state
// but this doesn't seem to work as expected.
  if (currentUserId === 'placeholder') {
    console.log('RESET TAGS');
//-- Tried both of the below to clear
    // tags$.reset();
    //tags$.allTags.delete();
    syncObs.clearPersist();
  }
};

Here is the reset function from the tags$ observable:

  reset: () => {
    tags$.allTags.set([]);
    currStorage?.setItem('tags', []);
  },

I know it is something I'm doing wrong, so any pointers would be appreciated.

Thanks!

[markmccoid]

I'm sure there is a better way, but I moved the creation of the observable and its syncObserver into a function that recreates the Observable when a user is logged in.

Here is a code snippet. Still hoping to hear from someone needing this type of functionality as I would love to hear how you accomplished. I'm excited to use Legend State, so I want to utilize it to its fullest!

export let tags$: Observable<AllTags>;
const initialize = () => {
  tags$ = observable<AllTags>({
    allTags: [],
    addTag: (tagname) => {
      const allTags = tags$.allTags.peek() || [];

      const newTag = { id: uuid.v4(), name: tagname, position: allTags.length + 1 };
      tags$.allTags.set([...allTags, newTag]);
      currStorage?.setItem('tags', tags$.allTags.peek());

      console.log('MMKV ID', currStorage?.getItem('mmkvid'));
    },
    removeTag: (tagId) => {
      const allTags = tags$.allTags.peek();
      const newTags = allTags.filter((el) => el.id !== tagId);
      tags$.allTags.set(newTags);
      currStorage?.setItem('tags', newTags);
    },
    reset: () => {
      tags$.allTags.set([]);
      currStorage?.setItem('tags', []);
    },
  });
  const customMMKVConfig = new ObservablePersistMMKV({ id: `${authManager?.currentUser?.id}` });
  const syncedTags = syncObservable(tags$, {
    persist: {
      plugin: customMMKVConfig,
      name: 'tags',
      options: {},
    },
  });
  observe(() => {
    console.log(`OBSERVED TAGS-${authManager?.currentUser?.name}`, tags$.allTags.peek());
  });
};
initialize();
authManager.subscribe(() => {
  initialize();
});

[MILLERMARRU]

I looked at this closely because your workaround (recreating the whole observable + calling syncObservable again inside initialize()) looks like a hack but it's actually the correct pattern here, not something to avoid.

The root problem: syncObservable(tags$, { persist: { plugin: customMMKVConfig, name: 'tags' } }) binds a persist plugin instance to tags$ at the moment you call it. If you keep reusing the same tags$ observable and just call syncObservable again with a new ObservablePersistMMKV({ id: newUserId }), the original binding to the old MMKV instance is still alive, nothing tears it down. So you end up with two active persist bindings on one observable, the old one still pointed at the previous user's MMKV instance. When you then call tags$.allTags.set([]) (or .delete()) to "reset", both bindings can react to that change, which is exactly the kind of bleed-through that would make clearing look like it's wiping the wrong instance's data or not taking effect where you expect.

Recreating tags$ from scratch per user, like your snippet does, sidesteps this entirely: the old observable (and whatever's bound to it) just goes out of scope when you reassign tags$ = observable(...), no explicit teardown needed since there's nothing left holding a reference to the old one. That's the same shape synced()/syncObservable() expect, one observable, one persist config, for its lifetime. I'd keep the initialize()-per-login-event pattern you already built rather than trying to mutate the existing observable's persist target in place.