этот плейлист просто огонь, показываешь много нового, даже при том что 2 года на тайпскрипте пишу уже насчёт хака с memo и forwardRef, всё конечно правильно но лучше не создавать функцию typedMemo а переопределить через declare тип у функции memo из React переопределять через declare типы из библиотек это нормальная практика, это необходимо например в tanstackRouter-е для полного инфера типов всех твоих роутов
Аюб контент просто ТОП! Спасибо) а по реакт хук форм что-нибудь с продвинутыми кейсами + типизация не планируешь снять?) было бы очень интересно посмотреть))
Спасибо за интересный ролик, кстати, мне кажется в видео не совсем классическое использование RenderProps, обычно функцию передают не как children, а как проп функцию, внутри самого тега. Было очень интересно увидеть новую для меня реализацию (function as children), и вообще тема паттернов очень интересна, с удовольствием бы посмотрела видео с их практическим применением.
Да, обычно под render prop подразумевают передачу функции именно в пропсы, но с children, как мне кажется удобнее. Про видео по паттернам - записал себе, нужно будет заснять.
а то везде только база в основном по реакт хук форм, а у тебя интересные примеры всегда, я так понимаю берешь их из своего опыта, с чем уже сталкивался, если вдруг работал с этой либой было бы круто если есть чем поделиться на основе своего опыта)
Если необходимо передать дженерики в компонент обернутый React.memo использую type casting - "export default memo(SomeComponent) as typeof SomeComponent;"
Дело в том, что memo(SomeComponent) и typeof SomeComponent это разные вещи, ты пытаешься один тип перевести в другой, которым он не является, если используешь as, это принудительное приведение типа, в том то и смысл, чтобы работать с typescript без принудительного приведения типа по тем правилам, которые заложены в саму концепцию ts.
22:06 имхо, для кнопки лучше брать сразу реактивский тип `ButtonHTMLAttributes`, из `Pick`ать из него только нужные атрибуты, чтобы подсказок в пропсах было немного (коллеги могут растеряться от обилия их). 30:16 а для кнопок, которые семантически выполнят роль ссылки я обычно от `[href]` решаю чем ей быть, а не делаю пропс `as`. Просто если это ссылка, то обычно внутри нужно решать это внешняя ссылка или внутренняя и если внутренняя то оборачивать ещё в компонент роутера на проекте (`react-router-dom` или `Next.js` к примеру)
Тут на самом деле нету правильного/неправильного подхода. Все зависит от ситуации. Многие ui библиотеки берут все из пропсов нативных элементов (button, div etc.), так как кейсы могут быть разные. Если что-то локальное, то можно и пикать, не знаю, будет ли это проблемой, если много подсказок?. По поводу пропса `as` - я не говорю, что это нужно делать. Понятное дело, что у всего есть свои плюсы и минусы. Однако я думаю для универсальной библиотеки компонентов - это не плохое решение. В данном случае цель была описать именно типизацию определенного подхода, а использовать его или нет - тема совсем другая)
У обходных решений с memo и forwardRef есть фатальный недостаток: не будет типизации свойств компонента вроде displayName. И это никак не обойти. А displayName очень полезен для отладки. Суть проблемы же в том, что сами по себе forwardRef с memo типизированы через унаследованные интерфейсы, а Тайпскрипт не поддерживает дженерики в таком случае (мол, дорого считать). И если с memo можно просто привести тип, то вместо forwardRef лучше использовать отдельное ref-свойство вроде innerRef. По этой же причине нет смысла переопределять их типизацию глобально, а то и вообще переопределять. С типизацией useRef всё очевидно: основное его использование - это получение ссылки на html-элементы, поэтому сделали такую типизацию, что при null в значении по умолчанию ТС не давал бы его случайно переопределить. Впрочем, мне это никогда не помогало.
А почему никак не обойти? Можно же руками добавить эти свойства к фукнции в return type. Просто в видео я этот момент не рассмотрел. Вот ссылка на плейграунд с примером - tsplay.dev/wO1olm
Спасибо за полезную информацию и качественный ролик со ссылками и таймкодами.
Не за что!
очень крутая инфа, спасибо!
Рад, что было полезно.
Лайк автоматом, хоть и выбрал backend на js
Спасибо!
Оч крепко. Сложно, но интересно) спасибо
Рад, что понравилось!
комментарий в поддержку канал❤
Спасибо!
Сначала лайк, потом смотреть)
Я тоже всем рекомендую так делать!)
Спасибо!
Лайк поставил, посмотрю позже) Спасибо за контент!
Спасибо большое!
Огромное спасибо!
Не за что)
Автор молодчага, все доступно объясняет. Желаю процветания каналу.
Спасибо!
Большое спасибо! Лучший!
Спасибо за поддержку!
Ещё не смотрел, но автору большое Спасибо за его работу
Спасибо за поддержку!
Спасибо за урок. Много нового и полезного для себя открыл)
Рад, что было полезно!
Делаешь крутой и полезный контент! Успехов тебе и нескончаемого потока мотивации😊
Спасибо, Ярослав!
этот плейлист просто огонь, показываешь много нового, даже при том что 2 года на тайпскрипте пишу уже
насчёт хака с memo и forwardRef, всё конечно правильно
но лучше не создавать функцию typedMemo
а переопределить через declare тип у функции memo из React
переопределять через declare типы из библиотек это нормальная практика,
это необходимо например в tanstackRouter-е для полного инфера типов всех твоих роутов
Я лично не люблю через declare перезаписывать. Но вариант тоже рабочий.
Спасибо!
не за что!
комментарий в поддержку канала
Спасибо!
Спасибо, ты большой молодец
Спасибо!
Крутой видос, вроде и работаю достаточно долго с тайпскриптом, но как-то не задумывался до этого момента о подобной типизации
Рад, что понравилось!
Спасибо
Пожалуйста!
Аюб контент просто ТОП! Спасибо) а по реакт хук форм что-нибудь с продвинутыми кейсами + типизация не планируешь снять?) было бы очень интересно посмотреть))
Спасибо за интересный ролик, кстати, мне кажется в видео не совсем классическое использование RenderProps, обычно функцию передают не как children, а как проп функцию, внутри самого тега. Было очень интересно увидеть новую для меня реализацию (function as children), и вообще тема паттернов очень интересна, с удовольствием бы посмотрела видео с их практическим применением.
Да, обычно под render prop подразумевают передачу функции именно в пропсы, но с children, как мне кажется удобнее. Про видео по паттернам - записал себе, нужно будет заснять.
мощно, да
👏👍
Спасибо!
а то везде только база в основном по реакт хук форм, а у тебя интересные примеры всегда, я так понимаю берешь их из своего опыта, с чем уже сталкивался, если вдруг работал с этой либой было бы круто если есть чем поделиться на основе своего опыта)
Спасибо за видео!
Пробовал описанный в видео компонент Button использоватьт с next/link? Home
Если необходимо передать дженерики в компонент обернутый React.memo использую type casting - "export default memo(SomeComponent) as typeof SomeComponent;"
Так тоже можно)
Дело в том, что memo(SomeComponent) и typeof SomeComponent это разные вещи, ты пытаешься один тип перевести в другой, которым он не является, если используешь as, это принудительное приведение типа, в том то и смысл, чтобы работать с typescript без принудительного приведения типа по тем правилам, которые заложены в саму концепцию ts.
крутое видео, а можешь какие нибудь кейсы интересные из тестирования разобрать?
Записал себе, постараюсь сделать скоро!
22:06 имхо, для кнопки лучше брать сразу реактивский тип `ButtonHTMLAttributes`, из `Pick`ать из него только нужные атрибуты, чтобы подсказок в пропсах было немного (коллеги могут растеряться от обилия их).
30:16 а для кнопок, которые семантически выполнят роль ссылки я обычно от `[href]` решаю чем ей быть, а не делаю пропс `as`. Просто если это ссылка, то обычно внутри нужно решать это внешняя ссылка или внутренняя и если внутренняя то оборачивать ещё в компонент роутера на проекте (`react-router-dom` или `Next.js` к примеру)
Тут на самом деле нету правильного/неправильного подхода. Все зависит от ситуации.
Многие ui библиотеки берут все из пропсов нативных элементов (button, div etc.), так как кейсы могут быть разные. Если что-то локальное, то можно и пикать, не знаю, будет ли это проблемой, если много подсказок?.
По поводу пропса `as` - я не говорю, что это нужно делать. Понятное дело, что у всего есть свои плюсы и минусы. Однако я думаю для универсальной библиотеки компонентов - это не плохое решение.
В данном случае цель была описать именно типизацию определенного подхода, а использовать его или нет - тема совсем другая)
Обернул компонент в HOC. Потом использую его в рендеринг списка, и проп key в нём уже отсутсвует. С точки зрения типизации.
Спасибо за контент.
Хммм, вот это странно. Ты же можешь передать key в любой компонент. Не покажешь пример, где это не работает?
интересно почему не предусмотрены эти компоненты обертки с под коробки для консистентности мемо и форвард рефов: вроде распространенный кейс
Так как типизация react поддерживается комьюнити, а не самой командой.
У обходных решений с memo и forwardRef есть фатальный недостаток: не будет типизации свойств компонента вроде displayName. И это никак не обойти. А displayName очень полезен для отладки. Суть проблемы же в том, что сами по себе forwardRef с memo типизированы через унаследованные интерфейсы, а Тайпскрипт не поддерживает дженерики в таком случае (мол, дорого считать). И если с memo можно просто привести тип, то вместо forwardRef лучше использовать отдельное ref-свойство вроде innerRef. По этой же причине нет смысла переопределять их типизацию глобально, а то и вообще переопределять.
С типизацией useRef всё очевидно: основное его использование - это получение ссылки на html-элементы, поэтому сделали такую типизацию, что при null в значении по умолчанию ТС не давал бы его случайно переопределить. Впрочем, мне это никогда не помогало.
А почему никак не обойти? Можно же руками добавить эти свойства к фукнции в return type. Просто в видео я этот момент не рассмотрел.
Вот ссылка на плейграунд с примером - tsplay.dev/wO1olm
😳🚑🚑🚑🚒🚒🚒👍👍👍
понял процентов 10% :(
лучше, чем ничего))
Wow super content about TypeScript and React! ❤
Thank you!