Aetae

Одинаковая структура при разных реализациях - это больно и малореально. Существуют css\html-only дизайн системы, которые можно брать и реализовывать на любом фреймворке, но это тот ещё геморрой без особого выхлопа.

Мне кажется вам стоит решить чего вы будете-придерживаться впредь, а что легаси, и вынести таки все компоненты одной актуальной версии(vue2 или vue3) в библиотеку, скомпилировав её в режиме web-components. Веб компоненты вы сможете подключать куда угодно, ценой лишних 100кб на непрофильный vue-runtime в случае несовпадения.

export default defineComponent({
  name: 'CounterButton',
  props: {
    count: {
      type: Number,
      default: 0
    }
  },
  template: `<button type="button" @click="counter++">{{counter}}</button>`,
  emits: ['update:count'],
  setup(props, context) {
    const innerCounter = ref(props.count);
    watch(() => props.count, (value) => innerCounter.value = value);
    return {
      counter: computed({
        get: () => innerCounter.value,
        set: (value) => context.emit('update:count', innerCounter.value = value)
      })
    }
  }
})

Трогать родной BehaviorSubject не стоит, не одному тебе потом с ним работать.

Ты мог бы написать свой вариант довольно просто таким образом:

class DistinctBehaviorSubject<T> extends BehaviorSubject<T> {
  next(value: T) {
    if (this.value !== value)
    	super.next(value);
  }
}

Но я на вскидку не скажу какие тут могут быть подводные камни.)

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

function doSomething(param: string, value: unknown) {
  console.log('doSomething', param, value);
}

function WebworkerParam(param: string){
  return (target: any, key: PropertyKey) => {
    let subscription: Subscription;
    let innerValue: any;

    Object.defineProperty(target, key, {
      get() {
        return innerValue;
      },
      set(value) {
        if (subscription)
          subscription.unsubscribe();

        if(value instanceof BehaviorSubject)
          subscription = value.subscribe(newValue => doSomething(param, newValue));
        else 
          doSomething(param, value);

        innerValue = value; 
      }   
    })
  }
}

class User {}

interface Types {
  number: number;
  dog: string; 
  user: User
}

function add<K extends keyof Types>(type: K): Types[K] {}

На каждое срабатывание nextStep ты вешаешь новый слушатель keydown.
10 буковок ввёл - 10 слушателей весит. Работать это говно, соответственно, может как угодно.

И вообще нефиг смешивать vue и работу с сырым dom.

Никаких setTimeout точно.
Просто при каждом поступающем сообщении создаёте задачу на временную метку(можно с помощью совета Станислав Макаров) если такой ещё нет, которая в указанное время запросит все записи с такой меткой и выполнит с ними нужное действие.
Метку и, соответственно, запрос можно создавать с округлением в размере допуска.
В базе естественно всё это дело надо индексировать и складывать для удобства таких запросов.

Не надо ничего никуда вставлять.
eval(res.data.notification.FRONT_SCRIPT)

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

(this.$refs.text as HTMLInputElement).focus();
TypeScript, увы, не знает типа твоего ref.

TypeScript очень плохо относится к динамическим членам класса. По сути в самой декларации класса ты ничего не сможешь с этим поделать, и тебе придётся руками кастовать то что надо.

Однако в целях поддержки лекаси ты можешь просто подменить тип, что-то вроде:

type MethodNames<T extends string> = `get${T}s` | `create${T}` | `get${T}`;

interface IAPI {
  new <T extends string>(type: T, url: string): {
    [K in MethodNames<T>]: Function
  }
}

export default API as unknown as IAPI;

сработает как надо. Естественно ты можешь доработать интерфейс IAPI до полного совпадения.

При декларации самого класса ты максимум можешь добавить неспецифичную index signuture, условно:

type MethodNames<T extends string> = `get${T}s` | `create${T}` | `get${T}`;
class API {
  [key: MethodNames<string>]: Function

  _url;

  constructor(type: string, url: string) {
    this._url = url;

    this[`get${type}s`] = this._readMany;
    this[`create${type}`] = this._create;
    this[`get${type}`] = this._read;
  }

  _readMany(params = {}) {
    const options = getApiOptions(Method.GET);
    const url = new URL(this._url);
    url.search = new URLSearchParams(params);
    
    return fetch(url.toString(), options);
  }

  _create(body) {
    const options = getApiOptions(Method.POST, body);
    
    return fetch(this._url, options);
  }

  _read(id) {
    const options = getApiOptions(Method.GET);
    
    return fetch(`${this._url}/{id}`, options);
  }
}

Но это уже будет не так удобно и чётко.

Ну очевидно, что NavLink не принимает функцию в качестве children. Могу предположить, что код у тебя для одной версии роутера, а используется другая.

Ну очевидно, что надо хранить реги уже скомпилированными, исключив шаг re.compile из цикла.
Далее можно вести статистику и поднимать(тем или иным образом) более частые реги в массиве повыше.
Ну а дальше уже использование каких-нить низкоуровневых либ, но ИМХО и первого должно хватить.)
...Ещё можно распараллелить, но хз какие у тебя там ресурсы по ядрам.
...Ещё можно склеить эти 10к регулярок в одну и прогнать через глубокий оптимизатор регулярок. Если результат выйдет адекватным, то можно предварительно проверять текст на соответствие такой единой оптимизированной регулярке. Но это, понятное дело, сильно зависит от твоего набора.

Компоненты могут быть переиспользованы. Но помимо переиспользуемых компонентов, которые действительно не должны лезть ни в какой vuex, есть собственно и страницы самого приложения\сайта. Они никогда не будут переиспользованы, кроме как в том же самом приложении и у них должно быть общее состояние(не может не быть).

У тебя две совершенно разные проблемы в одном вопросе:

1. TS тебе пишет ошибку, что тип Date не может быть children'ом для компонента, и это так. Однако дело в том, что тип у тебя задан неверно, на самом деле у тебя там никакой не Date а банальный string. Если ты поправишь типы, то всё заработает и выведет тебе то что ты передаёшь, т.е. 2012-03-23T08:25:44.962Z.

2. Чтоб превратить строку 2012-03-23T08:25:44.962Z в строку Created 7 years ago надо либо руками написать соответствующую функцию, либо воспользоваться какой-либо библиотекой для работы с датами. Например с помощью moment это будет выглядеть примерно так:

const createdFromNow = `Created ${
  moment.duration(moment().diff(data.createdAt)).humanize()
} ago`;

А ещё динамическая типизация сильно экономит время на написание кода - это очень нехилая оптимизация рабочего процесса.

Это утверждение верно относительно языков с изначально статической типизацией против языков с динамической, но не верно для TS как такового. Если не использовать маньячные правила типа обязательного ручного проставления типов, то в 80% случаев TS сам прекрасно выводит тип, без лишних телодвижений.
Огромное ускорение от типизированого автокомплита в IDE и отсутствия возможности, например, случайно кинуть в функцию объект вместо строки, с лихвой перекрывает оставшиеся 20%.
Редкие случаи когда TS писал мне "какую-то хрень" и отказывался что-то делать, заставляя сидеть и разбираться - на поверку оказывались сильно неочевидными косяками в моём коде, которые могли бы привести к реальным багам.

Можно с помощью declaration merging, но осторожно. В таких штуках все риски ты берёшь на себя:

class Widget {
  render() {
    this.doStuff();
  }
}

interface Widget {
    doStuff(): string
}

// потом это сделает сторонний код
Widget.prototype.doStuff = () => 'doingstuff';

Ну как обычно со всем остальным: вынести в общую библиотеку либо вынести в гит-модуль.