Import react from react не работает

почему «import из ‘реакции’;» не работа?

Может кто-нибудь объяснить мне, почему

import < React >from ‘react’;

все ломает, пока

import React from ‘react’;

работает просто отлично? Разве они не говорят то же самое? Я пытался найти ответ в другом месте в документации и в Интернете, но я не могу понять это. Я думаю, что это как-то связано с Бабелем?

Вот мои пакеты npm, если это поможет:

import React from ‘react’

По сути, это говорит: “найдите экспорт по умолчанию из модуля react и импортируйте его как константу, которую я хочу назвать React “.

import < React >from ‘react’

Это говорит: “найдите экспорт из модуля react который явно называется React , и импортируйте его здесь как константу, которую я хочу назвать React “.

Почему не import < React >from ‘react’ работы?

Потому что в пакете react экспорт с именем React . Существует только один экспорт по умолчанию. Если вы сделаете это, вы обнаружите, что React не undefined .

Но даже не похоже, что я использую React в своем коде. Итак, я не могу просто назвать это как угодно, например import Foobar from ‘react’ ?

Нет извините. Вам нужно импортировать значение по умолчанию и назвать его React . Это происходит потому, что каждый раз, когда вы пишете код JSX, например, или , этот код JSX передается и использует React.createElement() . Итак, вам нужно иметь доступ к React .

По данным MDN, imports работает таким образом

В основном это означает, что если пакет экспортирует что-то по умолчанию, его следует импортировать без <> и с любым именем, которое вы выберете. Когда пакет экспортирует что-либо как именованный экспорт, его следует использовать с <> .

react пакет экспортирует React по умолчанию, и каждый пакет может иметь только один export умолчанию.

Разница между экспортом по умолчанию и именным экспортом.

Экспорт по умолчанию

react.js

Вы можете импортировать указанный выше файл react.js в свой проект, например:

Именованные Экспорты

react.js

Затем вы должны импортировать указанный выше файл react.js в ваш проект, как

TL; DR – узнайте об экспорте по умолчанию и именном экспорте отсюда

Второй работает, потому что это экспорт по умолчанию из пакета React. Вы можете назвать его как угодно, потому что для каждого модуля существует только один экспорт по умолчанию.

Итак, import RandomName from ‘react’; будет иметь такую же функциональность.

Все остальное экспортируется четко определено, поэтому наименование имеет значение.

Другие экспорты могут выглядеть примерно так:

Чтобы импортировать его, вы должны выполнить import < someFunction >from ‘./path’; , Вы можете видеть, что мы деструктурируем (распаковываем) имя из объекта экспорта.

Источник

Импорт react с древнейших времен до наших дней

Прежде чем мы начнём разговор о способах импорта в веб-проекты библиотеки React, покажу современные способы выполнения этой операции и использования хука useState :

Ниже я расскажу об истоках каждого из этих механизмов, и о том, почему я предпочитаю использовать последний из них.

Импорт React до начала времён

Я начал писать React-код во времена React.createClass . Вот как это делалось тогда:

Тут можно видеть и var , и React.createClass , и require , и function . Славные были времена.

Классы и модули

Потом появился стандарт ES6 (и более поздние стандарты), в котором были описаны модули, классы и некоторые другие приятные синтаксические конструкции:

Именно в это время люди начали задаваться вопросом о том, как правильно импортировать React. Многие выбирали такой способ:

Обычно подобные вещи не вызывают вообще никаких вопросов. Программисты делают то, что согласуется с устройством библиотеки. Но React никогда не предлагал программистам возможности ES-модулей. С точки зрения программиста библиотека выглядела либо как глобальная переменная React , либо как CommonJS-модуль, представленный объектом React , в котором есть Component и много чего ещё. Но из-за того, как именно компилируется подобный код, оба подхода, с технической точки зрения, были рабочими. Ни один из них нельзя было признать «неправильным».

С другой стороны, глядя на вышеприведённый код можно задаться вопросом о том, почему нельзя переписать его так:

Причина, по которой тут надо импортировать React , заключается в том, что (в те времена) JSX-код компилировался в расчёте на использование React:

Поэтому, если использовался JSX, то надо было импортировать и React .

Через некоторое время, не очень большое, появились функциональные компоненты. Даже учитывая то, что тогда их нельзя было использовать для управления состоянием или побочными эффектами, они стали очень популярными. Я (как и многие другие) сильно привык к преобразованию кода компонентов, основанных на классах, в код функциональных компонентов, равно как и к обратной операции. Многие просто решили, что так работать проще в сравнении с использованием исключительно компонентов, основанных на классах.

Я же стремился к как можно более широкому использованию функциональных компонентов. И в этом, вероятно, кроется причина того, что я предпочитал использовать конструкции import React from ‘react’ и React.Component , а не import React, from ‘react’ . Мне не хотелось каждый раз менять выражения импорта, переходя от компонентов, основанных на классах, к функциональным компонентам, или выполняя обратную операцию. И да, я знаю, что IDE и редакторы, вроде VSCode и WebStorm, позволяют автоматизировать импорт библиотек, но мне никогда не удавалось добиться с помощью этих механизмов результата, который бы меня полностью устраивал (я постоянно сталкивался с всякими неприятностями, вроде этой).

И ещё одно интересное наблюдение. Если применять TypeScript вместо Babel, то понадобится пользоваться конструкцией import * as React from ‘react’ (если только не включить allowSyntheticDefaultImports.

Эпоха хуков

Потом появились хуки и мой подход к разработке компонентов снова эволюционировал:

Всё это привело к очередной волне вопросов о том, как правильно импортировать React.

Есть два способа использования хуков:

Надо ли пользоваться именованными импортами, или можно просто напрямую сослаться на то, что нужно, обратившись к React? Я, опять же, предпочёл поступить так, чтобы мне не приходилось обновлять команды импорта каждый раз, когда я добавляю хуки в файлы или удаляю их. И, опять же, я не доверяю возможностям редакторов кода по автоматизации импортов. В результате я выбрал конструкцию React.useState , а не useState .

Новый подход к трансформации JSX, будущее React и ES-модули

Когда, наконец, вышла 17 версия React, серьёзных изменений в библиотеке не произошло, но было сообщено об интересном дополнении. Речь идёт о новом способе преобразования JSX, для применения которого не нужно импортировать React. Поэтому теперь можно писать следующий код:

Это компилируется в следующий код:

Теперь импорт того, что нужно, выполняется автоматически. Это очень хорошо, но это ещё и означает, что если планируется перевести некий проект на использование этой возможности, нужно будет убрать из него выражения import React from ‘react’ , которые использовались только для обеспечения поддержки JSX. К счастью, команда разработчиков React создала скрипт, автоматизирующий этот процесс. Им нужно было принять решение о том, что делать в ситуациях, когда пользуются хуками. Тут есть два варианта:

Оба эти подхода являются в наши дни рабочими, они правильны с технической точки зрения. Продолжат они работать и тогда, когда в React наконец появится официальная поддержка ES-модулей.

Команда React решила выбрать подход, связанный с использованием именованных импортов. Я не поддерживаю это решение по причинам, о которых говорил выше (речь идёт о необходимости постоянно менять команды импорта). Поэтому я решил пользоваться конструкцией import * as React from ‘react’ . Она, правда, длинная, набирать её долго, поэтому я написал такой сниппет:

Вот твит Дэна Абрамова, касающийся текущего состояния дел в области импорта React. А именно, речь идёт о том, что конструкции import < useState >from ‘react’ и import * as React from ‘react’ вполне современны, а конструкцией import React from ‘react’ , так называемым «импортом по умолчанию», лучше не пользоваться, так как в будущем (возможно, в React 19 или 20) команда React откажется от поддержки этой конструкции.

Итоги

Я в настоящее время пользуюсь import * as React from ‘react’ . Благодаря этому мне не нужно беспокоиться о применяемых мной командах импорта. Собственно говоря, только что вы прочли мой развёрнутый ответ на вопрос о том, как правильно импортировать React.

Источник

Ошибка при работе с React?

Failed to compile
src\components\app\app.js
Line 5:8: ‘TopComponent’ is not defined react/jsx-no-undef

Search for the keywords to learn more about each error.
This error occurred during the build time and cannot be dismissed.

В чем может быть проблема?

• Вопрос задан 01 мар.
• 177 просмотров

Line 5:8: ‘TopComponent’ is not defined react/jsx-no-undef

Что здесь написано? Перевели?

https://developer.mozilla.org/en-US/docs/Web/JavaS.

Не знаю. Я только начал практиковаться по Реакту

top-component.js
import React from ‘react’;

const TopComponent =() => <
return(

**Там Hi и Text обернуты в div. Без понятия куда они делись

export default TopComponent;

index.js (расположенный в папке top-component)
import TopComponent from ‘./top-component/’;
export default TopComponent;

App.js
import React from ‘react’;
const App =()=> <
return(

)
>
export default App;

**здесь App возвращает TopComponent. Тоже не знаю куда делся при вставке

index.js (Конечный файл из которого все рендерится)
import React from ‘react’;
import ReactDOM from ‘react-dom’;
import ‘./index.css’;
import App from ‘./components/app/app.js’;

Структура проекта

Источник

why does «import < React >from ‘react’;» not work? [duplicate]

Can anyone explain to me why

import < React >from ‘react’;

breaks everything, yet

import React from ‘react’;

works just fine? Aren’t they saying the same thing? I’ve tried to find an answer elsewhere in documentation and on the internet, but I can’t figure it out. I think it may have something to do with Babel?

Here are my npm packages if it helps:

4 Answers 4

import React from ‘react’

This essentially says «find the default export from the react module and import that as a constant that I want to call React .»

import < React >from ‘react’

This says «find the export from the react module which is explicitly named React , and import that here as a constant that I want to call React .»

Why doesn’t import < React >from ‘react’ work?

Because there isn’t an export named React in the react package. There is only a single default export. If you do this, you’ll find that React is undefined .

But it doesn’t even look like I use React in my code. So, couldn’t I just name it anything I want, like import Foobar from ‘react’ ?

No, sorry. You need to import the default and name it React . This is because anytime you write JSX code like or , this JSX code is transpiled and uses React.createElement() . So, you need to have access to React .

The difference is between default exports & named exports.

Default Exports

react.js

You can import the above file react.js in your project like

Named Exports

react.js

Then you have to import the above file react.js in your project like

TL;DR — Learn about Default Exports & Named Exports from here

According to mdn, imports work this way

What this basically means is that if a package exports something as a default, it should be imported without the <> , and with any name you choose. When when a package exports something as a named export, it should be used with the <> .

The react package exports React as a default and each package can have only one default export .

The second one works because it’s the default export from the React package. You can actually name it anything because there is only a single default export per module.

So, import RandomName from ‘react’; would have the same functionality.

Anything else exported is explicitly defined which is why the naming matters.

The other exports may look something like this:

To import it, you would do import < someFunction >from ‘./path’; . You can see that we’re destructuring (unpacking) the name from the export object.

Источник

Великий раскол в import: проясняем неопределенность с импортом в Typescript

Перевод статьи подготовлен в преддверии старта курса «Разработчик React.js»

Я довольно долго работаю с typescript, и у меня было много проблем с тем, чтобы разобраться с его модулями и советующими настройками, и должен сказать, вокруг них и вправду много непонятного. Пространства имен, import * as React from ‘react’ , esModuleInterop и т.д. Поэтому давайте разберемся из-за чего поднялась вся шумиха.

Я не буду говорить о пространствах имен как о модульной системе в typescript, поскольку идея оказалась не лучшей (особенно учитывая текущий вектор развития), и этим никто сейчас не пользуется.

Итак, как же обстояли дела до появления esModuleInterop ? Были почти все те же модули, что есть у babel или браузеров, а также именованные импорты/экспорты. Однако, в вопросах экспортов и импортов по умолчанию у typescript был свой собственный вариант: нужно было писать import * as React from ‘react’ (вместо import React from ‘react’ ), и, конечно, здесь речь не только о react, а обо всех импортах по умолчанию из commonjs . Как так вышло?

Чтобы в этом разобраться, давайте посмотрим, как работает совместимость между некоторыми паттернами в модулях commonjs и es6 . Например, у нас есть модуль, который экспортирует foo и bar в качестве ключей:

Мы можем сделать импорт с помощью require и деструктуризации:

И применить тот же принцип, используя именованный импорт (хотя, если по-честному, то это не деструктуризация):

Однако более распространенный паттерн в commonjs – это const myModule = require(‘my-module’) (потому, что деструктуризации еще не было), но как сделать это же в es6 ?

При разработке спецификации для импорта в es6 одним из важных аспектов была совместимость с commonjs , так как на commonjs было уже написано много кода. Вот так и появились импорт и экспорт по умолчанию. Да, единственной целью было обеспечивать совместимость с commonjs , чтобы мы могли писать import myModule from ‘my-module и получать ровно тот же результат. Однако из спецификаций это было неочевидно, и к тому же, реализация совместимости была прерогативой разработчиков транспайлера. И вот тут как раз и случился великий раскол: import React from ‘react’ или же import * as React from ‘react’ – вот в чем вопрос.

Почему typescript выбрал последнее? Поставьте себя на место разработчика транспайлера и спросите себя, как можно легче всего транспилировать импорты из es6 в commonjs ? Допустим, у вас есть следующий набор импортов и экспортов:

Итак, будем использовать объект js с ключом default для экспорта по умолчанию!

Круто, но как насчет совместимости? Если импорт по умолчанию означает, что мы возьмем поле с именем default , значит когда мы напишем import React from ‘react’ – это будет значить const < default: React >= require(‘react’) , но так не работает! Тогда вместо этого попробуем использовать импорт со звездочкой. Теперь пользователям придется писать import * as React from ‘react’ , чтобы добраться до содержимого module.exports .

Однако здесь есть семантическое отличие от commonjs .
Commonjs был как обычный javascript, не больше. Просто функции и объекты, без всяких require. С другой стороны, в импорте es6 , require сейчас часть спецификации, поэтому myModule в данном случае – это не просто обычный объект javascript, а то, что зовется пространством имен (не путать с namespaces в typescript), которое, соответственно, обладает определенными свойствами. Одно из них заключается в том, что пространство имен нельзя вызвать. И в чем же тут проблема, вы можете спросить?

Давайте опробуем другой паттерн commonjs , с одной функцией в качестве экспорта:

Мы можем воспользоваться require и выполнить ее:

Хотя если попытаетесь выполнить это в spec-complaint среде с модулями ES6, то получите ошибку:

Все потому, что пространство имен – это не то же самое, что объект javascript, а отдельная структура, хранящая каждый экспорт es6.

Но вот Babel понял все правильно и предоставил такой вариант совместимости, при котором мы можем написать import React from ‘react ‘ и это будет работать. При транспиляции он помечает каждый модуль es6 специальным флагом в module.exports , чтобы мы понимали, что если флаг истинный, то возвращается module.exports , а если ложный (например, если это библиотека commonjs , которая не была транспилирована), то нам нужно будет обернуть текущий экспорт в < default: export >, чтобы мы могли каждый раз использовать default (взгляните вот сюда).

Typescript пробивался за счет импортов со звездочками, но в итоге сдался и добавил опцию esModuleInterop в компилятор. В целом, эта опция делает то же самое, что и babel, и если вы ее включите, то можете написать обычный импорт как import React from ‘react’ , и typescript все поймет.

Проблема в том, что несмотря на то, что в новых проектах она включается по умолчанию (при выполнении tsc —init ), она не подойдет для уже существующих проектов (даже если вы обновитесь до TypeScript 3), потому что у нее нет обратной совместимости. Таким образом вам придется переписать ненужные импорты со звездочками на импорты по умолчанию. React отнесется к этому нормально, поскольку это все еще набор именованных экспортов, но не к примеру с вызовом пространства имен. Но не бойтесь, если с типизацией экспортов все в порядке (а с ними в большинстве своем все в порядке, поскольку множество из них исправляется автоматически), TypeScript 3 позволит вам быстро преобразовать импорт со звездочками к стандартному.

Поэтому я действительно выступаю за использование опции esModuleInterop , хотя бы потому что она не только позволят вам писать меньше кода и облегчает его чтение (и это не просто слова, например, rollup не позволит вам так использовать импорты со звездочками), но и уменьшает разногласия между сообществами typescript и babel.

Предостережение: раньше существовала опция enableSyntheticDefaultImports , которая затыкала рот компилятору, когда он пытался пожаловаться на неправильный импорт по умолчанию, поэтому нам понадобился собственный способ обеспечивать совместимость с commonjs (например, WebpackDefaultImportPlugin ), но это было проблемно, поскольку, например, если у вас есть тесты, то вам все еще нужно обеспечивать такую совместимость. Обратите внимание, что esModuleInterop включает синтетический импорт по умолчанию только в случае, если ваш цель ES5. Поэтому если вы включите эту опцию, а компиляторы продолжат жаловаться на import React , то поймите, какую цель вы преследуете, и, возможно, включение импортов по умолчанию будет вашим вариантом (или же перезапуск vscode/webstorm, кто знает).

Надеюсь, мое объяснение хоть немного прояснило ситуацию, но если у вас остались вопросы, вы можете задать мне их в twitter!

Источник