Table of Contents #
Чтобы начать использовать JSX, необходимо сделать следующее:
Замечание: Идентификатор React жёстко прописан в коде, поэтому необходимо сделать React доступным с заглавной буквы R.
Оператор as #
Вспомним, как записывается декларирование типов:
Проверка типов #
TypeScript использует то же соглашение, что и React, чтобы различать два вышеупомянутых случая. Внутренние элементы всегда начинаются с маленькой буквы, а элементы, основанные на значении, начинаются с заглавной.
Внутренние элементы
Замечание: Вы также можете определить универсальный строковый индексатор JSX.IntrinsicElements :
Элементы-значения
Система ищет элементы-значения по идентификаторам в пределах области видимости.
Есть возможность ограничить тип элемента-значения. Но для этого необходимо ввести два новых термина: тип класса элемента (element class type) и тип экземпляра элемента (element instance type).
Как только тип класса установлен, тип экземпляра определяется объединением возвращаемых типов сигнатуры вызова типа класса и сигнатуры конструктора. Опять же, в случае класса ES6, типом экземпляра будет тип экземпляра этого класса, а в случае фабричной функции это будет тип возвращаемого функцией значения.
Проверка типа атрибута
Для того, чтобы проверить типы атрибутов, сначала необходимо определить тип атрибутов элемента (element attributes type). Эта процедура немного отличается для внутренних элементов и элементов-значений.
Для внутренних элементов это тип свойства в JSX.IntrinsicElements
Тип атрибута элемента используется для проверки типов атрибутов в JSX. Поддерживаются опциональные и обязательные свойства.
Замечание: Если имя атрибута не является корректным JS-идентификатором (как атрибут data-* ), это не будет считаться ошибкой, если не будет находиться в типе атрибутов элемента.
Также можно использовать оператор расширения:
Тип результата JSX #
Встраивание выражений #
JSX позволяет вставлять выражения между тегами, заключая их в фигурные скобки ( < >).
Вышеприведённый код завершится ошибкой, так как вы не можете разделить строку на число. При использовании опции preserve вывод будет выглядеть так:
Интеграция с React #
Для работы JSX с React необходимо использовать React typings. Эти типы определяют пространство имён JSX для корректного использования с React.
Использование React JSX вместе с TypeScript 1.6
Не так давно Microsoft объявила о выпуске TypeScript 1.6 Beta, одним из интересных, на мой взгляд, нововведением является поддержка React/JSX, что в совокупности с особенностями TypeScript’а открывает новые возможности.
Я расскажу о личном опыте — как начал использовать связку TypeScript + React, с каким проблемами столкнулся и как их решал. А так же покажу примеры gulp-тасков для того, чтобы это все заработало и продемонстрирую код минимального todo приложения на TypeScript + React (ссылка на Github).
TypeScript 1.6
Вот основные изменения и дополнения, которые принесло это обновление:
Найтивная поддержка JSX
«Вау!» — вот первая мысль, когда я прочитал анонс. Но дальше начались проблемы, так как нельзя просто взять и использовать edge-технологии, поэтому перед тем, начать писать классный типизированный код, нам нужно немного поработать в консоли, чтобы избежать в будущем проблемы со сборкой и деплоем нашего кода.
Подготовка
По умолчанию будем считать, что у нас установлены и настроены актуальные версии nodejs и npm.
Установка TypeScript 1.6 Beta
Для установки TypeScript 1.6 Beta в глобальную область видимости воспользуемся командой:
После этого у вас в консоле будет доступна команда tsc — это собственно и есть компилятор для TypeScript. Убедитесь что у вас установлена версия 1.6-beta.
Проверим, что всё установилось с помощью команды:
Для локальной установки будем использовать команду:
Создание package.json
Файл package.json содержит в себе информацию о вашем приложении: название, версия, зависимости и тому подобное. Любая директория, в которой есть этот файл, интерпретируется как Node.js-пакет, даже если вы не собираетесь публиковать его.
Способ использования файла package.json зависит от того, собираетесь ли вы скачивать пакет или публиковать его. В нашем случае он будет содержать список зависимостей нашего проекта:
Создание gulpfile.js
В качестве сборщика проекта я использовал gulp, но, как по мне, особой разницы нет, так как главное — идея. Для сборки проекта мы воспользуемся уже готовыми npm пакетами: gulp-typescript для компиляции TypeScript и browserify для работы с зависимостями нашего проекта.
Компиляция TypeScript
Таск для компиляции TypeScript выглядит следующим образом:
Здесь мы использали ранее рассмотренный файл проекта. Более подробно — на github странице проекта.
browserify
Таск для создания бандла проекта выглядит следующим образом:
Копирование index.html
В качестве примера работы со статическими файлами и их копирования в gulp приведу пример gulp-таска для копирования index.html в папку dist:
gulpfile.js файл
Тогда весь gulpfile.js будем таким:
TypeScript Definitions
Я сейчас не буду подробно останавливаться на описании TypeScript Definitions, об этом написано много классных статей. Скажу лишь, что для того чтобы можно было использовать библиотеки написанные на JS для них нужно использовать эти самые TypeScript Definitions. И есть даже целый опенсорсный проект в котором народ пишет такие дефинишены для популярных проектов. Их можно искать и скачивать на сайте, а можно поставить консольную утилиту которая этот процесс упростит:
С помощью этой утилиты мы скачаем definitions для React и сохраним в файл tsd.json запись о TypeScript Definition:
Проект находится в open-source, развивается и активно поддерживается сообществом — borisyankov/DefinitelyTyped.
Создание tsconfig.json
Файл tsconfig.json хранит настройки компиляции для вашего проекта. Такой файл поддерживается компилятором начиная с версии 1.5. Минимальный tsconfig.json, позволяющий компилировать файлы для React/JSX выглядит следующим образом:
React-код
Для примера работы связки TypeScript + React мы напишем минимальное todo приложение.
todoItem.tsx компонент
Начнём с самого маленького кирпичика, а именно — TodoItem. Добавим TypeScript Definition для React в начало файла:
Затем импортируем React в наш класс:
Определим интерфейс ITodo для элемента:
А также интерфейсы для состояния и свойств нашего компонента:
Тогда сам компонент будет выглядить следующим образом:
main.tsx компонент
Данный компонент будет содержать основную логику работы приложения. Принцип тот же, что и в TodoItem компоненте, поэтому приведу полный листинг файла:
bootstrap.ts
Данный файл служит точкой для старта приложения и содержит логику для вызова основого компонента:
index.html
Так как мы не добавляляли никаких стилей и тд, то исходный код файла будет таким:
Запуск и фейерверки
Установка и компиляция
После того как были созданы все файлы, папки и таски, выполним:
для установки всех пакетов и:
для компиляции нашего приложения.
Запуск
Тут всё очень прозаично — натравливаем любимый сервер на папку dist и радуемся полученным результатам, например так:
Затем идём на localhost:3000/index.html и тестируем.
Вместо заключения
Весь код представленный в этом мини-гайде можно найти по ссылке. Любые замечания и предложения только приветствуются.
Tsx что это typescript
За исключением типизации, написание шаблонов .tsx ничем не отличается от .jsx. Но так как при переходе с .jsx на .tsx возникает лишь один вопрос, как правильно писать те или иные виды компонентов в типизированном стиле, то данная глава будет отличаться от остальных и будет построена таким образом, чтобы общую информацию изучить по ходу детального рассмотрения каждого вида компонентов в отдельности. Кроме того, если раньше примеры кода были придуманы таким образом, чтобы помимо информативности, быть ещё и компактными, то в случаи с компонентами React, ничего поделать нельзя. Чтобы хоть как-то сгладить это, компоненты будут показываться небольшими частями, а уже после будет описываться важные-неочевидные моменты. Помимо этого, компоненты не будут иметь какой-то осмысленный характер. Если попытаться смоделировать, что-то, что можно продемонстрировать, то кода было бы в разы больше и сделало его менее понятным.
Также, возможности TypeScript, позволяют аннотировать языковые конструкции, как в классическом, так и в минималистическом стиле. В первом случае аннотацию типа содержит каждая конструкция. Во втором часть работы перекладывают на вывод типов. Так как предполагается, что читатели, если ещё не разрабатывают большие приложения, то всеми силами к этому стремятся. Поэтому все примеры в этой главе будут выполнены в классическом-максимальном стиле. Кроме того, стоит уточнить, что на момент написание этой главы используется React v16.4.1 и TypeScript 3.1 и если вы заметили несоответствие, которое может произойти из-за изменение в версиях выше указанных, то можете об этом сообщить всеми доступными способами, указанными в соответствующем разделе.
Следующее, на что стоит обратить внимание, это создание псевдонимов типа для всех объявленных ранее интерфейсов.
Затем, в теле класса компонента, происходит объявление полей, которые нужны для получение ссылок на нативные dom элементы ( ref ).
И прежде, чем перейти к рассмотрению кода в её теле, обязательно стоит пролить свет на один очень важный момент, связанный с аннотированием типов. Как было сказано в начале этой главы, все примеры являются классическими, с точки зрения типизации, но несмотря на это, всем, кто придерживается подобного подхода в повседневной разработке, рекомендуется делать отступления от правил, особенно в случаях с функциями передаваемых в качестве значения. В данном случае, подобное аннотирование, является явным перебором.
В случаях, когда параметры слушателя событий не требуются, лучше вообще опускать аннотацию типа и переложить эту заботу на вывод типов. К тому же, отсутствие аннотации даже подчеркнет тот факт, что важен лишь вызов этого слушателя.
Первая из них заключается в аннотировании параметра event, без аннотирования поля, которому присваивается слушатель событий. Из-за того, что этот код нельзя трактовать двусмысленно, не страдает его читаемость. Но кроме того, вывод типов сможет вывести тип для поля, если информацию о нем потребуется получить с помощью подсказок предоставляемых всеми современными idea.
Второй способ диаметрально противоположен первому и предполагает явно аннотировать поле, а не значение, в роли которого выступает слушатель событий.
Какой способ выбрать зависит лишь от конвенций по стилю кода установленного в команде и от специфики некоторых ситуации.
Далее стоит обратить внимание на код в теле слушателя событий, а именно операции асинхронного изменения состояния при помощи функции, также называемой “функциональным состоянием”. Именно этот способ был выбран по той причине, что он отлично дополняет сказанное относительно отступления от правил касающихся классического подхода при аннотировании языковых конструкций.
И напоследок осталось рассмотреть методы жизненного цикла компонента. Но так как в них нет ничего такого, на что читатели, к этому моменту, не смогли дать ответ самостоятельно, комментариев не будет.
Кроме того, что в React пользовательские компоненты могут расширять обобщенный класс Component
, они также могут использовать в качестве базового класса обобщенный класс PureComponent
Поскольку в React функциональные компоненты, которые чаще называют Stateless Components, являются обычной функцией, то объявлять их можно двумя способами, в виде обычной функции (Function Declaration) и в виде функционального выражения (Function Expression), декларация которого также разделяется на два варианта, аннотирование самой функции и декларирования ссылки на неё. Так как stateless компоненты очень компактные и в них нет ничего, что не было рассмотрено на предыдущих шагах, здесь будет приведен код всех трех вариантов, но особое внимание будет уделено последнему варианту.
Как уже было сказано, первый способ, аннотирование Function Declaration ничем не отличается от аннотирования обычных функций.
Второй способ, аннотирование функции, выступающей в качестве значения, также не отличается от аннотирования обычной функции.
Третий способ, на который стоит обратить внимание, заключается в аннотировании ссылки на компонент с помощью встроенного в систему типов React обобщенного типа StatelessComponent
. В нем нет ничего неординарного, поэтому о нём можно добавить, что в качестве аргумента типа, он ожидает тип, описывающий свойства ( props ) компонента.
Все варианты одинаковые и выбор зависит от личных предпочтений. Хотя я склоняюсь к третьему варианту.
Нет ничего особенного и в объявлении функциональной декларации (Function Declaration).
Но относительно функциональных компонентов, в роли которых выступают стрелочные функции (arrow function), без курьезов не обошлось. Дело в том, что на данный момент, TypeScript не поддерживает обобщенные стрелочные функции, в файлах, с расширением .tsx.
Кроме того, объявление обобщенного функционального компонента в виде функционального выражения тоже накладывает некоторые ограничения. В большинстве случаев, использование параметров типа предполагается использовать в обобщенном интерфейсе описывающим свойства ( props ) компонент. А это в свою очередь делает бессмысленным аннотацию идентификатора ссылающегося на функцию.
, но это бы сделало бессмысленным саму типизацию. Поэтому, единственный вариант объявления обобщенного функционального компонента, в виде функционального выражение, возможен путем аннотирования самой функции и переложением ответственности за аннотирование ссылки на вывод типов.
После того, как обобщенный тип был объявлен, его можно начать использовать в .jsx шаблонах.
На этом, беглое рассмотрение объявления и создания обобщенных компонентов закончено, можно переходить к более практическим примерам.
Сложно представить приложение, в котором при построении отображения, обошлось бы без идентичного кода, который повторяется в нескольких частях программы. Поэтому разработчики, на основе готовых, низкоуровневых компонентов, создают свои, более высокоуровневые компоненты. При этом, чтобы их можно было переиспользовать, они должны быть максимально универсальными. Поэтому давайте, на простых примерах, выясним, почему к этому стоит стремится и как этого добится.
Кроме того, бывают случаи, когда массив с данными, по которому строятся компоненты, собирается на основе других данных и сразу же передается в тот компонент, в котором с ним происходит дальнейшая работа. В случаи, когда с этими данными нужно работать после того, как по ним отрендерятся визуальные компоненты, их требуется сохранить в локальное состояние. При повторении данного сценария, это снова приведет к повторению кода и кроме того код программы будет усложнен операциями по сохранению и поддержке данных в актуальном состоянии. Это приводит к нарушению ещё одного принципа известного как принцип KISS (“Keep it simple, stupid”).
Как минимум тип данных, которые ожидает универсальный компонент, должен иметь собственную декларацию и описывать только минимально требующиеся для успешного выполнения характеристики.
В типизированных языках, проблемы с универсальностью, решается с помощью механизма создания обобщенных типов. К тому же TypeScript, поддерживает синтаксис параметризированных компонентов, что будет продемонстрировано в последнем примере.
Очень часто, при разработке React приложений, разработчикам приходится создавать конструкцию, известную в react сообществе, как HOC (Higher-Order Components).
HOC, это функция, которая принимает компонент и возвращает новый компонент. Другими словами, hoc, это функция, ожидающая в качестве параметров компонент (назовем его входным), который оборачивается в другой, объявленный в теле функции, компонент, который выступает в роли возвращаемого из функции значения (назовем его выходным). Слово “оборачивание” применимое относительно компонентов, означает, что один компонент, отрисовывает (рендерит) другой компонент, со всеми вытекающими из этого процесса (проксирование). За счет того, что входной компонент оборачивается в выходной, достигается расширение его и\или общего функционала. Кроме того, это позволяет устанавливать входному компоненту, как зависимости, так и данные, полученные из внешних сервисов.
Если объяснения, что такое hoc и в каких случаях в нем появляется необходимость, выходит за рамки данной книги, то с примерами, иллюстрирующими самые распространенные случаи, для общей картины, ознакомится все же стоит.
Но прежде чем приступить к краткому рассмотрению примеров, будет полезно более подробно ознакомиться с сигнатурой hoc-функции
Как уже было сказано, входной компонент, оборачивается, в объявленный в теле функции, выходной компонент, который может быть как классовым так и функциональным компонентом. И прежде чем кратко ознакомится с каждым из случаев, будет полезно, отдельно рассмотреть сигнатуру hoc-функции на распространенном в практике примере, когда свойства ( props ) выходного компонента, лишь дополняются свойствами входного компонента.
Теперь перейдем к рассмотрению кода, описывающего hoc целиком. Но так как его сигнатура уже была подробно изучена, а в его теле не происходит ничего, что не было бы рассмотрено в этой главе, нет необходимости в каких-либо комментариях.
И начать стоит с hoc, выходной компонент которого является классовым компонентом, использование которого требуется тогда, когда логика зависит от жизненного цикла компонента.
Если же потребности в жизненом цикле нет, то предпочтительней использовать hoc, у которого выходной компонент является функциональным.
И в заключение предлагаю рассмотреть случай, когда параметры устанавливаемые компоненту обертке отличаются от тех, которые он устанавливает оборачиваемому компоненту. И несмотря на то, что код показанный ниже, отличается от предыдущего, подробного разбора не будет, так как в нем нет ничего, что к этому моменту не было бы известно читателю.
Стартуем библиотеку компонентов на React и TypeScript
Большую часть свой работы, я пишу бэкенды, но вот на днях появилась задача начать библиотеку компонентов на React. Несколько лет назад, когда версия React была такой же маленькой, как и мой опыт фронтенд-разработки, я уже делал подход к снаряду и получилось неумело и коряво. Принимая во внимание зрелость текущей экосистемы React и мой подросший опыт, я воодушевился уж в этот-то раз сделать всё хорошо и удобно. В результате у меня появилась заготовка для будущей библиотеки, а чтобы ничего не забыть и собрать всё в одном месте, была написана эта статья-шпаргалка, которая также должна помочь тем, кто не знает, с чего начать. Посмотрим, что же у меня получилось.
TL/DR: Код готовой к старту библиотеки можно посмотреть на github
К задаче можно подойти с двух сторон:
Первый способ хорош для быстрого старта, когда вы совершенно не хотите разбираться с конфигурированием и подключением необходимых пакетов. Также этот вариант подойдёт для новичков, кто не знает с чего начать и в чём должно быть отличие бибилиотеки от обычного приложения.
Вначале я пошёл первым путём, но затем решил обновить зависимости и прикрутить ещё пару пакетов, и тут посыпались всякие ошибки и несостыковки. В итоге закатал рукава и сделал всё сам. Но генератор библиотек таки упомяну.
Create React Library
Большинство разработчиков, которые имели дело с React слышали про удобный стартер приложений на React, который позволяет свести конфигурацию проекта к минимуму и предоставляет разумные дефолты — Create React App (CRA). В принципе, его можно было бы использовать и для библиотеки (и есть статья на хабре). Однако, структура проекта и подход к разработке ui-kit немного отличается от обычного SPA. Нам нужен отдельный каталог с исходниками компонентов (src), песочница для их разработки и отладки (example), инструмент документирования и демонстрации («витрина») и отдельный каталог с подготовленными к экспорту файлами (dist). Также компоненты библиотеки не будут складываться в SPA приложение, а будут экспортироваться через индексный файл. Подумав об этом, я отправился на поиски и быстро обнаружил подобный CRA пакет — Creat React Library (CRL).
CRL, также как и CRA, является «easy-to-use» CLI-утилитой. С помощью неё можно сгенерировать проект. Он будет содержать:
Для генерации проекта библиотеки выполним(npx позволяет не устанавливать пакеты глобально):
И в результате работы утилиты получим сгенерированный и готовый к работе проект библиотеки компонентов.
На сегодняшний день зависимости немного устаревшие, поэтому я решил обновить их всех до последних версий с помощью npm-check:
Ещё одним печальным фактом является то, что приложение-песочница в каталоге example генерируется на js. Придётся руками переписать его на TypeScript, добавив tsconfig.json и некоторые зависимости (например, сам typescript и основные @types ).
Спасибо пользователю StanEgo, который рассказал про отличную альтернативу Create React Library — tsdx. Эта cli-утилита также похожа на CRA и в одну команду создат основу для вашей библиотеки с настроенным Rollup, TS, Prettier, husky, Jest и React. Причем React идёт как опция. Достаточно просто выполнить:
И в результате будут установлены необходимые свежие версии пактов и сделаны все настройки. Получим похожий на CRL проект. Основное отличие от CRL — Zero-config. Т. е. конфиг Rollup скрыт от нас в tsdx (также как это делает CRA).
Быстро пробежавшись по документации, я не нашёл рекомендуемых способов более тонкой конфигурации или что-то вроде eject как в CRA. Заглянув в issue проекта, обнаружил, что пока такой возможности нет. Для каких-нибудь проектов это может быть критично, в этом случае придётся немного поработать руками. Если же вам это не нужно, то tsdx отличный способ, чтобы быстро начать.
Берём управление в свои руки
Теперь установим пакеты react и react-dom и необходимые types (т.к. мы будем пилить компоненты на TypeScript) как devDependencies (как и все пакеты в этой статье):
Rollup
Для сборки будем использовать Rollup, как предлагал CRL. Необходимые пакеты и конфиг, я подсматривал также у CRL. Вообще слышал мнение, что Rollup хорош для библиотек, а Webpack для приложений. Однако, я не конфигурировал Webpack (мне хватало того, что делает за меня CRA), но Rollup действительно хорош, прост и красив.
В package.json добавим поля с распложением собранных бандлов библиотеки, как рекомендует нам rollup — pkg.module:
Конфиг представляет собой js-файл, а точнее экспортируемый объект. В поле input указываем файл, в котором прописаны экспорты для нашей библиотеки. output — описывает наши ожидания на выходе — в модуль какого формата скомпилировать и куда его положить.
Первый компонент и экспортный файл
Также в src надо создать файл с общими для библиотеками типами, где будет объявлен тип для css и svg (подсмотрено у CRL).
Далее добавим несколько инструментов для повышения качества нашего процесса разработки и его результата.
Забываем о форматировании кода с Prettier
Терпеть не могу в code-review указывать на небрежное или нестандартное для проекта форматирование, а тем более спорить про него. Подобные недочёты естественно должны быть исправлены, однако разработчикам лучше сосредоточиться на том, что и как код делает, а не как он выглядит. Эти исправления — первый кандидат на автоматизацию. Есть прекрасный пакет под эту задачу — prettier. Установим его:
Добавим конфиг для небольшого уточнения правил форматирования.
Мы можем не ждать форматирования до коммита, а сделать так, чтобы prettier постоянно срабатывал на изменённые файлы в процессе нашей работы. Да, нам нужен ещё один пакет — onchange. Он позволяет следить за изменениями файлов в проекте и тут же выполнять необходимую для них команду. Устанавливаем:
Затем в команды поля scripts в package.json добавляем:
На этом все споры о форматирвании в проекте можно считать закрытыми.
Избегаем ошибок с ESLint
ESLint уже давно стал стандартом и его можно встретить практически во всех js и ts-проектах. Нам он тоже поможет. В конфигурировании ESLint я доверяю CRA, поэтому просто возьмём необходимые пакеты из CRA и подключим в нашу библиотеку. Кроме того, добавим конфиги для TS и prettier (чтобы избежать конфликтов между ESLint и prettier ):
Настроим ESLint с помощью конфигурационного файла.
Тестируем с Jest
Чтобы писать модульные тесты для компонентов библиотеки, установим и сконфигурируем Jest — библиотеку тестирования от facebook. Однако, т.к. мы компилируем TS не через babel 7, а через tsc, то нам нужно также установить пакет ts-jest:
Чтобы jest нормально воспринимал импорты css или других файлов, необходимо подменить их моками. Создаём каталог __mocks__ и создаём там два файла.
styleMock.ts :
Теперь создаём конфиг jest.
Напишем простейший тест для нашего ExampleComponent в его каталоге.
Разрабатываем, документируем и любуемся компонентами с Storybook
Каждая библиотека нуждается в хорошей документации для её успешного и продуктивного использвания. Что касается библиотеки компонентов интерфейса, то про них не только хочется прочитать, но и посмотреть как они выглядят, а лучше всего потрогать и поизменять. Для поддержки такой хотелки есть несколько решений. Раньше я использовал Styleguidist. Этот пакет позволяет писать документацию в формате markdown, а также вставлять в неё примеры описываемых React-компонентов. Далее документация собирается и из неё получается сайт-витрина-каталог, где можно найти компонент, прочитать документацию о нём, узнать о его параметрах, а также потыкать в него палочкой.
Однако в этот раз я решил присмотреться к его конкуренту — Storybook. На сегодняшний момент он кажется более мощным с его системой плагинов. Кроме того, он постоянно развивается, имеет большое сообщество и скоро также начнёт генерировать свои страницы документации с помощью markdown-файлов. Ещё одно достоинство Storybook это то, что он является песочницей — средой для изолированной разработки компонентов. Это означает, что нам не нужны никакие полноценные приложения-примеры для разработки компонентов (как это предлагает CRL). В storybook мы пишем stories — ts-файлы, в которых мы передаём наши компоненты с некоторыми входыми props в специальные функции (лучше посмотреть на код, чтобы стало понятнее). В итоге из этих stories собирается приложение-витрина.
Запустим скрипт, который выполнит инициализацию storybook:
Теперь подружим его с TS. Для этого нам нужно ещё немного пакетов, а заодно поставим пару полезных аддонов:
Напишем нашу первую story в каталоге компонента ExampleComponent
Мы использовали аддоны:
Разрабатываем
Кроме того, можно авторизоваться в npm и опубликовать свою библиотеку как новый npm-пакет. А можно подключать её прямо из git-репозитория как из master, так и из других веток. Например, для моей заготовки можно выполнить:
Также, благодаря TS, будет работать автодополнение в IDE.
Подводим итоги
В середине 2019 года можно довольно быстро начать разрабатывать свою библиотеку компонентов на React и TypeScript, пользуясь удобными инструментами разработки. Этого результата можно достичь как с помощью автоматизированной утилиты, так и в ручном режиме. Второй путь является предпочтительным, если нужны актуальные пакеты и больше контроля. Главное знать куда копать, а с помощью примера в этой статье, я надюсь, это стало несколько проще.
Вы также можете взять получившуюся заготовку тут.
Кроме всего прочего, я не претендую на истину в последней инстанции и, вообще, занимаюсь фронтендом постольку-поскольку. Вы можете выбрать альтернативные пакеты и опции конфигурации и также достичь успеха в создании своей библиотеки компонентов. Буду рад, если вы поделитесь в комментариях своими рецептами. Happy coding!