контекст: automation qa який вчить js (поки досвід тільки з cypress), перша мова пайтон. Поки взагалі не розумію бенефіт від ts. Мабуть для складних фронтенд проектів справді зручно, але переваг для автотестів ( якщо гарно задизайнено) не бачу. З динамічною типізацією ніколи не мав проблем
Якщо я все правильно розумію то в QA automation трохи інша специфіка. Сценарії більш-менш лінійні і, головне, не залежні. (виправте якщо помиляюся) На фронті, нажаль, воно часто не так. + Код далеко не завжди ідеальний, очевидний і зрозумілий. Тут TS дуже допомагає.
Добрий день, можете пояснити таке питання. Навіщо пишеться в трикутних дужках тип Т в цій конструкції interface Named { name: string; value: T; } Хіба ми не можемо описати просто тип Т раніше, а інтерфейс написати так: interface Named { name: string; value: T; }
В першому випадку це узагальнений (generic) тип. Завдяки трикутним дужкам ми можемо зробити так: type WithValue = {value: T}; type NumericValue = WithValue type StringValue = WithValue Тобто ми не дублюємо самі себе
У нас буде маленька лекція про тестування в React 25.05.22 на цьому каналі - підписуйтесь. Якщо ж цікавить саме TDD - приєднуйтесь до каналу в t.me/reactbeginners і агітуйте людей. Будуть бажаючі - будемо думати
Якщо чесно, не розумію взагалі приколу тайпскрипта хоч й 4 роки вже працюю. як така заміна документації? ну ок, але можна одразу нормальну документацію писати. Перевірка аби в коді неправильно чогось не написали? ну для цього є код ревью від команди й тести. А якщо цього нема, але є продвинутий тайпскрипт з Дженериками - то це якась дичина а не проект. Більш зрозуміло для нових програмістів? знов - документація, рідмі й сам код по собі читабельним має бути. Натомість ми маємо купу зайвого коду для програміста, превірки вхідних данних в ф-ї хоча це по замовченню повинно бути в норм коді - в вас ф-я приймає те що не треба- ловіть Ексепшн Й вишенкою - маємо джаваскріпт код котрий при перетворені в байт код НЕ дозволяє тепер робити купу оптимізацій
Якщо за 4 роки ви не побачили користі від TS, то може для вас його і не має. Тут вже стільки списів зламано, що, напевне, дискутувати просто немає сенсу.
Чудово, що є такі як ви. Це безкоштовний контент, проте цінніший та крутіший за багато платних. Ще й солов'їною, дякую вам !)
Дякую безмежно. Лекції чудові, легкі для розуміння, без води.
Круто дякую вам за вашу працю, залишилося тільки знайти в собі сили.
Знайдете, аби бажання)
треба більше і більше українського айті контенту!!! Лайк і підписка!
Дякую!
❤❤❤
контекст: automation qa який вчить js (поки досвід тільки з cypress), перша мова пайтон. Поки взагалі не розумію бенефіт від ts. Мабуть для складних фронтенд проектів справді зручно, але переваг для автотестів ( якщо гарно задизайнено) не бачу. З динамічною типізацією ніколи не мав проблем
Якщо я все правильно розумію то в QA automation трохи інша специфіка. Сценарії більш-менш лінійні і, головне, не залежні. (виправте якщо помиляюся)
На фронті, нажаль, воно часто не так. + Код далеко не завжди ідеальний, очевидний і зрозумілий. Тут TS дуже допомагає.
56:30 А є запис обговорення рендеру кораблів? Не знайшов.
Ось відео ruclips.net/video/HIViZ_O6ctY/видео.html
@@reactdev ооо, дуже дякую!
Добрий день, можете пояснити таке питання. Навіщо пишеться в трикутних дужках тип Т в цій конструкції
interface Named {
name: string;
value: T;
}
Хіба ми не можемо описати просто тип Т раніше, а інтерфейс написати так:
interface Named {
name: string;
value: T;
}
В першому випадку це узагальнений (generic) тип. Завдяки трикутним дужкам ми можемо зробити так:
type WithValue = {value: T};
type NumericValue = WithValue
type StringValue = WithValue
Тобто ми не дублюємо самі себе
Дякую!
Чи можливо вас попросити якось зробити лекцію по TDD. По тестам дуже мало інформації в мережі.
У нас буде маленька лекція про тестування в React 25.05.22 на цьому каналі - підписуйтесь.
Якщо ж цікавить саме TDD - приєднуйтесь до каналу в t.me/reactbeginners і агітуйте людей. Будуть бажаючі - будемо думати
Якщо чесно, не розумію взагалі приколу тайпскрипта хоч й 4 роки вже працюю.
як така заміна документації? ну ок, але можна одразу нормальну документацію писати.
Перевірка аби в коді неправильно чогось не написали? ну для цього є код ревью від команди й тести. А якщо цього нема, але є продвинутий тайпскрипт з Дженериками - то це якась дичина а не проект.
Більш зрозуміло для нових програмістів? знов - документація, рідмі й сам код по собі читабельним має бути.
Натомість ми маємо купу зайвого коду для програміста, превірки вхідних данних в ф-ї хоча це по замовченню повинно бути в норм коді - в вас ф-я приймає те що не треба- ловіть Ексепшн
Й вишенкою - маємо джаваскріпт код котрий при перетворені в байт код НЕ дозволяє тепер робити купу оптимізацій
Якщо за 4 роки ви не побачили користі від TS, то може для вас його і не має. Тут вже стільки списів зламано, що, напевне, дискутувати просто немає сенсу.