vladimirincog

Конкретно клик по стрелочке не получится обработать, но можно сделать обработчик для направления скролла, если нужно

console.log(document.styleSheets);
console.log(document.styleSheets[0].cssRules[0].selectorText);

Как бы это странно не звучало, но одно из главных преимуществ TypeScript - это ускорение разработки в несколько раз. Да, когда еще ничего нет - разработка незначительно замедлится, так как помимо логики нужно описать еще и типы. Но это только в начале. И это не только возможность писать большую часть кода с помощью автодополнения. Поддержка существующего кода занимает в десятки раз больше времени, чем его начальное написание. Стоит ли вложить несколько лишних часов на старте, чтоб сэкономить в последствии месяцы? Как по мне стоит.

Еще одним огромным плюсом является возможность проектировать на типах. Познав дзен TypeScript'а я перестал пользоваться UML, так как типы дают мне ту же наглядность, но при этом еще и сокращают время, так как типы - это уже код. Ну и источник правды остается один. Бизнес требования выраженные в типах не дают отклонится от них при написании логики, исключая возможность неправильной трактовки задачи. Перенеся задачу в типы, я могу обсудить ее с коллегами и исправить неточности еще до написания кода, что опять же сильно экономит время.

Ну и отвчечу на некоторые Ваши сомнения:

TSLint в VSCode прям жутко тугой

TSLint официально deprecated, вместо него стоит использовать плагин к eslint, заодно можете мой конфиг попробовать.

Типы? Есть JSDOC

JSDoc в плане типов не умеет и 10% того, что умеет TypeScript. Кроме того, никто в здравом уме не пишет JSDoc на приватную логику, а значит проверки типов там не будет. JSDoc не гарантирует корректность рефакторинга, а вот благодаря TypeScript я, опять таки, точно не забуду обновить JSDoc.

многие библиотеки nodejs не имеют типов

может лет 5 назад так и было, но сейчас встретить библиотеку без типов - скорее исключение. Если библиотека популярная, но не предоставляет типов, скорее всего их уже написал кто-то другой, достаточно просто установить одноименный модуль из npm скоупа types и все будет работать само.

Поддержка браузерами скомпилированного кода? Да какбы почти весь JS имеет поддержку 95%+, тот же Babel уже забыл когда использовал.

Вообще это не основная задача компилятора TypeScript, а опциональная возможность. И babel + preset-env с ней справляются гораздо лучше. И никто не мешает использовать их вместе. А еще думаю вопрос времени, когда кто-то напишет оптимизатор кода использующий информацию о типах из TS.

Примерно в каждой второй есть инстансы, на которые смотришь - и чешешь репу - а как называется тип этой переменной в @types/?

import {someObject} from 'some-library';

type TypeFromValue = typeof someObject;
const valueCopy: TypeFromValue = {
    ...someObject,
    type: 'overrides',
    with: 'type check',
};

и кстати, вот пример того что JSDoc типы не умеют.

//@ts-check

и почти везде останется бесполезный any.

P.S. удачи такие типы на JSDoc описывать
P.P.S. Еще прелести современного TypeScript невозможные у...

Думаю можно просто рассчитать:

function calculateUTCOffsetSeconds(timestamp) {
  const date = new Date(timestamp);
  const utcTime = date.getUTCHours() * 3600 +
    date.getUTCMinutes() * 60 +
    date.getUTCSeconds();
  const localTime = date.getHours() * 3600 +
    date.getMinutes() * 60 +
    date.getSeconds();
  return localTime - utcTime;
}
console.log(calculateUTCOffsetSeconds(-2208988800000));

Читай про метод reshape()

Сначала делаем результирующий сабжект, куда будем помещать наши запросы по клику.
Это будет high order observable, т.е. поток, выкидывающий другие потоки.
const trigger = new Subject<Observable<string>>();
Допустим вот наша эмуляция запроса. Пусть у каждого будет номер mark1, mark2 и тд. Сделаю фабрику c внутренним счетчиком mark. У вас тут будет реальный запрос вместо этого.

const getRequest = (() => {
  let mark = 1;
  return () => of(`m${mark++}`).pipe(
      tap(x => console.log('start', x)), // пометим начало запроса, т.е. момент подписки на него
      delay((1000 * Math.random()) + 300), // случайная задержка
      tap(x => console.log('end', x)), // пометим окончание запроса, когда приходит результат.
    );
})();

При клике плюемся запросом. Ну как то так, если не тащить ангуляр.

button.onclick = () =>  trigger.next(getRequest());

А теперь немного магии. Результирующий поток будет выплевывать результаты последовательно. Каждый следующий запрос начнет выполняться после завершения предыдущего.
const result = trigger.pipe(concatAll())

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