Регистрация на 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 - Обзор результата

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

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

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

Ответить
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

Спасибо!

Ответить
slo_nik

Добрый вечер, Дмитрий.

А как, всё-таки, передать адрес api через env переменную на frontend?

Пробовал в Dockerfile установить переменную, но ничего не получилось.

FROM node:16-alpine as builder

WORKDIR /app

COPY ./package.json ./yarn.lock ./
RUN yarn install

COPY ./ ./

ENV REACT_APP_WEBSITE_URL $REACT_APP_WEBSITE_URL

RUN yarn build

FROM nginx:1.21-alpine

COPY ./docker/production/nginx/conf.d /etc/nginx/conf.d

WORKDIR /app

COPY --from=builder ./app/build ./public

Ошибок при сборке нет, но REACT_APP_WEBSITE_URL пустая на frontend-e.

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

Эти ENV в Dockerfile срабатывают в момент сборки образа через docker build, а не в момент запуска. Потому они там и пустые.

Для этого обычно при сборке подставляют туда значения-заглушки:

ENV REACT_APP_WEBSITE_URL=%REACT_APP_WEBSITE_URL%

И потом уже при запуске в скрипте docker-entrypoint.sh во всех файлах проекта подменяют заглушку %REACT_APP_WEBSITE_URL% на реальные значения переменных командой sed.

Мы так сделаем когда будем подставлять OAUTH_URL в эпизоде про аутентификацию на фронтенде.

Ответить
slo_nik

Я уже это понял, что просто так не работает, как с обычными образами.

Видел решения с использованием sh файла для установки env переменной, но подумал, что может есть простое решение.

Ответить
slo_nik

Значит для тестового сервера писать жёстко адреса?

Ответить
slo_nik

Ваше решение подразумевает, что env переменная будет браться тоже из Jenkins, а не из .env файла?

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

При запуске будет браться как и на бэкенде из обычных environment в docker-compose.yml и в docker-entrypoint.sh поставляться в файлы через sed.

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

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

Google
GitHub
Yandex
MailRu