To enable faster startup times and a better user experience, we should store last known feature state in local storage by default. It should be configurable, it should have a recommended stale date, and should be relevant based on the current user context.
An initial creation of the BrowserPolling object should check to see if there is a non-stale feature set in the local storage if configured to do so, and immediately feed it back into the repository if so. It needs to keep track of what contextSha was used to load the state, so if it changes, on a subsequent poll occuring, it checks for the new state and loads it in, even if the repository is ready. Typically clients will start on no-context and then almost immediately swap to a known context (e.g. with a user).
On a successful 2xx response, it should store the state.
To enable faster startup times and a better user experience, we should store last known feature state in local storage by default. It should be configurable, it should have a recommended stale date, and should be relevant based on the current user context.
An initial creation of the BrowserPolling object should check to see if there is a non-stale feature set in the local storage if configured to do so, and immediately feed it back into the repository if so. It needs to keep track of what contextSha was used to load the state, so if it changes, on a subsequent poll occuring, it checks for the new state and loads it in, even if the repository is ready. Typically clients will start on no-context and then almost immediately swap to a known context (e.g. with a user).
On a successful 2xx response, it should store the state.