Дмитрий Беляев

Генератор - это императивно управляемый итератор. Сами итераторы позволяют производить ленивые вычисления.

Практическое применение например в том, что можно построить высокоуровневые абстракции над итераторами:

function* counter() {
  let i = 0;
  while (true) {
    yield i++;
  }
}

function* map(innerIterator, f) {
  for (const value of innerIterator) {
    yield f(value);
  }
}

function* filter(innerIterator, f) {
  for (const value of innerIterator) {
    if (f(value)) {
      yield value;
    }
  }
}

function* take(innerIterator, count) {
  let i = 0;
  for (const value of innerIterator) {
    yield value;
    if (++i === count) { return }
  }
}

function* inspect(innerIterator) {
  for (const value of innerIterator) {
    console.log(value);
    yield value;
  }
}

console.log('Создаем итератор');
const iter = inspect(
  take(
    map(
      filter(
        counter(),
        v => v % 2 === 0
      ),
      v => v * 2
    ),
    30
  )
);
console.log('Итератор есть, но он еще ничего не считает: ', iter);
console.log('Вычисления будут по требованию:');
console.log([...iter]);

// хелперы
const makeCustomTextFieldWithState = (): [string, ReactElement] => {
  const [value, setValue] = useState<string>('');
  const onChange = (event: React.ChangeEvent<HTMLInputElement>) =>
    setValue(event.target.value);
  return [value, <CustomTextField onChange={onChange} />];
};

const makeManyCustomTextFieldWithState = (count: number): [string[], ReactElement[]] =>
  Array(count).fill(0).reduce(([values, elements]) => {
    const [value, element] = makeCustomTextFieldWithState();
    return [
      [...values, value],
      [...elements, element],
    ];
  }, [[], []]);

// в компоненте
const [[dept, login, firstName, lastName], elements] = makeManyCustomTextFieldWithState(4);
<>{elements}</>

Вы нигде и никогда не найдете руководства по переходу с языка А на язык Б. Бэкграунд у всех разный и такие руководства просто не имеют смысла.

А еще ответьте себе на вопрос, зачем Вам Rust? В JS/TS нет и половины тех проблем, которые он решает. Да, ценой некоторых ресурсов, но нет.
А еще, есть два типа людей - те, которые думают, что в TypeScript/Java/C# сильная система типов, и те, кто понимает, что они в разы слабее чем в ML языках. Система типов Rust - это доработанная система типов OCaml со всеми вытекающими. Тут кстати можно в мире JS попробовать ReasonML/ReScript и сравнить с TypeScript, чтоб понять суть было проще.

А общий рецепт освоения Rust выглядит так:
1. Прочитать Rustbook на русском, но лучше на английском.
2. Посмотреть лекции Алексея Кладова
3. Rust by example на русском или на английском
Ну и конечно никуда без практики

И да, всю прелесть borrow checker понять не получится, пока не по управляете памятью руками. Но для этого не обязательно лезть в C/C++, можно на том же Rust, правда придется окунутся в unsafe, так что отложите это на попозже, а сейчас воспримите borrow checker, как часть строгой системы типов, которая всеми силами пытается Вам помочь.

На JS можно спокойно писать (и очень многие пишут) вообще не задумываясь где и как у Вас выделяется память и где и когда она освобождается. И программа будет работать, возможно даже без багов и утечек.

В JS Вам не нужно думать, о том сколько живут объекты, если у Вас есть ссылка - объект точно жив.

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

В JS у Вас никогда не будет Undefined Behavior.

В JS у Вас никогда не будет гонок данных, каждый поток (воркер) живет в своем пространстве памяти. И даже если Вы пошарите память, Вам не придется парится с атомиками/мьютексами и c memory order, все уже решили за Вас.

В C++ Вам придется об этом всем думать, если захотите написать что-то полезное.

Inplace не получится, но можно в новую:

const sortedMap = new Map([...map.entries()].sort(([, a], [, b]) => b - a));
console.log(sortedMap);

Хотя если сильно хочется, то можно и inplace наколдовать, через очистку и перезапись:

const sorted = [...map.entries()].sort(([, a], [, b]) => b - a);
map.clear();
sorted.forEach(([k, v]) => map.set(k, v));
console.log(map);

const mediaQuery = window.matchMedia('(max-width: 992px)');
const handler = () => 
    $(document.body).toggleClass('lock', mediaQuery.matches);
mediaQuery.addListener(handler);
handler();

https://developer.mozilla.org/ru/docs/Web/API/Wind...

А вообще, такое спокойно через CSS можно делать:

@media (max-width: 992px) {
    body {
        /* тут то что у Вас в .lock было */
    }
}

Придется парсить ключи в обработчике submit:

const re = /(.+)\[(.+)\]\[(.+)\]/;
const formData = new FormData(drawingForm);
const result = {};
for (const [key, value] of Object.entries(formData)) {
    const matches = key.match(re);
    if (!matches) { continue }
    const [, k1, k2, k3] = matches;
    ((result[k1] ??= {})[k2] ??= {})[k3] = value;
}
console.log(result); // тут валидация

Добавьте

.main__list {
  width: 750px;
}

Стандарт VPAID описывает лишь интерфейс взаимодействия плеера с креативом.
Внутри может быть абсолютно любой код, который может делать все что угодно в рамках своего контекста, в том числе тоже быть плеером, который подгрузит рекламу по VAST/VPAID.

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

А может и не рекламу крутить, я например как то делал в виде VPAID интерактивную вакансию и таргетировал ее на IT'шников через рекламные сети.