Для добавленной в прошлый раз страницы спрограммируем полноценную форму регистрации и страницу подтверждения. Добавим вывод общих доменных ошибок и персональных ошибок валидации для полей. Отрефакторим код и вынесем клиент для работы с 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 Обзор результата
И в следующих эпизодах займёмся аутентификацией по токенам.
Скрытый контент (код, слайды, ...) для подписчиков.
Открыть →Чтобы не пропускать новые эпизоды подпишитесь на наш канал @deworkerpro в Telegram
Спасибо, очень круто, как всегда!
Спасибо.
Спасибо. Понравилось.
Прошу по возможности уделить время в будущих уроках рассмотрению 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, если такие имеются. Чтобы потом при необходимости можно было их удалить или подменить на фейки.
Если такие хранилища есть, то первый вариант - записывать чувствительные данные в отдельную таблицу в БД, а в вечные хранилища передавать идентификатор этой записи. Тогда для удаления данных просто удаляем запись из этой вспомогательной таблицы.
Второй вариант - в сообщения передавать данные, зашифрованные рандомным ключом, который хранится в таблице пользователя. И им же расшифровывать на принимающей стороне. Тогда по запросу от пользователя просто удаляем его ключ и все зашифрованные строки становятся невосстановимыми.
Спасибо огромное!
Спасибо!
Добрый вечер, Дмитрий.
А как, всё-таки, передать адрес api через env переменную на frontend?
Пробовал в Dockerfile установить переменную, но ничего не получилось.
Ошибок при сборке нет, но REACT_APP_WEBSITE_URL пустая на frontend-e.
Эти
ENV
в Dockerfile срабатывают в момент сборки образа через docker build, а не в момент запуска. Потому они там и пустые.Для этого обычно при сборке подставляют туда значения-заглушки:
И потом уже при запуске в скрипте
docker-entrypoint.sh
во всех файлах проекта подменяют заглушку%REACT_APP_WEBSITE_URL%
на реальные значения переменных командойsed
.Мы так сделаем когда будем подставлять
OAUTH_URL
в эпизоде про аутентификацию на фронтенде.Я уже это понял, что просто так не работает, как с обычными образами.
Видел решения с использованием sh файла для установки env переменной, но подумал, что может есть простое решение.
Значит для тестового сервера писать жёстко адреса?
Ваше решение подразумевает, что env переменная будет браться тоже из Jenkins, а не из .env файла?
При запуске будет браться как и на бэкенде из обычных
environment
вdocker-compose.yml
и вdocker-entrypoint.sh
поставляться в файлы черезsed
.Всем привет! Подскажите плз, не пойму, тест "confirms without token" не проходит, падает с ошибкой Uncaught [TypeError: Cannot read properties of undefined (reading 'pathname')] Хотя вроде все так, как должно быть
upd: А все, разобрался, нужно не Redirect использовать, а Navigate
Или войти через: