[Statsig] Slightly block the UI on gates

[gaearon]

This adds a tryFetchGates method which can be used to optimistically prefetch gates for some user. We are using this method to kick off the fetching in these situations:

• When you sign up
• When you log in
• When you switch accounts
• When you resume session

Then, by the time we ready the UI, we may already have the gates. This lets them kick in immediately instead of after a refresh. That's particularly important for signup since otherwise we have no ability to AB test onboarding.

There are some nuances. If the gate service goes down or if it's too slow, we don't want to block important operations. So there is a timeout. Also, a delay on rare operations (e.g. signup) is more acceptable than, say, a delay every time you start the app. Especially considering that if you're an existing user, you already have polling.

So I divided our cases into two groups:

• Login (with credentials) and signup have a longer timeout (1500 ms).
• All other operations have a very short timeout (250 ms).

If the Statsig call is fast (it generally is — unless the user has a bad connection), we always get fresh gates before we render the UI. If the Statsig call is lagging, we're willing to tolerate it a bit more during account creation and login, but not for longer than 1500 ms. And we're not willing to tolerate slow calls during everyday usage (so 250ms is the limit).

Test Plan

First, go through the same flows as in #3607. The last flow should now work even without steps 5 and 6 if your connection is fast enough (despite polling being commented out). You can artificially inflate the timeoutMs from 250 to 1000 for easier testing.

Next, try these flows. (For these, you can disable polling to keep testing cleaner. But it's also worth testing them at least once with polling set to 5 seconds.)

Incognito login:

1. Opt yourself into some feature flag.
2. Open incognito mode and log into your account with credentials.
3. Observe the gate passing immediately after login.

Registration:

1. Add some code to check the value of test_logged_in_gate during onboarding. (I set it up so that it only passes for logged-in users.)
2. Create an account
3. Observe the gate passing immediately after registration.

Finally, you can play with replacing Statsig.prefetchUsers([toStatsigUser(did)]) with a never-resolving Promise like new Promise(resolve => {}) or an always-failing Promise like new Promise(resolve => { throw Error('no') }). Verify that you're still able to create an account, log in, or switch between the accounts.

[render]

Your Render PR Server URL is https://social-app-pr-3608.onrender.com.

Follow its progress at https://dashboard.render.com/web/srv-cogkp5q1hbls73dn42e0.

[gaearon]

The pattern I'm using here is to kick it off as soon as we have the DID, but to await just before the state change.

[github-actions]

Old size	New size	Diff
6.42 MB	6.42 MB	432 B (0.01%)

---

[pfrazee]

Makes sense. (Didnt test)

[gaearon]

Have gone through all flows, seems to work.