DOCSEARCHbyAlgolia
Submit Docs

NgRx Platform

repository·main·Indexed 27 days ago

https://github.com/ngrx/platform

A monorepo for NgRx development, featuring a reactive state management library for Angular applications. It includes the ComponentStore for managing local state via updater(), setState(), and patchState(), as well as tools for selecting state as Observables or Signals and handling side effects with effect(). The repository also provides schematics-core utilities for AST transformations, Angular workspace management, and ESLint configurations for Angular TypeScript and HTML templates.

Tokens
151.2K
Snippets
411
Records
787
Agent score
91%

What's inside @ngrx/platform

  1. Overview of @ngrx/component-store concepts

    main

    ComponentStore is a standalone library designed to manage local or component-level state. It serves as a reactive alternative to the 'Service with a Subject' pattern.

    Key capabilities include:

    • State Lifecycle: State is typically tied to a component's lifecycle and is cleaned up upon component destruction.
    • State Initialization: State can be initialized either eagerly or lazily.
    • Writing State: State updates are performed using setState or updater methods, supporting both imperative updates and Observable-based updates.
    • Reading State: State is accessed via select (highly performant selectors) or a top-level state$ observable.
    • Side-effects: Side-effects (both synchronous and asynchronous) are managed using the effect method, which can consume data both imperatively and reactively.

  2. Overview of @ngrx/signals

    main
    @ngrx/signals is a standalone library providing a reactive state management solution and utilities specifically designed for Angular Signals. It focuses on being lightweight, performant, type-safe, and declarative. The library is built on principles of modularity and extensibility, allowing developers to combine independent building blocks for scalable implementations.

  4. Introduction to @ngrx/effects

    main
    NgRx Effects is an RxJS-powered side effect model for the NgRx Store. It provides a way to isolate side effects (like network requests, web socket messages, or time-based events) from your components. Instead of components interacting directly with services to fetch data, they dispatch actions to the Store, and Effects listen for those actions to perform the necessary asynchronous tasks and dispatch new actions based on the results.

  5. Understand NgRx Data vs NgRx Entity

    main

    The NgRx Data library extends the @ngrx/entity library.

    • NgRx Entity: Provides the core representation of a single entity collection within an NgRx Store using an EntityAdapter for querying and updating cached collections.
    • NgRx Data: A higher-level abstraction that leverages @ngrx/entity (along with @ngrx/store and @ngrx/effects) to provide:
      • A metadata-driven entity model.
      • Automatic actions, reducers, and selectors for all entity types in the model.
      • Asynchronous fetch and save HTTP operations implemented as NgRx Effects.
      • A reactive EntityCollectionService with a simplified API.

    Note that the underlying store, actions, adapters, and entity collections remain visible and directly accessible in NgRx Data.

  6. Understand NgRx Store key concepts

    main

    NgRx Store is an RxJS-powered global state management library for Angular. It uses a unidirectional data flow based on these core concepts:

    • Actions: Unique events dispatched from components or services that describe something happened in the application.
    • Reducers: Pure functions that take the current state and the latest action to compute a new state.
    • Selectors: Pure functions used to select, derive, and compose specific pieces of state.
    • Store: The central service that acts as an observable of the state and an observer of actions.

    Note: All Actions dispatched within an application state are processed by Reducers before being handled by Effects.

  7. Identify different types of application state

    main

    Understanding the different layers of state helps in choosing the correct management tool (e.g., ComponentStore vs. Global Store). The primary types of state are:

    • Server/Backend(s) State: The ultimate source of truth for all data.
    • Persisted State: Snapshots of backend data transferred to and from the application (e.g., JSON responses).
    • URL State: The state of the URL itself, which dictates page navigation and data requirements.
    • Client State: Application state not persisted to the backend (e.g., which tab is currently open).
    • Local UI State: State contained within a single component (e.g., the isEnabled toggle state of a specific component).

  8. Understand State Ownership: Store vs ComponentStore

    main

    The two state management approaches differ fundamentally in how they own and structure data:

    • Global Store: Manages a single immutable object containing all shared application state. The state is divided into multiple slices, each managed by its own reducer.
    • ComponentStore: Each ComponentStore is fully responsible for its own distinct state. You can have many different ComponentStore instances, each managing a specific piece of local state.

  9. Use EntityCollectionService to manage entity collections

    main

    An EntityCollectionService acts as a facade over the NgRx Data dispatcher and selectors. It manages a collection of entities of type T cached in the NgRx store.

    It provides two main capabilities:

    1. Command methods: Used to update the entity collection (either by triggering HTTP requests to a server or updating the cache directly).
    2. Selector observables (selector$): Observables that emit new values whenever a specific part of the cached entity collection changes.

    Note: The @ngrx/data package is in maintenance mode. Changes are limited to critical bug fixes.

  11. Understand EntityChangeTracker in @ngrx/data

    main
    The @ngrx/data package uses an EntityChangeTracker to monitor entity changes that have not yet been synchronized with the server. This mechanism allows the application to preserve "original values" for modified entities, enabling the use of undo actions to revert to the last known server state. This is particularly critical when using optimistic saves.