Почему я использую инлайн типизацию React компонентов
ฝัง
- เผยแพร่เมื่อ 8 ก.ย. 2024
- Понимаю что это выгладит непривычно. Но просто попробуйте написать так пару компонентов, может вам понравится
Почему FC выпилили из create-react-app: github.com/fac...
Подписывайтесь на мой telegram канал:
t.me/cleanfron...
![Warhammer 40k: Space Marine 2 | เพื่อจักรพรรดิ ! [ตอนเดียวจบ]](http://i.ytimg.com/vi/4M0ckYMA4-U/mqdefault.jpg)
Тоже занимался такими изысканиями, но всё же пришёл к выводу, что мне визуально приятнее вынести интерфейс компонента куда-то вверх или вообще в отдельный файл, если типы модульные. Вдобавок, если у нас всякие экстенды появляются, в инлайн типизации начинает мозолить глаза наращивание скобочек
Мне тоже нравится то что делаешь крутой очень опыт, крутая информация, очень полезно, интересно послушать человека со своим подходом.
На счёт рефакторинга, можно выделить название компонента, нажать shift+Ctrl+l , это выделит всё вхождения по файлу и ввести нужный, так мы не забудем ничего поменять, не нужно в ручную искать.
Странно что вы в видео утверждаете что как-то делать "Плохо". Это не плохо, а по другому, всё сказанное в видео просто дело соглашений и код-стайла в проете. Настраивается 2-3 правилами линта. Типы отдельным объектом всё же удобней выносить, так как они почти всегда будут иметь составные части, обёртки, дженерики. Зачем это всё мешать в разметку? Банально приятней читать когда: контракт -> реализация
Экспортировать типы из компонентов отвечающих за бизнес логику не надо, по этому просто называйте их Props. Это именно то название которому они соответствуют.
В ui компонентах тоже не надо называть ComponentProps, сделайте файл для ре-экспорта и там экспортируйте только то что вам надо и с какими надо именами. Например export type {Props as ButtonProps} from './button'. (о public API можно узнать в FSD архитектуре).
Про типизиацию пропсов согласен, не надо никаких FC и писать тип возвращаемого значение тоже не стоит, тайпскрипт сам прекрасно выведет этот тип.
Со всем согласен, но хотелось бы ещё добавить, что при создании нового компонента ненадо каждый раз всё писать с нуля, поскольку можно использовать соответствующий сниппет (самому написать под кодстайл проекта). А там уже неважно сколько "лишнего" кода будет.
Спасибо! супер контент! делишься опытом реальной разработки, интересные видео!
Коротко и интересные мысли!
Привет, Евгений!
Спасибо за видео. Мне, начинающему разрабу, очень полезны твои видео. В команде я один на фронтенде и это первая моя работа. Так что стараюсь не упускать такие видео, где поясняют как лучше писать код. Как раз сейчас решил с нового проекта использовать TS.
Поясни пожалуйста подробнее об экспорте. Ты упомянул, что экспорт по дефолту ты не рекомендуешь. Хотя без него сложно обойтись если используешь Suspense компонент для ленивой загрузки.
Для ленивой загрузки JS модулей не обойтись без экспорта по умолчанию. Но обычно это делается для модулей, которые являются "страницами". Во всех остальных случаях, лучше использовать именной экспорт.
Привет! Как раз по этому поводу сегодня видео сделаю)
Тоже встраиваю типы, но прописываю возвращаемое значение что бы сразу видеть ошибку, а не в момент использования.
Могу привести один пример, когда экспорт типа из компонента полезен - для типизации аргументов storybook (если у тебя он есть в проекте, конечно. Если нет, то рекомендую начать использовать). Разумеется, можно по-твоему сделать, но тогда придется доставать тип пропсов с помощью React.ComponentProps, что уже не так удобно, но всё еще остается валидным вариантом
Я в видео вроде говорил, что внешние типы хороши как раз для uikit компонентов и библиотечных компонентов. И пример со сторибуком как раз про это.
А, без сниппетов вообще грустно жить
5:00 кто мешаешь использовать Pick
Преттиер не удаляет запятую в дженериках в .tsx файлах, а вот в .ts удаляет. Впрочем, всегда можно написать , тут и запятая ненужна.
Если так, отлично!
Пойду перепроверю ещё раз, спасибо)
Ну очень на любителя идея инлайнить типы.
На мой взгляд читаемость сильно страдает, разметка смешивается с контрактом. Более того если у вас какие нибудь полиморфные типы с дженериками будут использоваться, заворачивать их в инлайн типы будет проблематично, а это значит что код будет неоднородным, где-то инлайн, где-то нет.
В общем так и не понял какую проблему вы решаете инлайном типов, из разумных аргументов услышал только кейс с рефакторингом компонента, когда переименовали компонент, но забыли поправить тип, но я думаю если это является большой проблемой наверняка можно правило для линтера написать чтобы отслеживать такие кейсы.
Еще если писать типы сразу инлайном то когда наводишь мышку на компонент сразу видно какие пропсы ожидает. Иначе видишь просто название своего типа или интерфейса, и что с ним делать ? как то тупо получается... Для меня это вообще основная причина писать инлайном типа для пропсов.
это зависит от IDE и настроек самой IDE
@@lorandemarcus а как такое в vscode настроить не подскажите?
@@avikbox в вскоде это по умолчанию. Просто надо деструктуризировать пропсы сразу в аргументах.
Интересная идея. Предлагаю не использовать деструктуризацию пропсов. Писать props: {/* типы */} читаемость возрастет
ts в реакте? Да вы месье извращенец
?
скорее это ты просто слабоумный