Request config rather than importing it #988
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
matthew-white
commented
May 1, 2024
| ], | ||
| fullWidth: true | ||
| }, | ||
| beforeEnter: () => (!config.showsAnalytics ? '/404' : true) |
There was a problem hiding this comment.
#819 added conditionalRoutes(). Before that, we used beforeEnter here.
2 tasks
matthew-white
commented
May 7, 2024
| // navigation. | ||
| const configPromise = config.dataExists | ||
| ? Promise.resolve() | ||
| : config.request({ url: '/client-config.json', alert: false }) |
There was a problem hiding this comment.
What is the error if the file isn't valid JSON?
ktuite
approved these changes
May 7, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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?
configis no longer a simple object and is now arequestDataresource. That makes it easy to send a request for it and to check its status. It's maybe a little funny thatconfigcan be accessed from either the container orrequestData, 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:
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 OIDC 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:
npm run testandnpm run lintand confirmed all checks still pass OR confirm CircleCI build passes