g
создал директорию ui или components, в ней точку входа создал и оттуда
export {Button} from ‘./button’Так мне уже подсказали выше
Size: a a a
2020 March 10
g
У нас на работе такая структура, и мне привычнее так писать стало.
m
ну с Богом, тогда. Лишь бы нравилось.
NG
создал директорию ui или components, в ней точку входа создал и оттуда
export {Button} from ‘./button’Можно так
export * from 'hello'
export * from 'hello'
g
Я думаю еслиб react-app из коробки хавал клнфиги бабеля такой проблемы не возникло...
ОХ
Когда ты тыкаешь Refactor в идее/шторме и у тебя нет дефолтных экспортов он в любой дыре найдет все упоминания каждого имени и все прекрасно заменит
ОХ
Дефолтные экспорты ломают цепочку эту, и все что под ними -- надо переименовывать руками
g
Та же проблема с декораторами
ОХ
Ну и конечно ты потом не будешь удивляться, почему в коде import Table from './Button'
ОХ
Это конечно на ревью надо ловить, но не хочется на это время тратить
ОХ
После этого можно еще экспорты в конце писать, чтобы вместо
export const a =
const b
const d
export const c =
писать
export { a, b }
и сразу видеть, что доступно другим, а что нет
export const a =
const b
const d
export const c =
писать
export { a, b }
и сразу видеть, что доступно другим, а что нет
m
Подскажите плиз, кто нибудь работал с oData? Чем вы конвертировали oData?
PM
я вообще про него забыл и юзаю исключительно именованные экспорты.
а почему бы нет?
PM
вся возня против export default началась вообще из-за вебпака и его особых отношений с ES модулями
m
Перечитай пожалуйста выше сообщения Олега. Тут не про вебпак разговор.
AM
Спасибо))
PM
Перечитай пожалуйста выше сообщения Олега. Тут не про вебпак разговор.
Так наоборот одна из фишек default экспорта - это возможность сразу дать имя применительно к доменной области, например:
import ProductsList from 'ListView';
PM
с именнованными экспортами тоже можно, но конструкция более неуклюжая
PM
Перечитай пожалуйста выше сообщения Олега. Тут не про вебпак разговор.
я просто вспомнил откуда возникла рекомендация не юзать их