m
Aleksandr Osipov
И то она касается сугубо TS
Она касается статических проверок. То есть больше забот по проверки корректности логики, что ты пишешь, ложится на тайпчекер. А значит ты пишешь с меньшим количеством ошибок)
Size: a a a
2020 July 02
З
крайне редко)
AO
makoven
Она касается статических проверок. То есть больше забот по проверки корректности логики, что ты пишешь, ложится на тайпчекер. А значит ты пишешь с меньшим количеством ошибок)
Понятно... ради ублажения TS
m
Aleksandr Osipov
Понятно... ради ублажения TS
Нет. Ради стабильности кода
m
но я в таких случаях делаю
[[key, value], [key2, value2]], ибо лень с мапами возитьсяТогда поиск по словарю ляжет на плечи js. А при map.get(key), поиском займется код на C++.
m
Тут, кстати еще возможны деоптимизации при доступе через obj[key]. Рантайму надо понять массив это или объект. Если объект чекнуть наличие геттеров, пройтисб по цепочке прототипов..
m
А map.get() однозначен
З
кому это интересно, когда операция практически бесплатна, а на фронте в 0.0000000001% случаев существуют какие-то ощутимо большие данные
AO
makoven
Тут, кстати еще возможны деоптимизации при доступе через obj[key]. Рантайму надо понять массив это или объект. Если объект чекнуть наличие геттеров, пройтисб по цепочке прототипов..
Часто ли это скажется хоть как о на производительности?
m
Aleksandr Osipov
Часто ли это скажется хоть как о на производительности?
Ай донт ноу )
AO
Подозреваю что только в довольно специфичных задачах
З
бизнес-код должен быть кратким и читаемым, а не содержать портянки
new Map(map...) и других приколов ради преждевременной оптимизацииAO
Вот с удалением правда геморой с объектом, можно конечно del obj[key], return {...obj}
m
бизнес-код должен быть кратким и читаемым, а не содержать портянки
new Map(map...) и других приколов ради преждевременной оптимизацииКстати, для однострочных стрелочных new Map() выглядит понятнее с точки зрения бизнес логики. Если возвращать объектовый литерал,
id => {}
то возникает неоднозначность, т.к. фигурные скобки тут будут означать новый блок функции. И в некоторых случаях можно забыть поставить скобки и получить логическую ошибку
id => {}
то возникает неоднозначность, т.к. фигурные скобки тут будут означать новый блок функции. И в некоторых случаях можно забыть поставить скобки и получить логическую ошибку
AO
makoven
Кстати, для однострочных стрелочных new Map() выглядит понятнее с точки зрения бизнес логики. Если возвращать объектовый литерал,
id => {}
то возникает неоднозначность, т.к. фигурные скобки тут будут означать новый блок функции. И в некоторых случаях можно забыть поставить скобки и получить логическую ошибку
id => {}
то возникает неоднозначность, т.к. фигурные скобки тут будут означать новый блок функции. И в некоторых случаях можно забыть поставить скобки и получить логическую ошибку
Так типизация же не даст
AO
Ну и к слову о производительности мапа, там где она нужна вдруг уж точно не стоит пересоздавать его каждый раз с копированием старого
m
Aleksandr Osipov
Так типизация же не даст
Даст. В данной ситуации, возврат undefined из хэндлера является особым случаем и частью АПИ
m
Aleksandr Osipov
Ну и к слову о производительности мапа, там где она нужна вдруг уж точно не стоит пересоздавать его каждый раз с копированием старого
Подозреваю, по производительности это ничем не отличается от {...obj}
AO
makoven
Подозреваю, по производительности это ничем не отличается от {...obj}
Ну я к тому что для получения профита от мапа в тех редких случаях когда это важно стоит скорее реф использовать а не перерсоздавать его
ЕГ
Преждевременные оптимизации - зло