How tree-shakable is onSnapshot?

[akauppi]

There are 8 different onSnapshot prototypes in the @exp API, differing by whether the first argument is a reference or query (2x) and the rest of the arguments (4).

What is the tree-shaking story for these?

In my code, I do:

import { query, collection, onSnapshot } from 'firebase/firestore'

...
  const tmp = (!qcArr || qcArr.length === 0) ? fbColl : query(fbColl, ...qcArr);
  const unsub = onSnapshot(tmp, (qss) => {
  ...

i.e. I end up using the same onSnapshot function for both collection (reference) and the query variant. I'll rework that code; but this is what made me think whether the packaging is in sync with rest of the @exp approach.

The current watershed is at whether I follow any of the data, at all. If I do, I get the code for following document, collection, and query, all in the same function.

Another option would be to shed the water between reference or query. This way, .onSnapshot could perhaps remain a method. Here, the compromise is whether one wants to follow data or just do individual gets.

Personally, I see that if someone uses Firestore, they likely want to follow the data in near real time instead of doing the imperative get's that of course are also possible. This could imply always, implicitly, bringing .onSnapshot along for the modules imported.

I don't care about one API over the other, but I do care about the tree shaking efficiency.

As to that, my first experience is:

dist/firebase.js     758.33kb / brotli: 84.64kb
dist/tslib.js        11.15kb / brotli: 1.81kb

That is a slight disappointment since I only use app, auth and firestore. I was expecting something like 400kB instead. These numbers are not the final word, but made me think about tree shakability not as a given, but a careful balance.

[akauppi]

More details on the build density (trying not to divert from the topic; this only shows that Firestore is not the problem with 0.900.15; auth still is):

EDIT: Due to a packaging glitch, auth ended up packaged twice in the numbers. Striking out expired notions.

vite v2.0.5 building for production...
✓ 67 modules transformed.
dist/vue-router.js           51.64kb / brotli: 11.48kb
dist/app.es.js               51.56kb / brotli: 13.78kb
dist/tslib.js                11.15kb / brotli: 1.81kb
dist/style.css               5.18kb / brotli: 1.44kb
dist/vue.js                  128.16kb / brotli: 25.35kb
dist/firebase.js             124.10kb / brotli: 21.61kb
dist/firebase/firestore.js   219.79kb / brotli: 37.95kb
dist/firebase/auth.js        206.36kb / brotli: 25.15kb    # CORRECT!   (original post had: 411.42kb / brotli: 26.86kb)

Auth is 53% of the overall Firebase size (30,4% compressed). tslib is counted in the sum, since it's only needed by Firebase.

I wonder why auth packs so much denser than Firestore code.

Overall compressed size of 88,23kB is very welcome. :)

---

EDIT: After cleaning up my packaging, the end result is an app with:

	text	compressed
app specific	52,0 kB	14,2 kB (10,0 %)
vue.js 3	179,6 kB	36,8 kB (25,8%)
firebase	570,9 kB	91,4 kB (64,2%)
---
total	802,5 kB	142,4 kB (100%)

[Feiyang1]

@schmidt-sebastian Is the realtime implementation for listening to documents, collections and queries the same, so it doesn't make sense to treat them differently in terms of tree shaking? or is there a chance to improve modularity somewhere?

[schmidt-sebastian]

All of our onSnapshot listeners use the same Query logic under the hood (even listeners for single DocumentReferences). The API layer is a bit different, but overall any improvements in tree-shaking here will not make a meaningful dent since our Listener logic relies on almost all of our internal SDK logic.

We could in the future split up our DocumentReference handling, but this is a major effort that will likely increase code size for most users.

[akauppi]

Got the answer I wanted. Marking this "answered" and trusting you to do a good work internally. 🙂

[akauppi]

@Feiyang1 Realized I could easily see which Firebase modules are being selected by Vite. Here's the list for auth and firestore:

firebase/firestore/dist/index.esm.js
@firebase/firestore/dist/exp/index.browser.esm2017.js

firebase/auth/dist/index.esm.js
@firebase/auth/dist/esm5/index.js
@firebase/auth/dist/esm5/index-392613a3.js

The good news is we have already found a workaround and plan to fix them soon.

Waiting for the next @exp releases. :)

[akauppi]

@Feiyang1 The suspicious size of firebase-auth turned out to be a mistake in my end; the module ended up packaged twice.

This puts firebase-auth at 206.36 kb (25.15 compressed) and the whole Firebase part of my app at 91,37 kb. I am fine with these results.