RFC: Use of NgRx Store for Global State Management

[nicobytes]

Summary

This RFC proposes adopting NgRx Store as the primary solution for managing global state for dotCMS app and keep Signal Store for local/component state. The goal is to reduce unnecessary server requests, improve UI/UX responsiveness, and provide a consistent approach to application-wide state management.

Background

We currently have two viable options for global state management:

1. NgRx Store (based on RxJS)
2. Signal Store (based on Angular Signals)

Both solutions offer advantages and trade-offs. However, based on our project needs—including managing complex, interconnected data and scaling our architecture—NgRx Store I think is the more appropriate choice.

When to Use NgRx Store

• Applications with complex or relational state.
• Requirements for undo/redo functionality.
• Large-scale applications needing maintainability and robust tooling.

When to Use Signal Store

• Simple, isolated component state.
• When boilerplate should be minimal.

Why NgRx Store?

Pros

• Scalability: Well-suited for complex, feature-rich applications.
• Debugging Tools: Seamless integration with Redux DevTools for time-travel debugging and clear visualization of state transitions.
• Ecosystem: Mature and well-supported, including devtools, router integration, and effects handling.
• Selector Composition: Ability to reuse and compose selectors for better maintainability.
• Signal Integration: Selectors can be consumed as signals in components, enabling compatibility with the Signal's pattern.

Cons

• Learning Curve: Requires a deeper understanding of RxJS, actions, reducers, and effects.
• Boilerplate: Increased setup overhead for actions, reducers, and effects.

Why Not Signal Store (For Global State)?

While Signal Store is a compelling solution for local state due to its simplicity and lower boilerplate, it presents several challenges for global state:

Ecosystem Limitations

• No mature equivalents of @ngrx/store-devtools or @ngrx/router-store. For example, the router-store lib will be useful to solve the problems with navigation state and solve some issues in our breadcrumb component.
• Lacks tooling for time-travel debugging and router synchronization.

Limited Computed Reusability

Signal Store's computed() values can't easily reference each other, making selector composition more difficult:

export const MyStore = signalStore(
  withState(initialState),
  withComputed((state) => ({
    totalPages: computed(() => Math.ceil(state.data().length / state.pagination().rowsPerPage)),
    isEnable: computed(() => state.totalPages() > 1), // ❌ Cannot reference totalPages
  }))
);

By contrast, NgRx selectors are easily composable:

export const selectUser = (state: AppState) => state.selectedUser;
export const selectAllBooks = (state: AppState) => state.allBooks;

export const selectVisibleBooks = createSelector(
  selectUser,
  selectAllBooks,
  (user, books) => books.filter(book => book.userId === user.id)
);

Signal-Compatible Selectors

NgRx allows selectors to be consumed as signals in component code:

export class UsersComponent {
  private readonly store = inject(Store);

  readonly users = this.store.selectSignal(selectUsers); // ✅ Signal<User[]>
}

How to Work with Global State Management Using Nx?

We need to explore how to structure and access global state effectively using the Nx libraries.

🔍 Spike Needed: Investigate and document the recommended patterns for managing global state in an Nx monorepo.

Key Questions:

• How should global state be exposed across libraries and applications?
• How can a feature like edit-content access and interact with global state owned by another domain?
• Should we colocate feature state in the libs folder, or centralize it?

Example Case:

The edit-content feature needs to read and update global application state. How should this interaction be designed using Nx boundaries, dependency rules, and shared libraries?

Outcome of this spike will help define our conventions and folder structure for scalable state access and sharing.

Conclusion

Given the complexity of our global state, our scale, and the need for a robust ecosystem, NgRx Store is the most suitable choice for our global state management strategy. While Signal Store remains useful for local component state, NgRx will offer the consistency, scalability, and tooling support needed for our application architecture.

[wezell]

One thing we need to fix is the re-syncing state between client and server when the user has been disconnected from the server. We need to send and set a couple of things when the websocket reconnects after a disconnect - things like the current site (site selector) that the user was on, the user's language of choice for the backend, etc....

Without doing that resync, we have a disconnect between the client state and the user server session- where the user looks like they are on SiteA and the server thinks they are on the default site.

[oidacra]

With NgRx, we can listen to websocket events and trigger actions in our frontend. For example, when the websocket reconnects, we can dispatch an action to re-sync the state by sending the current selected site, user language preferences, and other necessary data to the server.
We could implement an effect that listens for a 'WEBSOCKET_RECONNECTED' action, then collects the current state (site selection, language, etc.) from the store and sends this data to the server through the websocket. This way, we ensure that when a user reconnects after being disconnected, the client and server states are properly synchronized.

[zJaaal]

Is it possible to granulate the store? And not have a big file full of logic?

I remember when we implemented NgRx Store on the UVE, we had that problem, our store was way too big and we solved that migrating to Signal Store with the Slices feature. With that we were able to granulate our store as we pleased and not have one big store that was a nightmare to maintain

[nicobytes]

In this case, the idea is to define our global state and identify which elements truly belong to it—such as the current site, user info, feature flags, etc. Each feature should manage its own state independently. For example, UVE uses a custom store, the content editor also have a custom store and even some components have their own granular stores to handle local state. So, we’re already using a granular approach for feature states. Now, we just need to properly define our global state, which should remain small and focused.

[fmontes]

This is a great proposal @nicobytes , thanks for sharing.

I agree that @ngrx/store has strong advantages, especially for complex, interconnected states, and specially our routing state, but I'm concerned about over-engineering.

Before committing, I think we should try to define how our global state will potentially look like. Without this, we risk adding unnecessary complexity.

Suggested Next Steps

1. Scope Global State: Define what data genuinely needs to be globally shared versus local to specific portlets or features.
2. Validate Complexity: Test a few critical use cases, like navigation and content editing, to confirm if our state needs are as complex as assumed.

Happy to discuss this further once we have a better understanding of the actual state boundaries.

[oidacra]

My take on this,

Angular Signals Integration

Initially, I had concerns about NgRx using observables while Angular is moving toward signals. However, NgRx now provides this.store.selectSignal() which returns a signal instead of an observable for any store slice.

This means:
UI layer: Always use signals for better performance and simplicity
Complex operations: Use observables only when needed (pipes, startWith, concat, filter, etc.)

Best of both worlds - signals for UI reactivity, observables for complex async operations.

NgRx: Simple Solution to a Complex Problem

NgRx appears complex, but it's actually a simple solution to the complex problem we already have: creating a root store with dotCMS's inherent complexities. The complexity exists regardless - NgRx just manages it systematically.

Strongly Defined Patterns

Having a well-defined pattern means that after 6-12 months without touching the code, any developer can immediately understand how the state behaves. No guessing, no reverse-engineering custom solutions.

Single Source of Truth & Reusability

Any feature in dotCMS that needs sites, languages, feature flags, etc., knows exactly where to find them. One source of truth, completely reusable across all features. No data duplication or synchronization issues.

Traceable Debugging

We get highly traceable debugging - we know exactly how the store behaves at any point in time. Critical for enterprise clients when something goes wrong in production.

Native WebSocket Support

WebSocket integration is natively supported through Effects. No custom implementation needed.

Critical Boundary Definition

The most important consideration: clearly define what belongs in the root store and what doesn't.
Simple Rule: If data is used by more than one feature → Root Store. If it's feature-specific → Local State.
Root Store: Sites, languages, feature flags, user session, connection state
Local State: Component-specific UI state, form data, temporary states

[nicobytes]

Hello! Continuing with the conversion here, a first version of our global store looks like this:

interface AppGlobalState {
  auth: {
    currentUser: CurrentUser | null;
    permissions: UserPermissions;
  };
  currentSite: SiteDetails | null;
  featureFlags: Record<string, boolean>;
  systemLanguages: LanguageInfo[];
  userPreferences: {
    languageCode: string;
    timeZone: string;
    uiTheme: {
      primaryColor: string;
      secondaryColor: string;
      darkModeEnabled: boolean;
    };
    navigation: {
      isCollapsed: boolean;
    };
  };
  license: {
    type: 'community' | 'enterprise' | string;
    version: string;
    buildNumber: string;
  };
  breadcrumbMenu: MenuItem[];
}

This is pretty short and contains the common states using across the all app.

In this doc, more detail about that:
https://docs.google.com/document/d/1zV6oHhV20XJ22YoFWCty8AjX2h8AdkQgxise09sMFzc/edit?usp=sharing