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

Если Вы предполагаете, что нечто является единой сущностью, то должен быть ровно 1 источник истины, определяющий эту сущность. Типы - это источник истины о структуре Ваших сущностей. Если в двух приложениях Вы оперируете одними и теми же сущностями, то и типы для них должны быть едины, иначе это будет нарушением DRY. Но если по факту сущности разные, то даже если они выглядят одинаково, их нельзя объединить, иначе это будет нарушением SRP.

Что можно сделать если типы описывают единые сущности:
1. Если оба приложения живут в одном репозитории, то можно просто переиспользовать одни и те же модули в обоих приложениях. Можно даже сложить их в общую папку и прописать на нее алиас в tsconfig.json и в конфиге сборки.
2. Если приложение живут в разных репозиториях, то общий код можно вынести в третий репозиторий и подключить его через git модули
3. А если общий код еще и меняется редко, то разбить его на отдельные npm пакеты - хорошая идея. При этом не обязательно заливать его в публичный репозиторий или покупать у npm приватный, и даже свое зеркало ставить не обязательно (хотя и удобно). Можно просто запаковать пакет в .tgz командой npm pack, а потом устанавливать его из этого .tgz через npm i прямо с файловой системы или с любого http сервера. Кроме того npm i можно делать прямо из git репозитория в корне которого лежит package.json, но как по мне - это не очень хорошая затея, так как в git лежат исходники, а в npm пакете должен быть готовый к использованию (собранный) js код.
4. Ну и наконец, единый репозиторий так же можно организовать в несколько пакетов, используя npm workspaces и lerna.

UPD:
Надо ознакамливаться на что ссылаешься...
В русской википедии в статье про SRP понаписано много бреда, которого нет в английской версии.
Забавно, что подобно английской статье, в русской так же ссылаются на Роберта Мартина, который определяет данный принцип правильно (по крайней мере в тех его книгах, что я читал).
Это очень распространенное заблуждение (OMG, я кажется нашел, откуда все эти люди, что приходят на собеседования, понабрались этого бреда...)
Принцип единственной ответственности не про то, что код делает что-то одно или отвечает за что-то одно (какая вообще может быть ответственность у текста?).
Принцип единственной ответственности про то, что у каждой программной сущности есть ровно одно ответственное лицо, и только это лицо является источником изменений в коде этой сущности.

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

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

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'шников через рекламные сети.