How do I register RouterConfiguration in multi-rooted app ( Aurelia 2)

Help Requests
1

In aurelia 1 I used aurelia.setRoot() to switch between login screen and the application. I tried to do it in au2 by following https://docs.aurelia.io/developer-guides/cheat-sheet (multi-root part) with a partial success.
When I register RouterConfiguration in main.ts, switching from “login-page” to “app-root” produces an error:
“A root RouteContext is already registered. A possible cause is the RouterConfiguration being registered more than once in the same container tree. If you have a multi-rooted app, make sure you register RouterConfiguration only in the “forked” containers and not in the common root.”
So my question is what is the proper way of registering RouterConfiguration in a multi-rooted app?
How do I “fork” the containers?
Is root-switching still valid approach in au2 for this scenario?

1 Like
2

I believe you can do something like below for your case.

const rootContiner = DI.createContainer();
rootContainer.register(
  StandardConfiguration,
  // and other common registrations.
);

const loginContainer = rootContainer.createChild();
// register anything that is specific to the login part of the app
const loginAu = new Aurelia(loginContainer);
// use this Aurelia instance for the login part of the app

const appContainer = rootContainer.createChild();
appContainer.register(RouterConfiguration /* and other as deemed fit */);
const appAu = new Aurelia(appContainer);
// use this Aurelia instance for the "app" part of the app.

However, please take this with a grain of salt, as I have not used multi-rooted app much. IMPO to introduce multiple roots only to support the login page seems a bit overkill to me; especially considering that the login part of the app is a significantly smaller portion as compared to the rest of the app. However, please don’t consider this as deterrence; I am intrigued on the contrary about the solution you end up with. Please do share your final approach.

2 Likes
3

Thanx for a fast response. I agree that it is an overkill for this use case. It is a remnant of an old private/public app area recipe. Cheat sheet also mentions login-wall as an example of a possible multi-root scenario. All this app switching and container juggling brings unnecessary complexity.
I am trying an alternate approach that shows great promise. It will be a part of an au-2-bootstrap skeleton which ties in several plugins (configuration, authentication, api) and bootstrap 5 customization via sass. Will share as soon as it’s done.

3 Likes
4

As promised, here it is:

3 Likes