Best practise for creating and updating an item and dealing with onSnapshot triggers

[axzr]

Hi folks,

I've hit a weird infinite loop bug seemingly in an interaction between mst and firestore. I've found a fix, but it feels like a hack so I'm hoping that the community might have a better suggestion for me.

Here's the issue

1. I create a new instance of a model
2. 'shortly' afterwards (in the same 'processing cycle') I update that item
3. onSnapshot triggers and saves the new/plain item to firebase (v1)
4. onShapshot triggers and saves the updated item to firebase (v2)
5. the subscription to firestore triggers and updates the item to v1
6. this triggers a save
7. the subscription to firestore triggers and updates the item to v2
8. this triggers a save
9. goto 5

I get that maybe creating and updating the model 'close together' could be bad, and could lead to over-writing one version or the other. I don't get how this causes an infinite loop of swapping between the two versions.

I fixed the issue by adding a timeout at point 2 above. It was a hunch after trying a bunch of other stuff.

I'm not actually asking for a fix to the infinite loop, as such. I guess what I'm asking, is there a best practice for how to go about creating/updating a model in quick succession? It's done essentially synchronously, whereas (I believe) the onSnapshot triggers are going to fire asynchonously? That seems like a bad match.

I was thinking of debouncing the save function within onSnapshot, but again, just wondering what best practise is?

Sorry if my explanation isn't great. I'm still new to mst.

Cheers!

[EmilTholin]

Hi @axzr!

Maybe you could temporarily dispose the onSnapshot listener as you sync your MST models with the Firestore data as to not create the infinite loops?

Example

import { addDisposer, applySnapshot, onSnapshot, types } from "mobx-state-tree";
import {
  doc,
  onSnapshot as onFirestoreSnapshot,
  setDoc
} from "@firebase/firestore";

const Model = types
  .model({
    foo: "bar"
  })
  .actions((self) => {
    let snapshotDisposer;
    const listen = () => {
      snapshotDisposer = onSnapshot((snapshot) => {
        setDoc(doc(db, "foo", "bar"), snapshot);
      });
    };
    const unlisten = () => {
      snapshotDisposer();
    };

    return {
      afterCreate() {
        // ...
        self.foo = "baz";

        // Set up the MST snapshot listener...
        listen();

        const firestoreUnlisten = onFirestoreSnapshot(
          doc(db, "foo", "bar"),
          (doc) => {
            // ... but temporarily disable it when applying a Firestore
            // snapshot as to not create infinite loops.
            unlisten();
            applySnapshot(doc.data());
            listen();
          }
        );

        // Dispose the listeners when the model is destroyed.
        addDisposer(self, () => {
          unlisten();
          firestoreUnlisten();
        });
      }
    };
  });

[axzr]

Hi Emil,

Thanks for that. That's really interesting. I can't use that exact method as I'm subscribing at the collection level, but that is a really good lead, thank you!

I'm still curious though why any form of workaround is needed at all. Not sure if you are able to answer that?

Cheers!

[EmilTholin]

No problem! Great!

I might be wrong, but I don't think it's the update of the model instance "shortly" after it is created that causes the loop, but rather:

The MST model instance creation results in data being sent to the firestore, which leads to a new firestore snapshot, which in turn leads to an update of the MST model, ...

If you were to look in the Network tab of your browser I think you would see a never-ending amount of requests, but it doesn't look like it in the UI since the data is the same.

[axzr]

You've hit the key thing here: the data is /not/ the same. The data flip-flops between two versions of the model. One version as it was created, and one as it was modified.

If I get the chance I'll see if I can put together a minimum viable reproduction.