Robur

да

потому что вы ничего из функции не возвращаете. соответственно возвращается undefined.
И с чего вы взяли что await не ждет? думаю он все ждет, просто то что происходит в коде отличается от того что вы думаете что там происходит.

Разная.
во первых, есть спека, которая описывает что должно произойти при вызове конструктора с коллекцией в качестве аргумента. Это абстрактное алгоритмическое описание, у него сложность как видим O(n) при условии что adder имеет сложность O(1). Если adder имеет другую сложность - то соответственно сложность конструктора так же поменяется, вполне может быть и O(n^2) например. копаться что там может быть в adder мне уже лень, можете выяснить самостоятельно.
https://tc39.es/ecma262/#sec-set-iterable

Дальше, есть движок, в котором реализована эта спека. хоть мы и живем во времена дефолт-движка v8, но предполагать что это единственная реализация в мире не правильно. Напимер в файрфоксе - не он. В мобилках - по моему тоже (как минимум на ios).
Поэтому второй вопрос - в каком движке?

В движке может быть реализовано именно таким алгоритмом, а может быть и другим. Вплоть до разной сложности для разных данных.

Поэтому третий вопрос - для каких данных?

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

Чтобы сказать точно - надо смотреть в код движка.

Если у вас на интевью дошло до обсуждения деталей реализации v8 или spidermonkey, или еще чего, то вы должны уже не спрашивать на тостере такие вещи а отвечать. Ну как минимум быть в состоянии найти этот код при необходимости.

нет. "нормального" уровня достаточно.

В каких случаях использовать HOC, а в каких пользовательские хуки?

Если вы перешли на разработку с использованием хуков и хотите единообразия в коде - то всегда хуки. HOC не нужен вообще.

Если вам нравится/хочется запилить HOC и некоторая каша в коде вас не смущает - делайте HOC.

В плане функционала и возможностей они взаимозаменяемы.
С точки зрения чистоты кода конечно при переходе на хуки от HOC надо отказаться - это просто лишний концепт в приложении.

Я мало что понял, но в таких ситуациях основная идея обычно такая:
- то что покажет страница, зависит от каких-то параметров.
- когда вы кликаете, вы меняете эти параметры, и соответственно параметрам меняется отображение страницы
- эти параметры где-то сохраняются, варианты разные, можно прямо в url можно в localStorage
- при загрузке страницы вы читаете эти параметры и смотрите, как надо поменять отображение страницы

например у вас есть кнопка "показать данные", если на нее кликнуть то загружается json и показывается.
при клике вы делаете это все и при этом сохраняете в localStorage "showJson=true"
при загрузке страницы вы смотрите, если showJson=true, то тут же делаете все то что делаете по клику, не дожидаясь пока польователь нажмет кнопку. Как будто он ее сразу же нажал.

при желании можно данные тоже сохранять, чтобы при загрузке их показать сразу же, а не делать запрос на сервер.

в JS - никак. Вы можете разве что делать разные оптимизации поверх сборщика мусора - пул объектов, переиспользовать массивы, не создавать функции на каждый чих и так далее. Но большой вопрос - зачем это вам.
Если у вас не реалтаймовое приложение с большим количеством данных - убедитесь что нет утечек памяти и успокойтесь :)

Если просто душа просит другого - то вам нажен другой язык. И соответственно это будет не веб (разве что через WASI но это не точно)

Но, что если программист сам хочет принимать решения, и следить за памятью

Такого программиста надо отправить в хардкорную embedded разработку и он будет там счастлив, считая байты и подчищая регистры. А если будет оттуда выбираться и пытаться следить за памятью самостоятельно там где есть проверенные встроенные механизмы (GC, ARC и прочее) надо отбирать клавиатуру.

Раз уж просили:
1. Что значит "правильно"? нормальноу вас организовано
2. называть что-то контейнером или нет - это ваше личное дело, в зависимости от того как вы для себя решите код организовать. каких-то требований и общепринятых стандартов которые нельзя нарушать по этому поводу нет.
3. в общем случае - лучше загружать данные где-то в одном месте. Но бывают и исключения, дурно ли это у вас или нет здесь - я не знаю. Может так меньше запросов на сервер или лучше код, - тогда не дурно. Если вы просто не знали как код организовать и скопипастили загрузку в два места - то дурно.
4. можно
х. если нет нужды в редаксе, то да, он и не нужен. Если код начнет усложняться - какой-то стейт приложения потребуется.

ПС. можете посмотреть на apollo-client, у него внутри редакс вроде. Но подобного плана библиотеки писать вам вряд ли придется.