@react_js - страница 680 - Telegram web archive

Гайз подскажите кто знает Юзаю react + redux-saga + typescritp И смущает, что я описываю типы аргументов экшена и тип того что он возращает, и при этом приходится описывать тот же экшент что он возращает и в аргументе который принимает сага и когда конекчу компонет к ридаксу в интерфейсе пропросов нужно так же описать какие аргументы он принимает Нельзя ли как-то это засэтапить что бы не приходилось одно и тоже писать везде, а что бы тайпскрип понимал что это экшен и что раз он обрабатывается этой сагой то в агрументах будет он и то же самое с пропсами

Evgeny

Гайз подскажите кто знает Юзаю react + redux-saga + typescritp И смущает, что я описываю типы аргументов экшена и тип того что он возращает, и при этом приходится описывать тот же экшент что он возращает и в аргументе который принимает сага и когда конекчу компонет к ридаксу в интерфейсе пропросов нужно так же описать какие аргументы он принимает Нельзя ли как-то это засэтапить что бы не приходилось одно и тоже писать везде, а что бы тайпскрип понимал что это экшен и что раз он обрабатывается этой сагой то в агрументах будет он и то же самое с пропсами

создать новый тип не и везде его ипользовать? или я не понимаю вопроса?

Max

ну так и делаю

Max

просто хотелось бы что бы тс и так поимал что происходит

Max

и где что приходит

Evgeny

просто хотелось бы что бы тс и так поимал что происходит

а, ты хочешь, чтобы тс стал обратно js? =)

Ilya

правильно писать const keys = Object.keys(properties) for (let i = 0; i < keys.length... вместо for (const prop in properties) { ?

for in по спеке перебирает собственные свойства - не заходя в прототип так что функционально - тождественно, что так, что так. Как средства выразительности - вкусовщина, хотя все чаще слышу мнения что архаичные for конструктивы лучше не использовать - Object.keys - как общепринятое, часто встречающееся решение. Если ориентироваться на поддержку современного станлдарта то появляются дополнительныен методы для перечисления собственных свойств объекта. Тем не менее - учтите что for in объективно быстрее исполняется чем Object.keys https://www.measurethat.net/Benchmarks/Show/2375/0/for-in-vs-objectkeys

Oleg

for in по спеке перебирает собственные свойства - не заходя в прототип так что функционально - тождественно, что так, что так. Как средства выразительности - вкусовщина, хотя все чаще слышу мнения что архаичные for конструктивы лучше не использовать - Object.keys - как общепринятое, часто встречающееся решение. Если ориентироваться на поддержку современного станлдарта то появляются дополнительныен методы для перечисления собственных свойств объекта. Тем не менее - учтите что for in объективно быстрее исполняется чем Object.keys https://www.measurethat.net/Benchmarks/Show/2375/0/for-in-vs-objectkeys

та тут проблема с производительностью. вот думаю, это повлияет или нет.

Oleg

for in по спеке перебирает собственные свойства - не заходя в прототип так что функционально - тождественно, что так, что так. Как средства выразительности - вкусовщина, хотя все чаще слышу мнения что архаичные for конструктивы лучше не использовать - Object.keys - как общепринятое, часто встречающееся решение. Если ориентироваться на поддержку современного станлдарта то появляются дополнительныен методы для перечисления собственных свойств объекта. Тем не менее - учтите что for in объективно быстрее исполняется чем Object.keys https://www.measurethat.net/Benchmarks/Show/2375/0/for-in-vs-objectkeys

в смысле for in быстрее?

Ilya

в смысле for in быстрее?

да, я же длаже ссылку на бенчмарк дал

Mihail

Если ты не будешь перебирать объект с 1кк ключами, то разницу не заметишь

Ilya

Если ты не будешь перебирать объект с 1кк ключами, то разницу не заметишь

согласен, проблемам производительности в JS стоит относиться очень объективно осознавая пропорции затрачиваемого и выигрываемого, в том числе и доступность ресурсов

Oleg

мне всегда говорили, что классический быстрее

Ilya

так что я свои падаванм всегда советую использовать более выразительные средства - взамен архаичным, но более быстрым (так как сейчас мы свои JS приложения почти всегда собираем, тому же бабелю можно поручить оптимизацию если таковая потребуется)

Mihail

Сейчас скатимся до того, что ц++ быстрее

Mihail

😳

Ilya

такой же пример с использованием Array.prototype.includes вместо indeOf (который быстрее) - ну и что

Evgeny

мне всегда говорили, что классический быстрее

нельзя верить словам=) нужно верить бенчмаркам=) оно же еще от реализации в движке зависит

Oleg

кому теперь верить...

Ilya