После типизации наших E2E-тестов пора перейти к пошаговому добавлению типизации фронтенда, учитывая разные нюансы. Как раз этим займёмся в сегодняшнем мегаскринкасте про внедрение TypeScript в проект на ReactJS.
Помимо всех страниц проставим типы компоненту FeatureToggle и полностью типизируем AuthProvider. Проверим, сколько недочётов было в нашем коде.
Заодно напишем фейковый провайдер аутентификации для оборачивания им других компонентах в тестах:
- 00:00:24 Способы добавления типизации
- 00:01:50 Удаление лишнего кода
- 00:02:14 Изменение длины строки
- 00:03:38 Создание нового проекта
- 00:04:16 Пользователь node в Docker
- 00:07:23 Исследование нового проекта
- 00:10:19 Установка TypeScript в React
- 00:10:59 Файл index
- 00:13:45 Подержка TypeScript в ESLint
- 00:15:42 Типизация для features
- 00:17:30 Модули в tsconfig
- 00:18:45 Типы для FeatureToggle
- 00:19:11 Типы для Context
- 00:20:36 Функциональные компоненты и JSX Element
- 00:22:21 Составные типы
- 00:26:15 Рефакторинг через пользовательские типы
- 00:28:29 Проверка оригиналов вместо псевдонимов
- 00:29:49 Утиная типизация
- 00:30:40 Экспорт пользовательских типов
- 00:33:31 Типизация для props
- 00:39:01 Компонент Alert
- 00:40:50 Доработка Layout
- 00:41:08 Компонент Form
- 00:43:59 Страница Not Found
- 00:44:30 Компонент App и недочёт с Router
- 00:46:19 Типизация API-клиента
- 00:49:31 Стабы и моки Response
- 00:51:55 Error или Response
- 00:54:40 JSON в тестовых Response
- 00:57:02 Страница и форма регистрации
- 00:57:28 Дженерики для useState
- 00:58:59 События формы и полей
- 01:01:53 Компонент OAuth2
- 01:05:18 Целевая версия ECMAScript
- 01:06:40 Недочёт с Code Verifier
- 01:07:39 Описание ответа с токенами
- 01:10:11 Пустые значения в хранилище
- 01:11:44 Проверка существования поля
- 01:13:16 Остальные страницы
- 01:14:07 Удаление prop-types
- 01:14:41 Ошибка тестирования без провайдера
- 01:15:05 Тестовый FakeAuthProvider
- 01:18:32 Обзор результата
Скрытый контент (код, слайды, ...) для подписчиков.
Открыть →Чтобы не пропускать новые эпизоды подпишитесь на наш канал @deworkerpro в Telegram
Спасибо!
спасибо!
Огромное спасибо за проделанную работу по проекту и остальные видео! Тащусь от людей у которых все по полочкам!
Хотел бы у Вас узнать по структуре Frontend проекта на React. Сейчас все компоненты размещаются в одном месте —
src
. Но со временем вsrc
будет большой список разных папок и станет не понятно что из этого страницы, что из этого модули или что-то другое. В Api приложении на Slim Вы использовали для всех http запросов одну папку —Http
. По аналогии с этим во frontend можно сделать общую папкуPage
куда положить всё что относится к странице:В добавлении к этому общую инфраструктуру
Api
,Alert
,Form
,OAuth
можно положить вShared
:Только вот у
OAuth
имеется зависимость отLayout
. Прежде чем поместить вShared
- придётся избавиться от этой зависимости.Откуда пришла такая мысль? Это Feature Sliced Design. Правда там предлагается ещё разделить
Feature
иEntity
по отдельным папкам. Я бы этого делать не стал. ВедьFeature
, как мне кажется, это какCommand
из с бакенд приложения. Команды никогда не выносятся вsrc
.В итоге получилась бы следующая структура:
При желании можно получше подумать о структуре и в целом можно её сделать практически такой, как на Backend приложении. Это было бы полезно для ориентации в проектах. Особенно в Full stack разработке.
Да, с ростом проекта структура разрастётся и нужно будет более основательно всё компоновать.
Но в бэкенде у нас обычно слабосвязанная бизнес-логика с несколькими точками входа (HTTP, Queue), а во фронтенде же, наоборот, обычно единственный сильносвязанный интерфейс.
Можно по аналогии вынести
Pages
, как это по умолчанию сделано в SSR-фреймворках вроде NextJS, и на страницах уже компоновать разные компоненты-виджеты. Это будет менее связано с точки зрения зависимостей, но тогда с точки зрения близости компонент-виджет формы регистрации будет лежать далеко от самой страницы регистрации. Или потом получим, что многие части изWidgets
в итоге перекочуют вShared
и образуют непонятную кучу там.Так что это выбор сложный. А выносить отдельно
Entity
из фичи действительно не нужно.Или войти через: