When we use the Initialization gates there's a bit of an odd behaviour in my opinon. If we use a fallback on the OidcInitializationGate component and we get an error during bootstrap the errorComponent of OidcInitializationErrorGate is never shown.
In my case I have a loader on the first gate and that loader never dissappears.
Example:
async function bootstrapApplication(): Promise<void> {
// ... other async stuff
initializeOidc(); // wrapper function to load remote config
createRoot(getRoot()).render(
<StrictMode>
<MantineProvider theme={theme} defaultColorScheme="dark">
<OidcInitializationGate fallback={<LoadingOverlay visible />}>
<OidcInitializationErrorGate errorComponent={({ oidcInitializationError }) => oidcInitializationError.message}>
<RouterProvider router={router} />
</OidcInitializationErrorGate>
</OidcInitializationGate>
</MantineProvider>
</StrictMode>,
);
}
If the remote fetch fails for whatever reason (http error or zod validation failing) we can't make use of the error gate which we probably want.
Back in previous versions the boostraping accepted either an options object or an async callback. With the newer implementations that accept just an options object we could perhaphs pass an error property that would if it exists instantly stop the bootstrapping and show the errorComponent in the error gate.
This is probably just me nitpicking because we dynamically configure our deployed apps.
I will probably just await the bootstraping before rendering the app but I wanted to share this "issue" if you can call it that.
Version used: 10.2.1
When we use the Initialization gates there's a bit of an odd behaviour in my opinon. If we use a fallback on the OidcInitializationGate component and we get an error during bootstrap the errorComponent of OidcInitializationErrorGate is never shown.
In my case I have a loader on the first gate and that loader never dissappears.
Example:
If the remote fetch fails for whatever reason (http error or zod validation failing) we can't make use of the error gate which we probably want.
Back in previous versions the boostraping accepted either an options object or an async callback. With the newer implementations that accept just an options object we could perhaphs pass an error property that would if it exists instantly stop the bootstrapping and show the errorComponent in the error gate.
This is probably just me nitpicking because we dynamically configure our deployed apps.
I will probably just await the bootstraping before rendering the app but I wanted to share this "issue" if you can call it that.
Version used: 10.2.1