Request config rather than importing it

[matthew-white]

This PR makes progress on getodk/central#656. Previously, the Frontend config (src/config.js) was imported synchronously. createContainer() added the config to the container. Now the config will be requested during the initial navigation along with other initial requests.

Specifically, the config will now be requested from /client-config.json. We will need a new PR to the central repo to serve that file. This PR updates the nginx config for local development.

What has been done to verify that this works as intended?

I wrote new tests. I also tried it out locally. Frontend continues to load without issue. I can also see that changes to either src/config.js or /client-config.json are picked up.

Why is this the best possible solution? Were any other approaches considered?

config is no longer a simple object and is now a requestData resource. That makes it easy to send a request for it and to check its status. It's maybe a little funny that config can be accessed from either the container or requestData, but I think it's OK.

src/config.js still exists and is now the default config. It will be merged with the response from /client-config.json. I thought about removing src/config.js, but I think it's nice to have a single place to see the different config options. Deployments should no longer modify src/config.js and should instead modify /client-config.json.

The most important change is to the router and how it sends the initial requests. Previously, the router sent up to 4 requests. Now it will send up to 5:

• /v1/sessions/restore
• /client-config.json
• Translations for the user's locale
• /v1/users/current (once responses have been received for /v1/sessions/restore and /client-config.json)
• /v1/config/analytics (once a response has been received for /v1/users/current, if the user is an admin)

We will send the first three requests immediately, then send the latter two once the required responses have been received. Both the latter two requests depend on the config. The last request, for /v1/config/analytics, does not block rendering: the initial navigation proceeds once the other requests are complete.

Another part of my approach that I wanted to make note of is that I tried to handle the case where the request for /client-config.json fails. If that happens, we won't know how to render parts of Frontend. Importantly, we won't know how to render the login page (because we won't know whether SSO is enabled). Given that, if the request fails, the user will be sent to a special error page. They will be prevented from leaving the page for elsewhere in Frontend. As an alternative, I thought about canceling the initial navigation and just showing an alert. However, I think it's easier to reason about Frontend if the initial navigation always completes and there's always some current route (even if that route is for an error page).

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

There's now one more request before Frontend is rendered, so the initial load time will be a little slower. However, I doubt that it'll be much slower at all. The request will just hit nginx, not Backend or the database. The config file should be very small. We don't have that many initial requests in the scheme of things.

Before submitting this PR, please make sure you have:

• run npm run test and npm run lint and confirmed all checks still pass OR confirm CircleCI build passes
• verified that any code or assets from external sources are properly credited in comments or that everything is internally sourced

[matthew-white]

#819 added conditionalRoutes(). Before that, we used beforeEnter here.

[matthew-white]

Notes from interactive review