Типизация с TypeScript в React

После типизации наших 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 Обзор результата
Скрытый контент (код, слайды, ...) для подписчиков. Открыть →
Дмитрий Елисеев
elisdn.ru
Комментарии (5)
Руслан

Спасибо!

Ответить
Arunas

спасибо!

Ответить
kekc

Огромное спасибо за проделанную работу по проекту и остальные видео! Тащусь от людей у которых все по полочкам!

Ответить
Максим (@myks92)

Хотел бы у Вас узнать по структуре Frontend проекта на React. Сейчас все компоненты размещаются в одном месте — src. Но со временем в src будет большой список разных папок и станет не понятно что из этого страницы, что из этого модули или что-то другое. В Api приложении на Slim Вы использовали для всех http запросов одну папку — Http. По аналогии с этим во frontend можно сделать общую папку Page куда положить всё что относится к странице:

src/Page/Layout 
src/Page/Home 
src/Page/Join
src/Page/Error

В добавлении к этому общую инфраструктуру Api, Alert, Form, OAuth можно положить в Shared:

src/Shared/Api 
src/Shared/Alert, 
src/Shared/UI/Form
src/Shared/OAuth

Только вот у OAuth имеется зависимость от Layout. Прежде чем поместить в Shared - придётся избавиться от этой зависимости.

Откуда пришла такая мысль? Это Feature Sliced Design. Правда там предлагается ещё разделить Feature и Entity по отдельным папкам. Я бы этого делать не стал. Ведь Feature, как мне кажется, это как Command из с бакенд приложения. Команды никогда не выносятся в src.

В итоге получилась бы следующая структура:

└── src/
    ├── App/                    # Layer: Приложение
    |                           #
    ├── Process/              	# Layer: Процессы (опционально)
    |   ...                     #
    |                           #
    ├── Page/                   # Layer: Страницы
    |   ├── {SomePage}/ 		#     (н-р страница Join, Error, Home)
    |   ├── Layout 			#     (шаблоны страниц)
    |   ...                     #
    |                           #
    ├── Widget/                 # Layer: Виджеты
    |   ├── {SomeWidget}/       #    (н-р виджет Header)
    |   ...                     #
    |                           #
    ├── {SomeFeature}/          # Layer: Фичи
    |   ├── {SomeFeature}/		#	  (н-р фича Auth)
    |		├── Entity 			#     (н-р сущность User)
    |   ...                     #
    |   ...                     #
    |                           #
    ├── Shared/                 # Layer: Переиспользуемые ресурсы
    |   ├── Api/                #     Логика запросов к API
    |   ├── Alert/              #     Всплывающие окна
    |   ├── Config/             #     Конфигурация приложения
    |   ├── OAuth/              #     OAuth
    |   └── Ui/					# 	  UIKit приложения
    |		├── Form			#         
    |   ...                     #
    |                           #
    └── index.tsx/              #
  1. Что можете сказать по такой структуре?
  2. Что можете сказать в целом о подходе Feature Sliced Design, если Вы с ним знакомы?

При желании можно получше подумать о структуре и в целом можно её сделать практически такой, как на Backend приложении. Это было бы полезно для ориентации в проектах. Особенно в Full stack разработке.

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

Да, с ростом проекта структура разрастётся и нужно будет более основательно всё компоновать.

Но в бэкенде у нас обычно слабосвязанная бизнес-логика с несколькими точками входа (HTTP, Queue), а во фронтенде же, наоборот, обычно единственный сильносвязанный интерфейс.

Можно по аналогии вынести Pages, как это по умолчанию сделано в SSR-фреймворках вроде NextJS, и на страницах уже компоновать разные компоненты-виджеты. Это будет менее связано с точки зрения зависимостей, но тогда с точки зрения близости компонент-виджет формы регистрации будет лежать далеко от самой страницы регистрации. Или потом получим, что многие части из Widgets в итоге перекочуют в Shared и образуют непонятную кучу там.

Так что это выбор сложный. А выносить отдельно Entity из фичи действительно не нужно.

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

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

Yandex
MailRu
GitHub
Google