Compatibility with Firebase Modular JS SDK (v9)

[sceee]

What problem is this solving

Firebase recently introduced the modular web SDK, currently in beta.
One of its goals is to reduce the footprint of the lib allowing tree shaking. Therefore, a lot of users might want to benefit from using it.

Using vuexfire does currently not seem to be working with the new Firebase modular SDK because of the changed API:

TypeError: document.onSnapshot is not a function
    at bindDocument (webpack-internal:///./node_modules/vuexfire/dist/vuexfire.esm.js:456)
    at eval (webpack-internal:///./node_modules/vuexfire/dist/vuexfire.esm.js:614)
    at new Promise (<anonymous>)
    at bind$1 (webpack-internal:///./node_modules/vuexfire/dist/vuexfire.esm.js:603)
    at bindFirestoreRef (webpack-internal:///./node_modules/vuexfire/dist/vuexfire.esm.js:655)

See here for the new way the API works. What used to be something like this:

db.collection("cities").doc("SF")
    .onSnapshot((doc) => {
        console.log("Current data: ", doc.data());
    });

...is now something like this:

import { doc, onSnapshot } from "firebase/firestore";

const unsub = onSnapshot(doc(db, "cities", "SF"), (doc) => {
    console.log("Current data: ", doc.data());
});

That's why I think the bindFirestoreRef(...) now needs to be adjusted to adjust to the new API.

Proposed solution

As version 9 of the Firebase JS SDK will be the modular one, adjust to the new API so that vuefire/vuexfire works with the Firebase 9 JS SDK.

Describe alternatives you've considered

Stick with Version 8 of the Firebase JS SDK for now.

[sceee]

@posva I would be happy to help with the migration to the modular Firebase 9 SDK but unfortunately, I don't really understand how to build the projects (I'm not really into lerna & rollup).

Is there anywhere some hint on how to build & test the whole repository?
If so I would be happy to create a PR.

[posva]

@sceee the branch that needs to be updated is https://github.com/vuejs/vuefire/tree/v3 which is the next version of Vuefire that works for both Vue 2 and Vue 3. I haven't checked the breaking changes aside from modules from 8 to 9 but if that's the only breaking change, then it's fine to upgrade it.

Tests are currently failing after the upgrade to firebase 8 but it's no longer a lerna monorepo, so it should be easier to handle 🙂

[sceee]

@posva thank for the info - I will have a look and see if I can prepare a proposed upgrade.

I think there's not yet a changelog available for Firebase SDK v9 (as it's also still in Beta) but according to my information, this seems to be the only change.
There are some slight limitations at the moment, though, but according to my understanding they are not relevant to vuefire: https://firebase.google.com/docs/web/modular-upgrade#benefits

Anyway, I think the way forward will be v9 and therefore I think it would be good have vuefire support it better earlier than later (maybe also as a separate (alpha/beta) release so that Firebase v8 users can still use vuefire v3 and Firebase v9 users can use vuefire v4 (alpha/beta)?).
Would you agree?

[sceee]

I just noticed that firebase-mock is used for the tests which is already a blocker as it depends on the namespaced Firebase SDK (v8).

I anyway guess firebase-mock is kind of obsolete and it will probably not continue to be maintained well in the future as there is the official Firebase emulator suite now for local testing (which works way better IMHO).

So it would probably be better (and required) to migrate from firebase-mock to using the Firebase emulators for tests first.
Do you think this would make sense?

It unfortunately seems it's getting a bigger change than I initially thought...

[posva]

Do you think this would make sense?

Yes, feel free to do it

[sceee]

I pushed some work in progress here: https://github.com/sceee/vuefire/tree/firebase-emulators
and created an Action that executes the tests here: https://github.com/sceee/vuefire/actions/workflows/test.yml

Still, a lot of tests are failing but it's getting better.
I hope I can get all of the more fancy tests to work with the new setup.

[sceee]

@posva I fixed some more tests (it's now down to ~20 failing) but now I'm getting to a point where I'm getting stuck.

I think there are a few groups of issues left:

• Timing issues (target.items.value did not yet update after a item.set (DB update) call) - I introduced sleeps here which is definitely not ideal but solved a lot of them. Still, some are sometimes failing. I also discovered some floating promises in the code (but also production code). It could also result from these but I do not want to change the production code. Probably for more reliability, some timeouts need to be introduced/increased in the tests.
• Sometimes (also seems to be a timing issue) the following exception occurs (which - based on the comment above that line - looks kind of like a bug to me). It seems this occurs if the data is not yet bound correctly:

  ● refs in collections › keeps array of references when updating a property

    TypeError: Cannot read property '0' of undefined

      21 | ): Record<string, any> {
      22 |   // TODO: development warning when target[key] does not exist
    > 23 |   return path.split('.').reduce((target, key) => target[key], obj)
         |                                                        ^
      24 | }
      25 |
      26 | /**

      at src/shared.ts:23:56
          at Array.reduce (<anonymous>)
      at Object.walkGet (src/shared.ts:23:26)
      at Object.data (src/firestore/index.ts:151:19)

• some unbind spies do not work/are not triggered as expected. Example:

  ● refs in collections › unbinds refs when the collection is unbound

    expect(jest.fn()).toHaveBeenCalledTimes(expected)

    Expected number of calls: 1
    Received number of calls: 0

      128 |     await delay(200)
      129 |
    > 130 |     expect(spyA).toHaveBeenCalledTimes(1)
          |                  ^
      131 |     expect(spyB).toHaveBeenCalledTimes(1)
      132 |
      133 |     spyA.mockRestore()

      at Object.<anonymous> (__tests__/core/firestore/refs-collections.spec.ts:130:18)

I have the feeling that behavior for the unbind changed in Firebase compared to how firebase-mock mocks it.
So I'm actually not sure if there's really an issue now or if the tests simply would need to be adjusted. <-- This is where I would appreciate some help

Besides that, I had to make some general adjustments to some tests:

• Besides the timing issue, the order of elements when "storing" a bound collection in target.items.value is no longer deterministic. I have the feeling this is in-line with Firebase production service (it was just deterministic with firebase-mock) but I'm not 100% sure.
• The amount of times some spies are called changed (increased)

Would you think you have the possibility to take a look at the remaining failing tests (especially the failing unbind tests) to assess whether they really need to work like they are at the moment or some can be adjusted to the "new" behavior? Or if you have an idea why some of them are failing/how to fix them?

If you want to execute the tests locally, please

1. First install firebase-tools globally if you don't yet have them: npm i -g firebase-tools
2. Execute npm run test:unit - You can also execute the emulators using firebase emulators:start from the project directory and then - in a separate terminal, execute the tests (or single files) using npm run test:unit:execute. Use npm run test:unit:execute -- --t core/firestore/util if you just want to execute some files / it.only tests

If you prefer, I could also create a PR (draft) so we move the future discussion over there so we don't spam this issue.

Happy to hear what you think.

[posva]

I will take a proper look in a few weeks, after some Vue 3 related releases, and try to give you a hand. Have you published your code somewhere?

[sceee]

Thanks @posva . Yeah, the code is published here https://github.com/sceee/vuefire/tree/firebase-emulators and the latest action run always shows the up to date state.

[posva]

Thanks a lot @sceee !

I will get to this probably after a stable release on Pinia with Vue 3.2

[dosstx]

Thank you both for the work on migrating to v9. Even though v9 is still beta, I am loving it. The API is fantastic and everything is much faster. Just wanted to say keep up the great work!

[bangdragon]

How is the progress. I would love to use this library for firebase v9 because it has tree shaking.
Thanks

[sceee]

@posva quick question - is the code in old_src in the v3 branch still used or can it be deleted (just to make things easier to overview)?

[posva]

I think it can be ignored