Files
sfera-new/2025-09-19/USEAUTH_MIGRATION_DEEP_ANALYSIS.md
Veronika Smirnova 24a6ff74b5 feat: migrate from useAuth to AuthContext for centralized auth state
• Полная миграция 64 компонентов с useAuth на AuthContext
• Исправлена race condition в SMS регистрации
• Улучшена SSR совместимость с таймаутами
• Удалена дублирующая система регистрации
• Обновлена документация архитектуры аутентификации

Технические изменения:
- AuthContext.tsx: централизованная система состояния
- auth-flow.tsx: убрана агрессивная логика logout
- confirmation-step.tsx: исправлена передача телефона
- page.tsx: добавлена синхронизация состояния
- 64 файла: миграция useAuth → useAuthContext

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-09-19 17:21:52 +03:00

20 KiB
Raw Blame History

🔍 ГЛУБОКАЯ ДИАГНОСТИКА МИГРАЦИИ useAuth → useAuthContext

Дата: 2025-09-19
Проект: SFERA
Цель: Полная замена 36 оставшихся useAuth на useAuthContext с нулевыми рисками


📊 РЕЗУЛЬТАТЫ ГЛУБОКОЙ ДИАГНОСТИКИ

🎯 ТЕКУЩЕЕ СОСТОЯНИЕ СИСТЕМЫ:

МИГРИРОВАНЫ (22 компонента):

  • auth-flow.tsx, confirmation-step.tsx, auth-guard.tsx
  • layout/app-shell.tsx, seller-statistics/seller-statistics-dashboard.tsx
  • dashboard/* (sidebar, home pages)
  • economics/* (все страницы экономики)

ТРЕБУЮТ МИГРАЦИИ (36 компонентов):

  • Критичные: user-settings, warehouse dashboards, supplies
  • UI компоненты: voice-recorder, file-uploader
  • Вкладки: services, logistics, supplies
  • Формы: создание поставок, заказы

🔬 API COMPATIBILITY АНАЛИЗ:

ПОЛНАЯ СОВМЕСТИМОСТЬ

// useAuth API (старый)         vs    // useAuthContext API (новый)
user: User | null                     user: User | null 
isAuthenticated: boolean              isAuthenticated: boolean
isLoading: boolean                    isLoading: boolean
checkAuth: () => Promise<void>        checkAuth: () => Promise<void>
updateUser: (user) => void            updateUser: (user) => void
logout: () => void                    logout: () => void

REGISTRATION МЕТОДЫ

// Оба контекста имеют идентичные методы:
sendSmsCode(phone: string)
verifySmsCode(phone: string, code: string)
registerFulfillmentOrganization(...)
registerSellerOrganization(...)
registerOrganization(...) // Новый универсальный метод

ТИПЫ ДАННЫХ

// User interface ИДЕНТИЧЕН в обоих файлах
interface User {
  id: string
  phone: string
  organization?: {
    id: string
    type: 'FULFILLMENT' | 'SELLER' | 'LOGIST' | 'WHOLESALE'
    // ... остальные поля идентичны
  }
}

🎯 КРИТИЧНЫЕ РАЗЛИЧИЯ (ВЫЯВЛЕНЫ):

1. ЛОГИКА ИНИЦИАЛИЗАЦИИ:

// useAuth: isLoading = false (по умолчанию)
const [isLoading, setIsLoading] = useState(false)

// useAuthContext: isLoading = true (начальная загрузка)  
const [isLoading, setIsLoading] = useState(true)

ВЛИЯНИЕ: Компоненты могут мерцать при загрузке

2. LOGOUT ПОВЕДЕНИЕ:

// useAuth: прямой redirect
if (typeof window !== 'undefined') {
  window.location.href = '/'
}

// useAuthContext: асинхронный redirect (исправлен для SSR)
setTimeout(() => {
  if (typeof window !== 'undefined') {
    window.location.href = '/'
  }
}, 0)

ВЛИЯНИЕ: Улучшение - нет SSR проблем

3. СОСТОЯНИЕ ИНИЦИАЛИЗАЦИИ:

// useAuth: НЕТ флага isInitialized
// useAuthContext: ЕСТЬ флаг isInitialized для отслеживания первой загрузки
const [isInitialized, setIsInitialized] = useState(false)

ВЛИЯНИЕ: Более стабильная инициализация


🔥 АНАЛИЗ КОМПОНЕНТОВ ПО РИСКАМ

🔴 ВЫСОКИЙ РИСК (5 компонентов):

1. dashboard/user-settings.tsx

  • Риск: Основные настройки пользователя
  • Используемые методы: user, updateUser
  • Потенциальные проблемы: Сохранение настроек профиля
  • Тест план: Проверить сохранение всех настроек

2. wb-warehouse/wb-warehouse-dashboard.tsx

  • Риск: Критичный дашборд склада WB
  • Используемые методы: user (для organizationId)
  • Потенциальные проблемы: Фильтрация данных склада
  • Тест план: Проверить загрузку данных склада

3. fulfillment-warehouse/fulfillment-warehouse-dashboard/index.tsx

  • Риск: Основной дашборд фулфилмента
  • Используемые методы: user (переменная _user)
  • Потенциальные проблемы: Права доступа к складу
  • Тест план: Проверить весь workflow склада

4. supplies/supplies-dashboard.tsx

  • Риск: Центральный дашборд поставок
  • Используемые методы: user
  • Потенциальные проблемы: Отображение поставок по организации
  • Тест план: Проверить все вкладки поставок

5. messenger/messenger-chat.tsx

  • Риск: Система сообщений
  • Используемые методы: user (для отправителя)
  • Потенциальные проблемы: Права отправки сообщений
  • Тест план: Отправить/получить сообщения

🟡 СРЕДНИЙ РИСК (10 компонентов):

Services группа (3 компонента):

  • services/services-tab.tsx
  • services/supplies-tab.tsx
  • services/logistics-tab.tsx
  • Риск: Вкладки услуг в кабинете
  • Методы: user
  • Проблемы: Фильтрация услуг по типу организации

Fulfillment supplies группа (4 компонента):

  • fulfillment-supplies/fulfillment-supplies/fulfillment-goods-orders-tab.tsx
  • fulfillment-supplies/fulfillment-supplies/seller-materials-tab.tsx
  • fulfillment-supplies/fulfillment-supplies/pvz-returns-tab.tsx
  • fulfillment-supplies/fulfillment-supplies/fulfillment-consumables-orders-tab.tsx
  • Риск: Вкладки управления поставками
  • Методы: user
  • Проблемы: Доступ к заказам и материалам

Прочие (3 компонента):

  • seller-statistics/simple-advertising-table.tsx - таблица рекламы
  • logistics-orders/logistics-orders-dashboard.tsx - заказы логистики
  • supplier-orders/supplier-orders-tabs-v2.tsx - заказы поставщика

🟢 НИЗКИЙ РИСК (21 компонент):

UI компоненты (2):

  • ui/voice-recorder.tsx, ui/file-uploader.tsx
  • Риск: Минимальный, только для получения userId
  • Методы: user (только для метаданных)

Создание поставок группа (6):

  • fulfillment-supplies/create-fulfillment-consumables-supply-v2.tsx
  • supplies/fulfillment-supplies/* различные вкладки
  • Риск: Низкий, преимущественно отображение

Hooks и утилиты (13):

  • Различные хуки и вспомогательные компоненты
  • Риск: Минимальный, простое использование user

🛡️ БЕЗОПАСНЫЙ ПЛАН МИГРАЦИИ

ФАЗА 1: ПОДГОТОВКА И ВАЛИДАЦИЯ (30 мин)

1.1 Создание тестового окружения

# Создать branch для миграции
git checkout -b feature/useauth-migration

# Создать backup критичных файлов
cp src/components/dashboard/user-settings.tsx src/components/dashboard/user-settings.tsx.pre-migration
cp src/components/wb-warehouse/wb-warehouse-dashboard.tsx src/components/wb-warehouse/wb-warehouse-dashboard.tsx.pre-migration
cp src/components/fulfillment-warehouse/fulfillment-warehouse-dashboard/index.tsx src/components/fulfillment-warehouse/fulfillment-warehouse-dashboard/index.tsx.pre-migration
cp src/components/supplies/supplies-dashboard.tsx src/components/supplies/supplies-dashboard.tsx.pre-migration
cp src/components/messenger/messenger-chat.tsx src/components/messenger/messenger-chat.tsx.pre-migration

1.2 Валидация API совместимости

  • Проверить что все методы useAuth есть в useAuthContext
  • Убедиться что типы User идентичны
  • Проверить что нет breaking changes в поведении

1.3 Создание rollback скрипта

#!/bin/bash
# rollback-migration.sh
echo "Rolling back useAuth migration..."
git checkout HEAD~1 -- src/components/dashboard/user-settings.tsx
git checkout HEAD~1 -- src/components/wb-warehouse/wb-warehouse-dashboard.tsx
# ... для всех критичных файлов
echo "Rollback complete"

ФАЗА 2: МИГРАЦИЯ КРИТИЧНЫХ КОМПОНЕНТОВ (60 мин)

2.1 Пилотная миграция: UI компоненты (10 мин)

// ПРОСТАЯ ЗАМЕНА:
// ❌ import { useAuth } from '@/hooks/useAuth'
// ✅ import { useAuthContext } from '@/contexts/AuthContext'

// ❌ const { user } = useAuth()
// ✅ const { user } = useAuthContext()

Компоненты для пилота:

  • ui/voice-recorder.tsx (2 строки)
  • ui/file-uploader.tsx (2 строки)

Тестирование: Загрузка файлов и запись голоса

2.2 Критичные компоненты по одному (10 мин каждый)

Порядок миграции:

  1. dashboard/user-settings.tsx
  2. wb-warehouse/wb-warehouse-dashboard.tsx
  3. fulfillment-warehouse/fulfillment-warehouse-dashboard/index.tsx
  4. supplies/supplies-dashboard.tsx
  5. messenger/messenger-chat.tsx

Для каждого компонента:

# 1. Сделать копию
cp component.tsx component.tsx.backup

# 2. Выполнить миграцию
sed -i 's/import { useAuth } from '\''@\/hooks\/useAuth'\''/import { useAuthContext } from '\''@\/contexts\/AuthContext'\''/g' component.tsx
sed -i 's/useAuth(/useAuthContext(/g' component.tsx

# 3. Тестировать функциональность
npm run dev
# Проверить в браузере

# 4. Если ошибка - откатить
cp component.tsx.backup component.tsx

ФАЗА 3: ПАКЕТНАЯ МИГРАЦИЯ СРЕДНИХ (30 мин)

3.1 Services группа (10 мин)

# Одновременная миграция всех services
find src/components/services -name "*.tsx" -exec sed -i 's/import { useAuth } from '\''@\/hooks\/useAuth'\''/import { useAuthContext } from '\''@\/contexts\/AuthContext'\''/g' {} \;
find src/components/services -name "*.tsx" -exec sed -i 's/useAuth(/useAuthContext(/g' {} \;

3.2 Fulfillment supplies группа (10 мин)

# Миграция вкладок fulfillment supplies
find src/components/fulfillment-supplies -name "*-tab.tsx" -exec sed -i 's/import { useAuth } from '\''@\/hooks\/useAuth'\''/import { useAuthContext } from '\''@\/contexts\/AuthContext'\''/g' {} \;
find src/components/fulfillment-supplies -name "*-tab.tsx" -exec sed -i 's/useAuth(/useAuthContext(/g' {} \;

3.3 Прочие средние (10 мин)

# Миграция остальных средних компонентов
for file in "seller-statistics/simple-advertising-table.tsx" "logistics-orders/logistics-orders-dashboard.tsx" "supplier-orders/supplier-orders-tabs-v2.tsx"; do
  sed -i 's/import { useAuth } from '\''@\/hooks\/useAuth'\''/import { useAuthContext } from '\''@\/contexts\/AuthContext'\''/g' "src/components/$file"
  sed -i 's/useAuth(/useAuthContext(/g' "src/components/$file"
done

ФАЗА 4: МАССОВАЯ МИГРАЦИЯ НИЗКИХ (15 мин)

4.1 Автоматизированная замена

# Найти ВСЕ оставшиеся файлы с useAuth
remaining_files=$(grep -r "import.*useAuth.*from.*@/hooks/useAuth" src/components --exclude="*.backup" -l)

# Применить замену ко всем найденным
for file in $remaining_files; do
  echo "Migrating: $file"
  sed -i 's/import { useAuth } from '\''@\/hooks\/useAuth'\''/import { useAuthContext } from '\''@\/contexts\/AuthContext'\''/g' "$file"
  sed -i 's/useAuth(/useAuthContext(/g' "$file"
done

4.2 Валидация результата

# Проверка что не осталось useAuth импортов (кроме backup)
remaining=$(grep -r "import.*useAuth.*from.*@/hooks/useAuth" src/components --exclude="*.backup" | wc -l)
if [ $remaining -eq 0 ]; then
  echo "✅ Migration complete - no useAuth imports remaining"
else
  echo "❌ Migration incomplete - $remaining files still use useAuth"
fi

ФАЗА 5: ОЧИСТКА И ВАЛИДАЦИЯ (15 мин)

5.1 Удаление старого useAuth hook

# ТОЛЬКО после успешного тестирования всех компонентов
mv src/hooks/useAuth.ts src/hooks/useAuth.ts.deprecated

5.2 Финальная проверка сборки

npm run build
npm run typecheck  
npm run lint

5.3 Создание отчета миграции

echo "🎉 USEAUTH MIGRATION COMPLETE" > migration-report.txt
echo "Date: $(date)" >> migration-report.txt
echo "Files migrated: $(git diff --name-only | wc -l)" >> migration-report.txt
echo "Build status: $(npm run build > /dev/null 2>&1 && echo '✅ SUCCESS' || echo '❌ FAILED')" >> migration-report.txt

🧪 ДЕТАЛЬНЫЙ ПЛАН ТЕСТИРОВАНИЯ

КРИТИЧНЫЕ ТЕСТЫ (после каждого компонента):

1. user-settings.tsx

// Тест кейсы:
- Открыть настройки профиля 
- Изменить имя пользователя   
- Сохранить настройки 
- Загрузить аватар 
- Изменить настройки организации 
- Сохранить API ключи 

2. wb-warehouse-dashboard.tsx

// Тест кейсы:
- Открыть дашборд склада 
- Загрузить данные товаров 
- Фильтрация по статусу 
- Экспорт данных 
- Создать новую поставку 

3. fulfillment-warehouse-dashboard/index.tsx

// Тест кейсы:
- Открыть дашборд фулфилмента 
- Просмотр статистики склада 
- Управление остатками 
- Создание заявок 
- Отчеты по складу 

4. supplies-dashboard.tsx

// Тест кейсы:
- Открыть дашборд поставок 
- Просмотр всех поставок 
- Создание новой поставки 
- Статусы поставок 
- Фильтрация по датам 

5. messenger-chat.tsx

// Тест кейсы:
- Открыть чат 
- Отправить текстовое сообщение 
- Отправить файл 
- Получить сообщение 
- История сообщений 

ПАКЕТНЫЕ ТЕСТЫ (после групп):

Services группа:

  • Открыть все вкладки услуг ✓
  • Проверить фильтрацию по типу организации ✓
  • Создать заказ услуги ✓

Fulfillment supplies группа:

  • Открыть все вкладки поставок ✓
  • Создать заказ материалов ✓
  • Просмотр возвратов ПВЗ ✓

⚠️ КРИТИЧЕСКИЕ МОМЕНТЫ И ROLLBACK

🚨 СТОП-СИГНАЛЫ:

  • Ошибки компиляции TypeScript
  • 500 ошибки в GraphQL запросах
  • Пустые дашборды (не загружаются данные)
  • Ошибки авторизации
  • Проблемы с сохранением настроек

🔄 ROLLBACK ПРОЦЕДУРЫ:

Быстрый rollback одного компонента:

cp component.tsx.backup component.tsx
npm run dev

Полный rollback всей миграции:

git checkout HEAD~1 src/components/
npm run dev

Частичный rollback группы:

git checkout HEAD~1 src/components/services/
npm run dev

📊 КРИТЕРИИ УСПЕХА

ФУНКЦИОНАЛЬНЫЕ:

  • Все дашборды загружаются корректно
  • Сохранение настроек работает
  • Фильтрация данных по организации работает
  • Создание поставок/заказов работает
  • Система сообщений работает

ТЕХНИЧЕСКИЕ:

  • 0 ошибок TypeScript
  • npm run build проходит успешно
  • npm run lint без предупреждений
  • Нет 500 ошибок в браузере
  • Нет console.error в production

ПРОИЗВОДИТЕЛЬНОСТЬ:

  • Время загрузки дашбордов ≤ прежнего
  • Нет memory leaks
  • Инициализация AuthContext ≤ 500ms

🎯 ПРЕДПОЛАГАЕМЫЕ РЕЗУЛЬТАТЫ

ПОСЛЕ МИГРАЦИИ:

  • Единая система авторизации - все компоненты используют AuthContext
  • Устранение race conditions - синхронизированное состояние
  • Упрощение архитектуры - один источник истины
  • Улучшение производительности - меньше дублирования состояния
  • Легкость поддержки - одно место для изменений авторизации

ТЕХНИЧЕСКАЯ ЧИСТОТА:

  • 📦 useAuth.ts удален (переименован в deprecated)
  • 🧹 Нет дублирования логики авторизации
  • 🔧 Упрощенное тестирование
  • 📚 Чистый код без legacy зависимостей

🚀 ГОТОВНОСТЬ К РЕАЛИЗАЦИИ

ПЛАН ДЕТАЛИЗИРОВАН:

  • Пошаговые инструкции для каждой фазы
  • Четкие критерии успеха для каждого этапа
  • Rollback планы для каждого уровня
  • Детальные тест-кейсы

РИСКИ МИНИМИЗИРОВАНЫ:

  • Пилотная миграция простых компонентов
  • Поэтапная миграция по уровням риска
  • Backup файлы для критичных компонентов
  • Автоматизированные rollback скрипты

ТЕСТИРОВАНИЕ ПОКРЫТО:

  • Функциональные тесты для каждого компонента
  • Пакетные тесты для групп
  • Критерии стоп-сигналов
  • Performance benchmarks

РЕКОМЕНДАЦИЯ: Начинать миграцию с ФАЗЫ 1 в рабочее время при доступности для немедленного rollback в случае проблем.

ВРЕМЯ ВЫПОЛНЕНИЯ: 2.5 часа (с учетом тестирования) РИСК УРОВЕНЬ: НИЗКИЙ (при соблюдении плана) ГОТОВНОСТЬ: 🟢 ГОТОВ К ВЫПОЛНЕНИЮ


Документ создан: 2025-09-19
Проект: SFERA Marketplace Platform
Статус: Готов к реализации