Journeys in environment configuration

[arrilight]

This PR proposes a file-structure change for the apps: journey bundles will now live in shared libraries instead of inside of the app. This way we can dynamically change journey-list based on the configuration of the environment, having multiple apps with different journeys inside of one.

[unlimitedjest]

All in all I think this is a solid approach, and I'm excited for the changes!

[unlimitedjest]

We'll need some kind of support to define and render sub-menu items

[unlimitedjest]

The file name bundle is a bit confusing, especially with the more specific file name including bundle. Maybe including route in the name somewhere would help clarify at a glance?

[unlimitedjest]

Picking transactions as an example, but my comment would apply in general:

It could be useful to separate customer defined journey configuration options from options set in the product.

For example, I'd have a file journey-config-overrides that exports

export const journeyConfigOverrides: Partial<TransactionsJourneyConfiguration> = {
   showPendingOnTop: true,
   showCheckImages: true,
   accountInfoProperties: { ...goes here }
}

that would then be consumed by the generated journey bundle file here:

{
      provide: TransactionsJourneyConfiguration,
      deps: [EnvironmentService],
      useFactory: (envService: EnvironmentService) =>
        ({
          pageSize: 10,
          slimMode: envService.environment?.common.designSlimMode,
          ...journeyConfigOverrides
        } as TransactionsJourneyConfiguration),
}

Basically, during an upgrade, having this separation would 1) ensure we preserve journey configuration options set during development and 2) make it more transparent which values were set OOTB and which were added by the customer.

[daiscog]

Suggested change

	name: $localize`Ach Positive pay link@@main.ach-positive-pay.link.text:ACH Positive Pay`,
	name: $localize`:Ach Positive pay link@@main.ach-positive-pay.link.text:ACH Positive Pay`,

[daiscog]

Suggested change

	name: $localize`Make a Payment Link@@main.make-a-payment.link.text:Make a payment`,
	name: $localize`:Make a Payment Link@@main.make-a-payment.link.text:Make a payment`,

[daiscog]

Suggested change

	name: $localize`transactions list link@@main.transactions.link.text:Transactions List`,
	name: $localize`:transactions list link@@main.transactions.link.text:Transactions List`,

[daiscog]

I like to avoid casting wherever possible as it can mask some underlying type errors. Here, for example, slimMode is defined as just boolean in the TransactionsJourneyConfiguration type but the object being cast as that type could actually have boolean | undefined as the type of slimMode.

Refactoring to have an explicit return type on the factory exposes this as a compile error:

Suggested change

	useFactory: (envService: EnvironmentService) =>
	({
	pageSize: 10,
	slimMode: envService.environment?.common.designSlimMode,
	} as TransactionsJourneyConfiguration),
	useFactory: (envService: EnvironmentService): TransactionsJourneyConfiguration =>
	({
	pageSize: 10,
	slimMode: envService.environment?.common.designSlimMode,
	}),

[daiscog]

(I appreciate this isn't part of the point of the PR - there's a lot of stuff in the GSA that could do with cleaning up.)

[daiscog]

There's a lot of duplication of html structure here, just because *bbIfEntitlements will display nothing when given undefined. Maybe we can avoid this using an ng-template...

      @for (journey of journeys; track journey) {

        <ng-template #journeyLinkTemplate>
          <li class="bb-layout__horizontal-nav-item">
             <!-- ...etc -->
          </li>
        </ng-template>

        @if(journey.permissions) {
          <ng-container *bbIfEntitlements="journey.permissions">
            <ng-container *ngTemplateOutlet="journeyLinkTemplate" />
          </ng-container>
        } @else {
          <ng-container *ngTemplateOutlet="journeyLinkTemplate" />
        }

Maybe even better would be to speak with the web-foundation team to ask if they can change the *bbIfEntitlements directive so that if given a certain value, say '*', then it automatically shows the content without checking any entitlements. Then we could just do this:

      <li
        *bbIfEntitlements="journey.permissions ?? '*'"
        class="bb-layout__horizontal-nav-item"
      >
        <!-- ... etc -->
      </li>

[tcorral]

Good morning, @daiscog , @unlimitedjest .

What is the purpose and the status of this PR?