Schedule everything on the AsyncQueue

[schmidt-sebastian]

This PR fixes a scheduling problem in the firestore-exp client. Before this change, most methods looked like this:

getComponent().then(() => enqueueOp())

That meant that getComponent() did not run on the AsyncQueue. During a test I noticed that the following did not issue a write:

setDoc(docRef, {});
terminate(firestore);

This was because terminate did not use getComponent() and hence was able to schedule its task on the async queue before setDoc().

This is a large PR but I am out next week so take your time :)

[changeset-bot]

💥 No Changeset

Latest commit: 94c0d82

Merging this PR will not cause any packages to be released. If these changes should not cause updates to packages in this repo, this is fine 🙂

If these changes should be published to npm, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[google-oss-bot]

Size Analysis Report

Affected Products

No changes between base commit (cc16b4a) and head commit (1060664).

Test Logs

• Base (cc16b4ae): https://github.com/firebase/firebase-js-sdk/actions/runs/244776757
• Head (1060664f): https://github.com/firebase/firebase-js-sdk/actions/runs/244794143

[google-oss-bot]

Binary Size Report

Affected SDKs

• @firebase/firestore

  Type	Base (cc16b4a)	Head (1060664)	Diff
  browser	248 kB	248 kB	-238 B (-0.1%)
  esm2017	196 kB	196 kB	-40 B (-0.0%)
  main	482 kB	482 kB	-212 B (-0.0%)
  module	246 kB	246 kB	-194 B (-0.1%)
  react-native	196 kB	196 kB	-40 B (-0.0%)

• @firebase/firestore/exp

  Type	Base (cc16b4a)	Head (1060664)	Diff
  browser	189 kB	189 kB	+261 B (+0.1%)
  main	474 kB	477 kB	+2.72 kB (+0.6%)
  module	189 kB	189 kB	+261 B (+0.1%)
  react-native	189 kB	190 kB	+261 B (+0.1%)

• @firebase/firestore/lite

  Type	Base (cc16b4a)	Head (1060664)	Diff
  main	142 kB	142 kB	+2 B (+0.0%)

• @firebase/firestore/memory

  Type	Base (cc16b4a)	Head (1060664)	Diff
  browser	186 kB	186 kB	-238 B (-0.1%)
  esm2017	147 kB	147 kB	-40 B (-0.0%)
  main	356 kB	356 kB	-212 B (-0.1%)
  module	184 kB	184 kB	-194 B (-0.1%)
  react-native	147 kB	147 kB	-40 B (-0.0%)

• firebase

  Type	Base (cc16b4a)	Head (1060664)	Diff
  firebase-firestore.js	286 kB	286 kB	-189 B (-0.1%)
  firebase-firestore.memory.js	226 kB	226 kB	-189 B (-0.1%)
  firebase.js	821 kB	821 kB	-193 B (-0.0%)

Test Logs

• Base (cc16b4ae): https://github.com/firebase/firebase-js-sdk/actions/runs/244776757
• Head (1060664f): https://github.com/firebase/firebase-js-sdk/actions/runs/244794143

[var-const]

Question: what's the reason to check for _terminated? Can an instance be terminated without being initialized? If yes, consider adding this bit to the error message below.

[schmidt-sebastian]

If a user calls "terminate()" on an uninitialized Firestore, we should also not initialize it. The error message is actually shared between the new SDK and the old SDK and hence, I would rather not touch it.