React reactnode что это
React терменология (виртуального) DOM
В терминологии React, есть пять основных типов, которые важно различать:
1)2) ReactElement / фабрика ReactElement-ов
3) ReactNode
4)5) ReactComponent / класс ReactComponent
React Elements
Основной вид в React является ReactElement. Он имеет четыре свойства: type, props, key и ref. Он не имеет методов и ничего в прототипе.
Вы можете создать один из этих объектов через React.createElement.
Для рендеринга нового дерева в DOM, вы создаете ReactElement-ы и передаваете их React.render вместе с обычным DOM Element-ом (HTMLElement или SVGElement). ReactElement-ы не путайте с DOM Element-ами. ReactElement является облегченным, без состояний, неизменным, виртуальным представление DOM Element-а. Это виртуальный DOM.
Чтобы добавить свойства к DOM элементу, передайте объект свойств в качестве второго аргумента и детей в качестве третьего аргумента.
Если вы используете React JSX, то ReactElement-s создаются для вас. Так что это эквивалентно:
Фабрика-ReactElement-ов это просто функция, которая генерирует ReactElement с определенного type свойством. React имеет встроенный помощник для Вас, чтобы создать фабрики.
Это позволяет создать удобное сокращение, а не писать React.createElement(‘div’) все время.
В React уже встроенны фабрики для общих тегов HTML:
Если вы используете JSX у вас нет необходимости пользоваться фабриками. JSX уже обеспечивает удобные сокращения для создания ReactElement-ов.
React Узлы
Они используются в качестве свойств других ReactElement-ов с тем чтобы отображать детей. В действительности они создают дерево ReactElement-ов.
React компоненты
Вы можете использовать React только для ReactElement-ов, но по-настоящему получить преимущество React вы получите если захотите использовать ReactComponent для создания инкапсуляции со встроенными состоянием.
Класс ReactComponent это просто класс JavaScript (или «конструктор функции»).
Когда этот конструктор вызывается, то как и ожидается, возвращают объект, с по крайней мере, render методом на него. Этот объект ссылается на ReactComponent.
Кроме тестирования, вы обычно никогда не должны вызывать конструктор на себя. React вызывает его для вас.
Вместо этого, вы передаете ReactComponent-класс createElement-у и получаете ReactElement.
Либо используя JSX:
Когда это передается React.render-у, React вызовет конструктор для вас и создст ReactComponent, который вернет.
Если вы продолжите вызывать React.render с тем же типом ReactElement и в том же контейнере DOM Element он всегда возвратит тот же экземпляр. Этот экземпляр является stateful.
Вот почему вы не должны строить свои собственные экземпляры. Вместо этого, ReactElement является виртуальным ReactComponent прежде чем он будет построен. Старый и новый ReactElement можно сравнить, чтобы увидеть, нужно ли новый ReactComponent экземпляр создается, или используется существующий повторно.
Ожидается, что render метод ReactComponent-а возвращает еще один ReactElement. Это позволяет этим компонентам быть составными. В конечном счете рендер превращается в ReactElement с тегом string, который создает экземпляр DOM Element-а и вставляет его в документ.
Как устроен ReactJS. Пакет React
Большинство людей, работающих во фронтенде, так или иначе сталкивались с реактом. Это JavaScript библиотека, помогающая создавать крутые интерфейсы, в последние годы набрала огромную популярность. При этом, не так много людей знает, как она работает внутри.
В первую очередь, сделаем небольшой пример, на основе которого будем рассматривать этот пакет. Наше мини-приложение будет выглядеть так:
Кому интересно поэкспериментировать и посмотреть, во что превращает ваш код бабель – babel repl.
React.createElement
Итак, мы получили множество вызовов React.createElement() и время посмотреть что же делает эта функция. Опишем на словах (а можно и в файл заглянуть – ReactElement.js).
В первую очередь она проверяет есть ли у нас пропсы (в коде объект с пропсами, который мы передали, называется config ).
Далее идут следующие шаги:
Когда мы подготовили все данные, мы вызываем внутреннюю функцию, которая создаёт объект, описывающий наш компонент. Выглядит этот объект следующим образом:
Если переводить на наш пример, то результат React.createElement(App, null) выглядить это будет так:
Кроме того, в дев режиме у нас появится дополнительное поле, которое будет использоваться для отображения красивого стека с именем файла и строкой:
Подведём маленький итог из того, что мы увидели выше. Пакет react выступает переводчиком между нами и остальными пакетами, которые работают далее над нашим приложением, переводя наши вызовы в слова, понятные, например, реконсайлеру.
React.useState
На самом деле, говорить много тут не придётся. По сути, пакет является фасадом, через который наши вызовы идут к внутренним сущностям.
Так, useState — это ни что иное, как две строчки кода:
Что дальше
Финал
У меня есть очень простой функциональный компонент:
И еще один компонент:
Я получаю следующую ошибку:
[ts] Тип элемента JSX ‘ReactNode’ не является функцией-конструктором для элементов JSX. Тип undefined нельзя присвоить типу ElementClass. [2605]
Как мне это правильно набрать?
Просто children: React.ReactNode
Убедитесь, что нежелательные типы нейтрализованы, заключив возвращаемое значение в React Fragment ( <> ):
Вот что сработало для меня:
Изменить Я бы рекомендовал использовать children: React.ReactNode вместо этого сейчас.
вы можете объявить свой компонент следующим образом:
Вы можете использовать ReactChildren и ReactChild :
Это сработало для меня. Дочерним узлом может быть много разных вещей, поэтому явная типизация может пропустить случаи.
Тип возвращаемого значения функционального компонента ограничен JSXElement | null в TypeScript. Это текущее ограничение типа, чистый React допускает больше типов возвращаемых значений.
В качестве временного решения можно использовать утверждение типа или фрагменты:
ReactNode
Вы также можете использовать React.PropsWithChildren
Общий способ найти любой тип на примере. Прелесть машинописного текста в том, что у вас есть доступ ко всем типам, если у вас есть правильные @types/ файлы.
Чтобы ответить на этот вопрос, я просто подумал о том, что компонент React использует эту children опору. Первое, что пришло в голову? А как насчет
Затем, если вы щелкните определение типа, вы сразу перейдете к определению children исходящего из DOMAttributes интерфейса.
Примечание: этот процесс следует использовать для поиска любого неизвестного типа! Все они ждут, пока вы их найдете 🙂
Функциональные компоненты¶
Всем известно, что React компоненты, обозначаемые как функциональные, являются обычными функциями. И как все функции в JavaScript, они также могут быть определены двумя способами — в виде обычной функции (Function Declaration) и в виде функционального выражения (Function Expression), таящего один неочевидный нюанс, который подробно будет рассмотрен по ходу знакомства с ним.
Определение компонента как Function Declaration¶
Типизация параметров¶
Факт, что функциональный компонент, является обычной функцией, предполагает необходимость в типизировании её сигнатуры или точнее её параметров, так как указание типа возвращаемого значения не просто можно, а даже рекомендуется опустить, возложив эту работу на вывод типов.
Также необходимо всегда помнить, что независимо от того используется пространство имен React непосредственно или нет, модули определяющие React компоненты обязаны его импортировать. В противном случае компилятор напомнит об этом с помощью ошибки.
При определении первого параметра функционального компонента props появляется потребность в типе описывающем их.
Поскольку идеология React подразумевает прокидывание пропсов из одного компонента в другой, то компоненту выступающему в роли провайдера помимо своих пропсов, необходимо описывать пропсы своих детей. В случаях, когда в проброске нуждаются только несколько значений принадлежащих к типам из системы типов TypeScript, декларирование их в пропсах провайдера не будет выглядеть удручающе.
Экспорт типа параметров¶
Но если пробрасываемые пропсы представлены множеством значений, к тому же, частично или полностью принадлежат к пользовательским типам, то более целесообразно включить в описание типа пропсов компонента-провайдера, тип, описывающий пропсы компонента, которому они предназначаются. Поэтому тип описывающий пропсы желательно всегда экспортировать. Для того, чтобы избежать коллизий именования типов представляющих пропсы, их идентификаторы необходимо конкретизировать, то есть давать более уникальные имена. Поэтому принято имени Props добавлять префикс идентичный названию самого компонента.
Получение типа параметров без его экспорта¶
Тем, кому ближе минимализм, может прийтись по душе подход с получением типа пропсов без его экспорта.
Подобный способ будет не заменим при работе со сторонними библиотеками React компонентов, которые не имеют экспорты типов описывающих свои пропсы.
Модификатор readonly для параметров¶
Не будет лишним напомнить, что при помощи модификатора readonly не удастся избежать изменений переменных ссылки на которые были получены с помощью механизма деструктуризации.
Декларирование children¶
При необходимости декларирования children можно выбрать несколько путей. Первый из них подразумевает использование обобщенного типа PropsWithChildren
Если логика компонента предполагает обязательную установку children или уточнение типа к которому они принадлежат, то появляется необходимость их непосредственной декларации в типе представляющем пропсы этого компонента.
Для этого понадобится импортировать обобщенный тип ReactElement
, первый параметр типа которого ожидает тип пропсов, а второй строку или конструктор компонента для указания его в качестве типа поля type необходимого для идентификации. По факту тип ReactElement
Если кажется просто, то не стоит сомневаться, оно так и есть. Совершенно ничего сложного. Единственное стоит уточнить два важных момента.
Всё дело в том, что экземпляр компонента представляется типом Element из пространства имен JSX, является производным от типа ReactElement
, что делает уточнение типа бессмысленным.
Кроме этого, ReactElement
совместим не только с экземплярами компонентов, но и React элементов.
Ссылки useRef() и ref¶
Ввиду того, что тема касающаяся первого параметра функционального компонента обозначаемого пропсами, себя исчерпала, пришло время рассмотреть его второй, не часто используемый, параметр, обозначаемый как реф и предназначенный для передачи ссылки на текущий компонент. Для большего понимания этого механизма необходимо начать его рассмотрение из далека. Но прежде стоит уточнить два момента.
Во-первых тему посвященную рефам стоит начать с напоминания, что они делятся на два вида. Первый вид предназначен для получения ссылок на React элементы, а второй на React компоненты. Так вот второй параметр функционального компонента предназначен для установления рефы на себя самого, тио есть на компонент.
Во-вторых, при рассмотрении механизма посвященного рефам, применяются хуки, чья логика работы будет затронута лишь поверхностно, поскольку впереди ожидает целая глава посвященная их подробному рассмотрению.
Обратные ссылки forwardRef¶
Разрешить данную ситуацию можно несколькими способами. Первый заключается в явном преобразовании типа функционального компонента к типу ForwardRefRenderFunction которому в качестве аргументов типа требуется указать необходимые типы. При этом отпадает нужда в указании аргументов типа непосредственно самой универсальной функции forwardRef () ;
Последнее на что стоит обратить внимание, это обобщенный тип ForwardRefExoticComponent
к которому принадлежит значение возвращаемое из универсальной функции forwardRef () и указывать который в явной форме нет никакой необходимости.
Система типов React¶
Первый тип, вносящий смуту, это ранее рассмотренный ReactElement
Типы событий React¶
Последнее что осталось без внимания, это событийный механизм или если быть точнее определение слушателей событий. Для этого в системе типов React определен специальный обобщенный тип ReactEventHandler ожидающий в качестве аргумента типа тип представляющий нативный dom элемент которому будет установлен текущий слушатель событий.
Несмотря на то что такой способ типизирования слушателей событий является предпочтительным, также не будет лишним рассмотреть и другой имеющийся вариант состоящий в описании непосредственно сигнатуры функции.
Мемоизация слушателей событий¶
На этом рассмотрение типизирования функционального компонента определенного как Function Declaration, завершено. И поскольку тема получилась довольно не маленькая исключим затягивание и перейдем к рассмотрению следующего вида функциональных компонентов.
Определение компонента как Function Expression¶
Поскольку самое необходимое относящиеся ко всем видам React компонентов было рассмотрено в предыдущей теме, в этой и последующих, повествование будет сосредоточено исключительно на различиях.
Для определения функционального компонента как Function Expression декларация типов React предусматривает вспомогательный обобщенный тип FC
Если тип пропсов указан в качестве аргумента типа FC
В остальном все что было рассмотрено в предыдущей теме относительно пропсов и children идентично и для данного способа типизирования функциональных компонентов.
При возникновении необходимости в определении второго параметра функционального компонента придется самостоятельно указывать аннотацию типа, поскольку по каким-то причинам обобщенный тип FC
этого не предусматривает.
В остальном все рассмотренное относительно рефов в теме посвященной функциональным компонентам определенным как Function Declaration, верно и для текущего вида определения.
При необходимости во втором параметре можно отказаться от типа FC
Важной особенностью использования обобщенного типа FC
заключается в том, что он, помимо типа представляющего пропсы, также содержит описание типа возвращаемого функцией значения. Вроде бы так и должно быть, но нюанс заключается в том, что возвращаемое значение обязательно должно принадлежать к типу совместимому с ReactElement
Поэтому в случае, предполагающем, что функциональный компонент, определенный как Function Expression, будет возвращать значение отличное от ReactElement
, потребуется самостоятельно описать его сигнатуру. Что не представляет никакого труда.
Если в подобном определении функциональных компонентов существует частая потребность, будет целесообразней определить собственный тип подробно описывающий сигнатуру функции.
, что является сокращением от Custom Functional Component, готов сэкономить время и нервы разработчика.
На этом тема относящаяся функциональных компонентов себя полностью исчерпала, поэтому без лишних слов двигаемся к следующей теме посвященной классовым компонентам.
Классовые компоненты¶
Помимо компонентов на основе функций, React позволяет определять компоненты на основе классов, которые, как в случае реализации ловушки для ошибок просто не заменимы. Кроме этого, с ними необходимо познакомиться, так как они являются частью React. Именно поэтому текущая глава полностью посвящена старым добрым классовым компонентам.
Производные от Component
Пользовательские компоненты построенные на основе классов обязаны расширять базовый обобщенный класс Component
имеющего три необязательных параметра типа.
Первым делом стоит обратить внимание на первую строку, а именно импорт пространства имен React. Не зависимо используете вы его напрямую или нет, оно обязательно должно быть импортировано, в противном случаи компилятор напомнит об этом с помощью ошибки.
Кроме того в нашем примере у метода render отсутствует аннотация возвращаемого типа, что на практике даже приветствуется. Но с образовательной точки зрения её указание не принесет никакого вреда.
При переопределении производным классом метода render в качестве типа возвращаемого значения необходимо указывать тип совместимый с указанным в базовом классе, то есть с типом ReactNode поведение и нюансы которого были подробно рассмотрены в главе посвященной функциональным компонентам.
Как говорилось ранее, тип от которого должны наследоваться пользовательские классовые компоненты является обобщенным и имеет три необязательных параметра типа, что и иллюстрирует наш минималистический пример.
В реальных проектах подобное встречается редко, поэтому следующим шагом разберем логику определения типов описывающих пользовательский компонент.
Параметры Props¶
Поскольку в описании базового класса поле ( this.props ) принадлежит к типу определенного в качестве первого параметра типа, то есть Component
, то Props необходимо указать в аннотации не только первого параметра конструктора, но и в качестве первого аргумента базового типа. Иначе this.props так и останется принадлежать к простому объектному типу <> заданному по умолчанию.
Посмотрим как новая информация преобразит наш основной пример.
Параметр children¶
Состояние State¶
Говоря о состоянии нельзя обойти стороной такой метод как setState необходимый для его изменения, о котором известно что в качестве аргумента он может принимать как непосредственно объект представляющий новое состояние, так и функцию возвращающую его. Но поскольку первый случай ничего, что нас могло бы заинтересовать, из себя не представляет, рассмотрен будет лишь второй вариант с функцией. Поэтому продолжим наш основной пример и внесем в него изменения касающиеся изменения состояния. Создадим скрытый метод reset который будет сбрасывать значение пройденного времени.
В случае когда функция updater выполняет частичное обновление состояния и при этом тип возвращаемого значения указан явно, необходимо воспользоваться механизмом распространения ( spread ) дополнив отсутствующую часть в новом состоянии старым.
Несмотря на то что механизм распространения помогает обойти трудности связанные с совместимостью типов, лучшим вариантом будет вообще не указывать возвращаемый функцией updater тип, а возложить эту обязанность на вывод типов.
Snapshot¶
И на этом рассмотрение состояния завершено, поэтому можно приступить к рассмотрению третьего и последнего параметра базового типа Component
Жизненный цикл¶
Вдобавок необходимо заметить, что код иллюстрирующий жизненный цикл компонента взять из декларации устанавливаемой из репозитория @types/react и именно поэтому она изобилует излишними преобразованиями в Readonly тип. Но как было отмечено ранее, в этом нет нужны поскольку все типы составляющие троицу аргументов базового типа уже прошли преобразование при определении представляющих их псевдонимов. Учитывая этот факт предыдущий код будет выглядеть следующим образом.
Ссылки ref¶
Следующий в очереди на рассмотрение механизм, получение ссылок на нативные dom элементы и React компоненты, обозначаемый как рефы (refs).
Второй способ получения ссылки на нативный элемент заключается в определении функции принимающей в качестве единственного параметра нативный dom элемент, сохранение ссылки на который перекладывается на разработчика.
Выбор того или иного способа зависит лишь от предпочтений самого разработчика.
И раз уж тема дошла до рассмотрения рефов, то необходимо рассмотреть механизм получения с их помощью ссылки на классовый компонент.
Обработчики событий¶
На этом рассмотрение работы с механизмом рефов в типизированном стиле завершено. Но до завершения знакомства с работой классового компонента в основе которого лежит Component
Первым делом возвратим предыдущий пример в первоначальное состояние и добавим кнопку для отправки формы.
Контекст можно было бы сохранить прибегнув к методу bind или делегированию события непосредственно с помощью стрелочной функции определенной в месте установки слушателя, но зачем? Для bind потребуется определения дополнительного поля.
Стрелочная функция будет пересоздаваться каждую отрисовку.
На этом тему посвященную созданию классового компонента расширяющего Component
можно заканчивать и переходить к следующей теме. Единственное что точно не будет лишним, так это собрать весь пройденный материал в одном месте.
Производные от PureComponent
Помимо того, что пользовательские компоненты могут быть производными от универсального класс Component
, они также могут использовать в качестве базового класса универсальный класс PureComponent
Тем кто только начал своё знакомство с классовыми компонентами с данной главы необходимо вернутся на шаг назад или даже более разумно в самое начало, поскольку именно там объясняется что для полного понимания необходимо ознакомиться со всем материалом относящимся к React.