Как хранить данные в React глобально?

Способы глобального хранения данных в React

Глобальное хранение данных в React-приложениях — это фундаментальная задача, требующая выбора подходящего инструмента в зависимости от масштаба, сложности и требований проекта. Вот основные подходы, которые я использую на практике.

1. Context API (Встроенное решение React)

Стандартный React-инструмент для передачи данных через дерево компонентов без явной передачи пропсов. Идеально подходит для средних и небольших приложений, где состояние не слишком часто меняется.

// Создание контекста
import React, { createContext, useState, useContext } from 'react';

const GlobalStateContext = createContext();

export const GlobalProvider = ({ children }) => {
  const [user, setUser] = useState(null);
  const [theme, setTheme] = useState('light');

  const value = {
    user,
    setUser,
    theme,
    setTheme,
  };

  return (
    <GlobalStateContext.Provider value={value}>
      {children}
    </GlobalStateContext.Provider>
  );
};

// Хук для использования контекста
export const useGlobalState = () => {
  const context = useContext(GlobalStateContext);
  if (!context) {
    throw new Error('useGlobalState must be used within GlobalProvider');
  }
  return context;
};

Преимущества:

• Встроен в React, не требует дополнительных зависимостей
• Простая интеграция с функциональными компонентами через хуки
• Хорошо подходит для темизации, аутентификации, локализации

Ограничения:

• Неоптимален для часто изменяющихся данных (перерисовывает всех потребителей)
• Отсутствует встроенная система Middleware или DevTools

2. Сторонние менеджеры состояния (Redux, MobX, Zustand)

Для сложных приложений с интенсивным взаимодействием данных я предпочитаю специализированные библиотеки.

Redux Toolkit (современный подход к Redux)

// store.js
import { configureStore, createSlice } from '@reduxjs/toolkit';

const userSlice = createSlice({
  name: 'user',
  initialState: null,
  reducers: {
    setUser: (state, action) => action.payload,
    clearUser: () => null,
  },
});

const store = configureStore({
  reducer: {
    user: userSlice.reducer,
  },
});

// Компонент с подключением
import { useSelector, useDispatch } from 'react-redux';

const UserProfile = () => {
  const user = useSelector((state) => state.user);
  const dispatch = useDispatch();
  
  return <div>{user?.name}</div>;
};

Плюсы Redux:

• Предсказуемость состояния благодаря однонаправленному потоку данных
• Богатая экосистема (Middleware, DevTools, персистентность)
• Отлично масштабируется для enterprise-приложений

Zustand (легковесная альтернатива)

import create from 'zustand';

const useStore = create((set) => ({
  bears: 0,
  increasePopulation: () => set((state) => ({ bears: state.bears + 1 })),
  removeAllBears: () => set({ bears: 0 }),
}));

// Использование в компоненте
function BearCounter() {
  const bears = useStore((state) => state.bears);
  return <h1>{bears} bears around</h1>;
}

3. Серверное состояние (React Query, SWR, Apollo Client)

Для данных, которые приходят с бэкенда, я отделяю клиентское состояние от серверного состояния.

// React Query пример
import { useQuery, useMutation, QueryClient } from 'react-query';

const queryClient = new QueryClient();

function UsersList() {
  const { data, isLoading, error } = useQuery('users', fetchUsers);
  
  const mutation = useMutation(updateUser, {
    onSuccess: () => {
      queryClient.invalidateQueries('users'); // Автоматическая инвалидация
    },
  });
}

Ключевые преимущества:

• Автоматическое кэширование и инвалидация
• Фоновое обновление данных
• Оптимистичные обновления
• Пагинация и бесконечная подгрузка "из коробки"

4. Локальное хранилище браузера (LocalStorage, SessionStorage, IndexedDB)

Для персистентности данных между сессиями:

// Кастомный хук для LocalStorage
import { useState, useEffect } from 'react';

function useLocalStorage(key, initialValue) {
  const [storedValue, setStoredValue] = useState(() => {
    try {
      const item = window.localStorage.getItem(key);
      return item ? JSON.parse(item) : initialValue;
    } catch (error) {
      console.error(error);
      return initialValue;
    }
  });

  const setValue = (value) => {
    try {
      const valueToStore = value instanceof Function ? value(storedValue) : value;
      setStoredValue(valueToStore);
      window.localStorage.setItem(key, JSON.stringify(valueToStore));
    } catch (error) {
      console.error(error);
    }
  };

  return [storedValue, setValue];
}

Критерии выбора подхода

В своей практике я руководствуюсь следующими принципами:

1. Масштаб приложения:

   • Малое: Context API + локальное состояние
   • Среднее: Zustand или Redux Toolkit
   • Крупное: Redux Toolkit + React Query

2. Тип данных:

   • UI-состояние (модалки, темы): Context API или Zustand
   • Бизнес-логика: Redux Toolkit
   • Серверные данные: React Query/SWR/Apollo

3. Требования к производительности:

   • Для минимизации ререндеров: Zustand, Recoil, или MobX
   • Для строгой предсказуемости: Redux

4. Командные факторы:

   • Опыт команды с конкретной библиотекой
   • Требования к поддержке и долгосрочности проекта

Мои рекомендации по архитектуре

В современных проектах я часто комбинирую несколько подходов:

• React Query для всех асинхронных данных с бэкенда
• Zustand для клиентского UI-состояния
• Context API для статических значений (тема, язык, feature flags)
• LocalStorage middleware для персистентности критичных данных

Пример комбинированного подхода:

// Архитектурный пример
const App = () => {
  return (
    <QueryClientProvider client={queryClient}>
      <ReduxProvider store={store}>
        <ThemeProvider>
          <AuthProvider>
            <AppLayout />
          </AuthProvider>
        </ThemeProvider>
      </ReduxProvider>
    </QueryClientProvider>
  );
};

Важное замечание: Не стоит стремиться к глобальному хранению всех данных. Локальное состояние (useState, useReducer) остается предпочтительным для изолированной логики компонентов. Глобальное состояние следует использовать только для данных, которые действительно нужны в нескольких несвязанных частях приложения.

Выбор конкретного решения всегда зависит от проекта, но понимание всех доступных опций позволяет принимать архитектурные решения, которые масштабируются вместе с приложением и обеспечивают оптимальную производительность и поддерживаемость кода.