Skip to the content.

The State Side

State Management and Operations

Learn the Basics

Approach

Folder Structure

The State is UI and JS Framework agnostic i.e. It allows any framework like React/Bootstap/Vue/Angular to bind with it. All the implementation is purely in JavaScript or TypeScript making it easy to evolve the business to keep its models regardless of the evolution of UI.

.
└── state/
    └── item/
        ├── item.initial.js
        ├── item.type.js
        ├── item.reducer.js
        ├── item.selectors.js
        ├── item.operations.js
        └── item.helper.js

Non-asynchronous activities do not require an operations file and purely work with actions and reducers.

This folder is dedicated to managing the state logic for the item feature. It contains files that separate concerns, making the codebase more maintainable and scalable.

  1. item.initial.js:
    • Contains the initial state for the item feature.
    • This is used as the default value when the reducer initializes its state.
  2. item.type.js:
    • Defines action types as constants (e.g., ADD_ITEM, REMOVE_ITEM).
    • Helps avoid hardcoding strings and ensures consistency across actions and reducers.
  3. item.reducer.js:
    • Implements the reducer function for the item feature.
    • Responsible for updating the state based on dispatched actions using pure functions.
  4. item.selectors.js:
    • Contains selector functions to extract specific pieces of data from the Redux store.
    • Encapsulates state structure, making it easier to refactor or derive computed values efficiently.
  5. item.operations.js:
    • Includes asynchronous operations or complex business logic, such as API calls.
    • Often used with middleware like redux-thunk or redux-saga to handle side effects.
  6. item.helper.js:
    • Contains utility functions or helper methods specific to the item feature.
    • These functions support reusable logic that doesn’t directly interact with Redux but aids in computations or transformations.

Advantages of This Structure

This structure is commonly used in large applications to ensure separation of concerns and maintain a clean codebase.

Architecture

server system diagram

Key Components

  1. Selectors:
    • Functions used to extract specific pieces of data from the store.
    • They interact with the store to retrieve data for use in the application.
  2. Actions:
    • Represent events or intentions in the application (e.g., user interactions).
    • Actions are dispatched to trigger changes in the application’s state.
  3. Action Types:
    • Define unique identifiers for actions (e.g., ADD_ITEM, REMOVE_ITEM).
    • These are used by reducers to determine what kind of state update is required.
  4. Reducer/Controller:
    • Pure functions that take the current state and an action, then return a new state.
    • Responsible for updating the store based on dispatched actions.
  5. Store:
    • A centralized location where the entire application state is maintained.
    • Acts as a single source of truth for the app’s data.
  6. Middleware:
    • Functions that sit between actions being dispatched and reducers processing them.
    • Used for handling side effects like asynchronous operations, logging, analytics, etc.
  7. State Provider:
    • A wrapper component that provides access to the store throughout the application.
    • Ensures components can connect to and interact with the store.
  8. Async Operations:
    • Handles asynchronous tasks such as API calls or database queries.
    • Often managed through middleware like redux-thunk or redux-saga.
  9. Personalization:
    • Middleware or logic responsible for tailoring app behavior or content based on user preferences or context.
  10. Analytics:
    • Middleware that tracks user interactions and sends data to analytics platforms.
  11. Localization:
    • Middleware or logic that adapts content based on language or region settings.
  12. AJAX Client:
    • Facilitates communication with external APIs or servers for fetching or sending data.

Workflow

  1. Actions are dispatched by components or logic in response to user interactions or events.
  2. Middleware intercepts these actions to handle side effects (e.g., async tasks, logging).
  3. The reducer processes the action and updates the store with new state.
  4. Selectors retrieve updated state from the store for use in components.
  5. The State Provider ensures all components have access to the store’s data.

This architecture promotes predictable state management, scalability, and separation of concerns in frontend applications.