Почему я использую инлайн типизацию React компонентов

Понимаю что это выгладит непривычно. Но просто попробуйте написать так пару компонентов, может вам понравится
Почему FC выпилили из create-react-app: github.com/fac...
Подписывайтесь на мой telegram канал:
t.me/cleanfron...

[@jamesull]

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

[@webDever]

Мне тоже нравится то что делаешь крутой очень опыт, крутая информация, очень полезно, интересно послушать человека со своим подходом. На счёт рефакторинга, можно выделить название компонента, нажать shift+Ctrl+l , это выделит всё вхождения по файлу и ввести нужный, так мы не забудем ничего поменять, не нужно в ручную искать.

[@АнатолийГорбов-о1ь]

Спасибо! супер контент! делишься опытом реальной разработки, интересные видео!

[@izzy7541]

Странно что вы в видео утверждаете что как-то делать "Плохо". Это не плохо, а по другому, всё сказанное в видео просто дело соглашений и код-стайла в проете. Настраивается 2-3 правилами линта. Типы отдельным объектом всё же удобней выносить, так как они почти всегда будут иметь составные части, обёртки, дженерики. Зачем это всё мешать в разметку? Банально приятней читать когда: контракт -> реализация Экспортировать типы из компонентов отвечающих за бизнес логику не надо, по этому просто называйте их Props. Это именно то название которому они соответствуют. В ui компонентах тоже не надо называть ComponentProps, сделайте файл для ре-экспорта и там экспортируйте только то что вам надо и с какими надо именами. Например export type {Props as ButtonProps} from './button'. (о public API можно узнать в FSD архитектуре). Про типизиацию пропсов согласен, не надо никаких FC и писать тип возвращаемого значение тоже не стоит, тайпскрипт сам прекрасно выведет этот тип.

[@BOCbMOU]

Со всем согласен, но хотелось бы ещё добавить, что при создании нового компонента ненадо каждый раз всё писать с нуля, поскольку можно использовать соответствующий сниппет (самому написать под кодстайл проекта). А там уже неважно сколько "лишнего" кода будет.

[@RamaRama-qv3jo]

Коротко и интересные мысли!

[@paemox]

Тоже встраиваю типы, но прописываю возвращаемое значение что бы сразу видеть ошибку, а не в момент использования.

[@krowker]

Привет, Евгений! Спасибо за видео. Мне, начинающему разрабу, очень полезны твои видео. В команде я один на фронтенде и это первая моя работа. Так что стараюсь не упускать такие видео, где поясняют как лучше писать код. Как раз сейчас решил с нового проекта использовать TS. Поясни пожалуйста подробнее об экспорте. Ты упомянул, что экспорт по дефолту ты не рекомендуешь. Хотя без него сложно обойтись если используешь Suspense компонент для ленивой загрузки.

[@adamburke4496]

Для ленивой загрузки JS модулей не обойтись без экспорта по умолчанию. Но обычно это делается для модулей, которые являются "страницами". Во всех остальных случаях, лучше использовать именной экспорт.

[@paromovevg]

Привет! Как раз по этому поводу сегодня видео сделаю)

[@Andreitrenkal]

Могу привести один пример, когда экспорт типа из компонента полезен - для типизации аргументов storybook (если у тебя он есть в проекте, конечно. Если нет, то рекомендую начать использовать). Разумеется, можно по-твоему сделать, но тогда придется доставать тип пропсов с помощью React.ComponentProps, что уже не так удобно, но всё еще остается валидным вариантом

[@paromovevg]

Я в видео вроде говорил, что внешние типы хороши как раз для uikit компонентов и библиотечных компонентов. И пример со сторибуком как раз про это.

[@webDever]

А, без сниппетов вообще грустно жить

[@undertale-15075O]

5:00 кто мешаешь использовать Pick

[@BOCbMOU]

Преттиер не удаляет запятую в дженериках в .tsx файлах, а вот в .ts удаляет. Впрочем, всегда можно написать , тут и запятая ненужна.

[@paromovevg]

Если так, отлично! Пойду перепроверю ещё раз, спасибо)

[@kryptamine]

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

[@avikbox]

Еще если писать типы сразу инлайном то когда наводишь мышку на компонент сразу видно какие пропсы ожидает. Иначе видишь просто название своего типа или интерфейса, и что с ним делать ? как то тупо получается... Для меня это вообще основная причина писать инлайном типа для пропсов.

[@lorandemarcus]

это зависит от IDE и настроек самой IDE

[@avikbox]

@@lorandemarcus а как такое в vscode настроить не подскажите?

[@BOCbMOU]

@@avikbox в вскоде это по умолчанию. Просто надо деструктуризировать пропсы сразу в аргументах.

[@mnik0128]

Интересная идея. Предлагаю не использовать деструктуризацию пропсов. Писать props: {/* типы */} читаемость возрастет

[@catbarsic]

ts в реакте? Да вы месье извращенец

[@АлексейСоколов-у3к]

?

[@тимур_атмосферный]

скорее это ты просто слабоумный