React: global state, context providers and app services separation

[stalniy]

Summary

This document proposes a strategy for how we use React Providers, Jotai, React Query, and Services in the Console frontend projects.
The goal is to reduce unnecessary re-renders, and establish clear boundaries for application-wide state, remote data, and services.

Motivation

Right now we have 22 providers wrapping the deploy-web app.
Each provider is a potential trigger for re-rendering the entire application whenever its state changes.
This creates unnecessary overhead, makes reasoning about state harder, makes unit testing harder, and increases the risk of performance issues.

We need a clear convention for:

• When to use React Context Providers
• How to store global state efficiently
• How to handle server data fetching
• How to organize app services in testable way

Proposal

1. Use React Providers only for static values

• ✅ Good for: configuration, services, themes, or values that rarely change
• ❌ Avoid using for frequently updated state (e.g., UI state, counters)
• Reason: a change in a provider value triggers a re-render of the entire subtree

Examples:

• Application theme (ThemeProvider)
• Services container (ServicesProvider)
• App configuration loaded at startup

2. Use Jotai for application-wide state

• Use a single Jotai store to hold shared state across the app.
• Each atom represents a piece of state.
• Components subscribe only to the atoms they use.

✅ Benefit: Unlike React Context, updating one atom does not re-render the entire app — only components using that atom are updated. This also gives us a possibility to serialize jotai store and store in localStorage

Examples:

• blockchain node api url
• Global UI state (sidebar open/closed, modals)
• Cross-component state (payments state, user related state, selected bid, selected deployment, etc.)

3. Use React Query for remote data

• Fetch all server/stateful data through React Query.
• This gives us:
  • Built-in caching
  • Background refetching
  • Automatic state synchronization with the server

Examples:

• Deployments list
• Provider list
• Blockchain related data

4. Extract service logic into services

• All complex domain logic (e.g., interacting with APIs, blockchain, Akash SDKs) should be implemented as application services.
• Services are then provided through a single ServicesProvider.

This keeps our architecture clean:

• React Providers → for static service injection
• Services → contain logic and APIs
• State management (Jotai + React Query) → drives the UI