Plugin overview

This repository contains publishable TypeScript packages that encapsulate shared Investec Online platform behaviour. Most packages are small, stateful adapters: the consumer injects runtime context such as authResponse, environment, or menu state, then calls a function or subscribes to emitted updates.

Workspace structure

• each plugin is a top-level Nx library;
• each publishable package has its own package.json, project.json, and .azure-pipelines.yml;
• src/index.ts defines the public contract;
• VitePress documentation lives in docs/;
• plugins-demo is the local harness for exercising plugin APIs.

Plugin packages

Package	Responsibility	Main exports
@investec/plugins-adobe-analytics	Standardised Adobe Analytics event building and data-layer dispatch	AdobeAnalytics
@investec/plugins-client-type-router	Route URL context to clientType and shell interaction state	routeClientTypeBasedOnUrl, DEFAULT_ROUTE_RULES
@investec/plugins-cobrowse	Privacy-first Cobrowse.io lifecycle, session codes, cross-origin iframe bridging, and redaction	InvestecCobrowse, cobrowse
@investec/plugins-experience-manager	Determine pre-login and post-login destinations	determineJourneyPreLogin, determineJourneyAfterLogin, decodeDestination
@investec/plugins-feature-flags-builder	Legacy feature-flag aggregation from gateway endpoints	getUserFeaturesWeb
@investec/plugins-feature-library	Feature-registry loading, favourites, eligibility, Adobe Target overrides, and search	getWebFeatures, checkFeatureRequirements, featureSearch, addFavouriteFeature
@investec/plugins-left-nav-builder	Build left-nav items from menu state and client context	leftNavBuilder, getLoggedInMenuState
@investec/plugins-livechat	NICE CXone chat wrapper with thread recovery and browser events	LiveChat
@investec/plugins-menu-builder	Aggregate multiple menu APIs into one menu model	menuBuilder, setupMenu
@investec/plugins-personalisation	Adobe Target content retrieval and profile-update helpers	getAdobeTargetDataByTemplate, postProfileUpdatesByTemplate
@investec/plugins-portfolio-builder	Portfolio aggregation, totals, contact data, and portfolio streaming	portfolioBuilder, portfolio
@investec/plugins-profiles-builder	Retrieve and normalise client profiles	profilesBuilder, getProfiles
@investec/plugins-toggles-builder	Legacy toggle and kill-switch mapping	getToggles, mapToggles, removeToggledFeatures

Integration model

The packages fall into four groups.

Stateful shell builders

• Menu builder
• Left nav builder
• Portfolio builder
• Profiles builder

These packages expose ReplaySubject-based state objects, expect environment and auth context to be injected first, and emit updates incrementally.

Shell routing and journey helpers

• Experience manager
• Client type router

These packages are pure or mostly pure decision layers that map URL or auth context to navigation outcomes and shell chrome state.

Discovery and personalisation

• Feature library
• Feature flags builder
• Toggles builder
• Personalisation

These packages decide what a customer can see, open, or be shown, often by combining feature-registry data with authenticated client context.

External integrations

• Adobe analytics
• Livechat

These packages wrap third-party systems behind a smaller platform-facing API.

Consumer expectations

Before using a plugin:

1. import from the package root, not from internal file paths;
2. set any exported activeEnvironment value before making calls;
3. inject required state such as authResponse, clientType, or menu data before triggering builder functions;
4. treat exported subjects and mutable module-level caches as application-lifetime state unless the package exposes an explicit reset path.

How consumers extend plugin behaviour

The plugin package normally owns the shared logic. A consumer extends it by:

1. shaping the plugin input;
2. wrapping the emitted output in app-owned state;
3. composing application-specific rules after the plugin result;
4. using any explicit extension hook the package exposes.

Do not patch around a shared defect in every consumer if the rule belongs in the shared package. Use the plugin when the behaviour must stay consistent across platform consumers.

Legacy packages

feature-flags-builder and toggles-builder are legacy compatibility layers. They remain useful when the platform still expects their data shape, but they are not the preferred place to introduce new entitlement logic.

Related pages

• Get started
• Extension patterns
• Plugin demo

For the standards contributors and agents must follow when expanding a shared plugin, start with Get started and Extension patterns.