К
ну это не значит что можно везде пихать
Size: a a a
2021 May 16
AF
потому что на том количестве элементов, когда разница в производительности вообще станет заметна, DOM просто умрёт.
К
ну генератор тут все равно лучше
К
ток их почти не юзают
К
а так пофиг
AF
Это следует пихать везде, и только если вдруг начнутся какие-то проблемы, подтверждённые профайлером, пытаться оптимизировать. Тратить энергию на микрооптимизацию перебора семи элементов плохо.
G
Ссылку можно еще раз?
К
это НЕЛЬЗЯ тупо пихать, как все делают
К
особенно в реакте =))
AF
Это также лучше, чем генератор, по той же причине, по которой это лучше .reduce и for. Потому что это узкоспециализировано.
ON
понятно! То есть либо then, либо await и сохранять возвращаемый axiosResponse в переменную
AF
Если стоит задача "обработать каждый элемент последовательности", то следует пользоваться инструментом, семантика которого состоит в "обработать каждый элемент последовательности", а не "произвести неопределённое количество неопределённых операций". Такой код гораздо более доступен, потому что не требует проверять каждую строчку, чтобы убедиться, что он нигде не стреляет в ногу.
К
ты ты предлагаешь сначала обойти дерево, положить все результаты в массив, и потом еще его обойти?
К
вместо того чтобы сразу обойти и сделать
AF
да, async для того и нужен, чтобы работать с кодом, который выглядит линейно, но на самом деле время от времени останавливается и ждёт
AF
это во многих случаях очень хорошая идея.
К
если оно персистентно
К
если его меняет что-то снаружи - нет
AF
я предлагаю сначала получить список (каким угодно образом), а обрабатывать его в отдельном месте, не думая о том, каким способом он получен. При этом операцию получения списка можно переиспользовать, что и есть не повторяй себя.
К
ну вот, чем тебе генератор не нравится?