Activities of "MarkHulevskyi"

This should be enough, thanks

Hi ABP Team,

We're reaching out regarding a customization scenario for our LeptonX-based application and would appreciate your guidance on the officially supported approach.

We're building a custom shell on Angular + ABP (LeptonX) and want to swap out specific LPX UI components for our own, while keeping their underlying ABP functionality (routing, auth, permissions, theme, language) intact. We need official guidance/APIs to do this safely, since the current public docs don't cover source-level replacement of these components.

What we want to do

1. Replace lpx-toolbar-container with our own component, while preserving its current functionality (user info, login/logout/profile actions, and the ability to add custom menu entries).
2. Extract the features from lpx-settings (theme switching, language switching, and control over which setting groups appear) and move them under our lpx-toolbar-container replacement, rather than replacing lpx-settings as a separate component.
3. Replace lpx-navbar with our own component, while preserving its current functionality (active route detection, expand/collapse state, grouped/child menu items, permission-based visibility).
4. Replace the overall application layout (currently rendered via abp-dynamic-layout) with our own layout component, while preserving ABP's route integration, permission filtering, and localization behavior.

What we're asking ABP for

• The officially supported way to replace each of these components (e.g., via ReplaceableComponentsService / eThemeLeptonXComponents.* keys, or another mechanism).
• The underlying service(s) that power lpx-settings, lpx-toolbar-container, and lpx-navbar (theme/language state, setting groups, user info, menu/route data) so we can reuse that logic inside our own components.
• The stable service contracts we should rely on (menu, user, route, permission services) so our replacements keep working across LeptonX updates.
• Source access or a working sample repo, if available, since current public APIs aren't enough for these replacements.