Регистрация на React и работа с API

Для добавленной в прошлый раз страницы спрограммируем полноценную форму регистрации и страницу подтверждения. Добавим вывод общих доменных ошибок и персональных ошибок валидации для полей. Отрефакторим код и вынесем клиент для работы с API. Сделаем проксирование запросов с фронтенда на бэкенд. Вынесем компоненты для элементов формы. Для всего напишем много кода и тестов:

  • 00:01:32 - Вёрстка формы регистрации
  • 00:05:09 - E2E-тесты регистрации
  • 00:10:30 - Фикстуры с занятым email
  • 00:13:32 - Состояние для полей формы
  • 00:14:50 - Универсальный обработчик onChange
  • 00:17:48 - Отправка формы в API
  • 00:19:06 - Добавление CORS-заголовков
  • 00:20:59 - Проксирование запросов в API через Nginx
  • 00:25:57 - Обработка результатов запроса
  • 00:27:12 - Отлов ошибок подключения
  • 00:28:54 - Отображение успеха
  • 00:30:21 - Отображение доменных ошибок
  • 00:32:08 - Вывод ошибок валидации из API
  • 00:34:40 - Универсальный обработчик
  • 00:36:19 - Определение JSON формата ответа
  • 00:37:17 - Отклонение ошибочных ответов в catch
  • 00:41:36 - Юнит тест для React-компонента
  • 00:48:07 - Формат Accept для возврата
  • 00:50:15 - Рефакторинг компонента
  • 00:51:01 - Получение JSON-данных ответа
  • 00:53:13 - Компонент работы с API
  • 00:55:11 - Mock компонента в тестах
  • 00:58:18 - Автоподстановка Content-Type
  • 01:00:09 - Unit-тесты для api
  • 01:04:50 - Вынос парсеров ошибок
  • 01:08:01 - Рефакторинг проверки формата
  • 01:09:54 - Защита от повторной отправки
  • 01:13:12 - Вынос Alert-блоков
  • 01:14:23 - Элементы формы
  • 01:16:25 - Страница подтверждения регистрации
  • 01:20:40 - Unit-тест подтверждения
  • 01:24:16 - Редирект на страницу успеха
  • 01:26:55 - Включение Feature Toggle
  • 01:27:49 - Обзор результата

И в следующих эпизодах займёмся аутентификацией по токенам.

Скрытый контент
Комментарии (10)
Руслан

Спасибо, очень круто, как всегда!

Ответить
Arunas

Спасибо.

Ответить
Yevhenii Lykholai

Спасибо. Понравилось.

Ответить
ХОРХОЙ

Прошу по возможности уделить время в будущих уроках рассмотрению Server Side Rendering для React. Хотя бы в минимальном объеме, так как тема очень актуальная и востребованная.

Ответить
Руслан

Только не в ущерб общему прогрессу, уж очень важные темы впереди, хочется добраться до бизнес слоя не сбивая темп.

Ответить
Максим

Поддерживаю) Тема бизнес логики давно уже уходит всё дальше и дальше. Сейчас уже она близко и многие её ждут. А SSR тему можно рассмотреть и не в исполнении Дмитрием, при этом это можно это сделать чуть позже)

Ответить
Руслан

Дмитрий, добрый день,

в последнее время все чаще сталкиваюсь с запросами по обеспечению приватности пользовательских данных: General Data Protection Rules (GDPR), Cookie Consent Trial Request (CCPA), Health Insurance Portability and Accountability Act (HIPAA) и др.

Можете поделиться рекомендациями/опытом касательно как избежать возможных проблем совместимости с данным требованиями на этапе построения архитектуры приложения (особенно Message Driven) и/или на других этапах разработки?

Спасибо.

Ответить
Дмитрий Елисеев

Главная рекомендация - не хранить идентифицирующие данные в открытом виде в вечных неизменных хранилищах вроде Kafka или ClickHouse, если такие имеются. Чтобы потом при необходимости можно было их удалить или подменить на фейки.

Если такие хранилища есть, то первый вариант - записывать чувствительные данные в отдельную таблицу в БД, а в вечные хранилища передавать идентификатор этой записи. Тогда для удаления данных просто удаляем запись из этой вспомогательной таблицы.

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

Ответить
Руслан

Спасибо огромное!

Ответить
fedot

Спасибо!

Ответить
Зарегистрируйтесь или войдите чтобы оставить комментарий

Или войти через:

Google
GitHub
Yandex
MailRu