Конечно конечно, писать каждый раз проверки внутри функции, что входная переменная является числом вместо того, чтобы сразу типизировать аргумент безусловно быстрее и полезнее для разработчика. Это так весело в чистом JS писать instanceof и typeof. А аргумент по отстрел ноги просто великолепен! А для чего по вашему существуют типы в других языках? Ровно для этого, чтобы все вызывалось с нужными параметрами и не ломалось. Никто не пишет без нужды параметр как dynamic. А если аргументом является функция вы как проверяете ее сигнатуру, если не секрет? А если ее параметром будет сложный объект? Мне на TS потребуется ровно минута, а вам ?
Да ничего он не убивает. Просто это язык не для вкатышей в IT, которым надо все и сразу, и быстро. У него есть определенный высокий порог вхождения, но потом уже этого не замечаешь. Вас послушать, тогда и С# убивает производительность да? Там тоже типы, там тоже дженерики, там тоже надо сигнатуры функций правильно описывать. Я не сравниваю TS и Шарп, но принцип один. Это вы ещё на С+ не писали. Нервы у него видите ли...
Используйте readonly по умолчанию, это позволит избежать случайного перезаписывания типов в вашем интерфейсе
Поправочка, не в интерфейсе, а в объекте заданного типа. На этапе компиляции будет проведена проверка, что вы пытаетесь присвоить значение свойству, которое указано как readonly.
И стоит добавить сюда описание что такое type и что такое interface. В чем между ними основная разница и что предпочтительнее использовать. К сожалению, последнее мало кто понимает.
Я бы сказал проблема молодых "я же программист" не решена. Пишем на реакте сложные приложения и при грамотной декомпозиции приложения никогда не возникало проблем с обновлением всего дерева разом. Конечно, если писать компоненты на 500 строк кода, то потом легко говорить, что реакт фуфло и к него проблемы с обновлением
И насколько это на сегодняшний день актуально? Чем настолько принципиально отличаются типы и интерфейсы, что возникает потребность в префиксах? Мы давно отказались от такого нейминга и, проверьте, стало только проще.
Ну так область-то применения этого браузера какая? Когда мы продукт разрабатывали, он нам нужен был чтобы в толстом клиенте веб страницы поднимать - так проще было функционал развивать. Но это только десктоп, для всего остального есть нативный хром. К чему я это говорю, что за ним сомнительное будущее, извините лично мое мнение. Мы уже наелись с ним, не говоря уже о том, что если надо открыть несколько окон, то это отдельные процессы, а не отдельные вкладки...
Очередная попытка натянуть сову на глобус. Они столько лет пытаются и свой браузер сделать и UI Kit, что это уже просто смешно. Писал я на qml. Соглашусь, для десктопа вполне приемлемо, но это все поделки и не более. Нормальной поддержки сертификатов нет, сервис воркеры работают с ограничениями и очень медленно. Пресловутый JsEngine это обрезанный функционал нормального браузерного API Если нужно что-то новое придется обновлять кор версию QT. Если ТС использует компоненты, то понятно что под капотом тем плюсовая обвязка, которая ещё и кроссплатформенно зависимая. Далее, нет поддержки сторонних js библиотек. Все ошибки браузера вы должны обрабатывать ручками на тех же плюсах. А так да, вещь хорошая.
Конечно конечно, писать каждый раз проверки внутри функции, что входная переменная является числом вместо того, чтобы сразу типизировать аргумент безусловно быстрее и полезнее для разработчика. Это так весело в чистом JS писать instanceof и typeof. А аргумент по отстрел ноги просто великолепен! А для чего по вашему существуют типы в других языках? Ровно для этого, чтобы все вызывалось с нужными параметрами и не ломалось. Никто не пишет без нужды параметр как dynamic. А если аргументом является функция вы как проверяете ее сигнатуру, если не секрет? А если ее параметром будет сложный объект? Мне на TS потребуется ровно минута, а вам ?
Да ничего он не убивает. Просто это язык не для вкатышей в IT, которым надо все и сразу, и быстро. У него есть определенный высокий порог вхождения, но потом уже этого не замечаешь. Вас послушать, тогда и С# убивает производительность да? Там тоже типы, там тоже дженерики, там тоже надо сигнатуры функций правильно описывать. Я не сравниваю TS и Шарп, но принцип один. Это вы ещё на С+ не писали. Нервы у него видите ли...
Поправочка, не в интерфейсе, а в объекте заданного типа. На этапе компиляции будет проведена проверка, что вы пытаетесь присвоить значение свойству, которое указано как readonly.
И стоит добавить сюда описание что такое type и что такое interface. В чем между ними основная разница и что предпочтительнее использовать. К сожалению, последнее мало кто понимает.
Используйте тип напрямую в определении функции вместе с деструктуризацией
Все отлично, но зачем вы везде используете React.FC ? Признано устаревшим в т.ч. и в 18 реакте.
Это вторая проблема "молодых" - они не умеют читать документацию, рекомендации и стайлгайды по написанию кода
Я бы сказал проблема молодых "я же программист" не решена. Пишем на реакте сложные приложения и при грамотной декомпозиции приложения никогда не возникало проблем с обновлением всего дерева разом. Конечно, если писать компоненты на 500 строк кода, то потом легко говорить, что реакт фуфло и к него проблемы с обновлением
И насколько это на сегодняшний день актуально? Чем настолько принципиально отличаются типы и интерфейсы, что возникает потребность в префиксах? Мы давно отказались от такого нейминга и, проверьте, стало только проще.
Ну так область-то применения этого браузера какая? Когда мы продукт разрабатывали, он нам нужен был чтобы в толстом клиенте веб страницы поднимать - так проще было функционал развивать. Но это только десктоп, для всего остального есть нативный хром. К чему я это говорю, что за ним сомнительное будущее, извините лично мое мнение. Мы уже наелись с ним, не говоря уже о том, что если надо открыть несколько окон, то это отдельные процессы, а не отдельные вкладки...
Очередная попытка натянуть сову на глобус. Они столько лет пытаются и свой браузер сделать и UI Kit, что это уже просто смешно. Писал я на qml. Соглашусь, для десктопа вполне приемлемо, но это все поделки и не более. Нормальной поддержки сертификатов нет, сервис воркеры работают с ограничениями и очень медленно. Пресловутый JsEngine это обрезанный функционал нормального браузерного API Если нужно что-то новое придется обновлять кор версию QT. Если ТС использует компоненты, то понятно что под капотом тем плюсовая обвязка, которая ещё и кроссплатформенно зависимая. Далее, нет поддержки сторонних js библиотек. Все ошибки браузера вы должны обрабатывать ручками на тех же плюсах. А так да, вещь хорошая.