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

Включи предупреждения в консоли. Ты пытаешься изменять массив напрямую в store, чего делать нельзя.

const arr = this.$store.getters.templatesList.slice(0);

Ну и для сортировки есть встроенный метод sort:

arr.sort(({created_at:a}, {created_at:b}) => a < b ? -1 : a > b ? 1 : 0);

Что именно ты хочешь сократить, вроде ж дальше некуда: один тип на вход - один на выход?

Ну можешь убрать async и await, они здесь не нужны:

const ApiServiceModule = {
  get: <T>(url: string): Promise<T> => fetch(url)
    .then(response => response.json())
    .catch(err => console.error(err))
}

async/await всего лишь сахар над Promise и в данном случае ничего не делают, т.к fetch и так возвращает Promise.

P.S. Ну и методом я бы это не назвал, это свойство с функцией. Метод имеет доступ к this.

Быстрое решение - построить для этого массива суффиксное дерево алгоритмом Укконена (или вот ссылка), потом обойти его, найти самую глубокую вершину, у которой есть более одного ребенка, и вывести путь до нее от корня. Работает за O(n).

Edit:

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

И еще проще, но уже за куб - переберите любые 2 позиции и потом одним циклом считайте, сколько символов с этих позиций совпадают.

почитайте что такое ssh jump host (или ssh bastion host).

Вот неплохая ссылка.
https://www.redhat.com/sysadmin/ssh-proxy-bastion-....

Правильный ответ: писать код предусматривающий подобные вещи через абстракции. Тебе не надо триггерить события, ты должен при установке значения напрямую вызывать нужные функции. Ты сам знаешь что у тебя в коде происходит и какие функции привязаны к событиям, тебе не нужно ждать событий от браузера.
Полезный ответ: использовать любую библиотеку умеющую в data binding, которая будет заботится о таких вещах за тебя. Мне лично нравится Vue, но есть и множество решений по-проще и по-традиционней.
Плохой ответ: ты можешь добиться этого примерно таким извращением, подменив стандартный сеттер на value:

const valueDescriptor = Object.getOwnPropertyDescriptor(HTMLInputElement.prototype, 'value');
Object.defineProperty(two, 'value', {
  ...valueDescriptor, 
  set(value) {
    valueDescriptor.set.call(this, value);  
    this.dispatchEvent(new Event('input', {
      bubbles: true,
      cancelable: true,
    }));
  } 
})

По множеству причин.
Например вас предупредить что вы идете в дикий интернет.
Записать ваше действие
Впарить вам реферала
....

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

во первых - performance.now возвращает дробное число, поэтому там в принципе может быть наносекундная точность. однако стандарт определяет что точность должна быть 5 микросекунд. Плюс браузеры могут специально занижать точность чтобы бороться с некоторыми атаками.

поэтому правильно вызывать функцию много раз и считать среднее.
так же в ноде есть process.hrtime которая дает наносекунды.

оба этих метода "в лоб" не дадут нормального результата. Почему? потому что в реальности происходит много всего интересного при выполнении кода.

в движке есть неимоверное количество оптимизаций, и функция вызванная 10 раз будет иметь совершенно другой код чем функция вызванная 100 раз. То же касается и типов параметров - например вы можете передавать целые или дробные числа.
На одну вашу написанную js-функцию движок сгенерирует несколько функций которые это реализуют. У этих функций может быть совершенно разный код с разной произодительностью.

Переключение происходит на лету и в общем виде вы не знаете когда это происходит.

поэтому само по себе замерение скорости "функции" имеет мало смысла, так как там их несколько внутри. Если интересны детали - погуглите JIT, AOT и v8 optimizations.
Сейчас важно то что есть "холодные" функции которые работают медленее но надеждее и как правило используются сразу и есть "горячие" варианты, которые компилятор начинает использовать когда видит что код вызван много раз, и условия не меняются. "Горячие" работают быстрее.

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

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

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

И тут самый главный момент - даже если вы замерите эту скорость, что вы будете делать с этим знанием? В реальной программе при выполнении этого кода скорость может быть совсем не такая как вы намеряли. Эти тесты годятся только для своего общего развития

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

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

Тут есть несколько решений.
Например:

type TupleUnion<U extends string, R extends string[] = []> = {
	[S in U]: Exclude<U, S> extends never ? [...R, S] : TupleUnion<Exclude<U, S>, [...R, S]>;
}[U] & string[];

interface Interface {
  foo: boolean;
  bar: string;
  baz: object
}

type Keys = TupleUnion<keyof Interface>; 

let keys: Keys;

keys = ['foo', 'bar', 'baz']; // OK все ключи указаны
keys = ['foo']; // NOT OK указаны не все ключи
keys = ['foo', 'bar', 'another bar']; // NOT OK один из ключей не совпадает

Но в реальном проекте их использовать крайне не рекомендуется - они сожрут тебе всю память и весь процессор, если ключей будет побольше чем парочка.

вам надо не в интернете искать решение а перевести ошибку и подумать.
Давайте я помогу - сегодня хорошее настроение.

Ошибка говорит "запросы у которых в url символы '<' '\n' '\t' '\r' блокируются.
вам надо найти то место где делается этот запрос, отдебажить, посмотреть на урл и найти там эти символы. Потом подумать откуда они там взялись и исправить то место.

Судя по тому что вы делаете что-то по уроку, мест где вы делаете http запрос у вас вряд ли более одного.

Внизу страницы есть ссылка "Обратная связь". По ссылке - форма. В форме - выпадающий список. В выпадающем списке пункт - "Нарушение правил сайта". Вот его и выбираете. Чуть пониже поле - "Текст сообщения". Там излагаете суть вопроса - кто, чего и как. Ещё ниже кнопка - "Отправить сообщение". Жмёте её.

Я думаю, что стоит учить Rust именно сейчас потому, что язык перспективный. Вакансии начнут появляться через пару-тройку лет. Язык сложный, поэтому нужно время на его изучение. Пока выучите и рынок подтянется.
К тому времени будете в топе разработчиков с реальным опытом.
У Rust есть хороший потенциал по вытеснению C, особенно с учетом того, что его дизайн способствует эффективному применению в многопоточных системах. Ввиду предстоящего бума ARM-процессоров перспектива очень даже заманчива.
На текущий момент Rust + работа зарубежом (фриланс) вполне нормальная перспектива.

const a = 10;
const b = 2;
const c = 4;

function calc(first, last) {console.log(first + last);}

calc(a, b);
calc(a, c);

тоесть мы в функцию передаем параметры!

Ну так что ты в итоге возвращаешь?

return [...newArr, ...getArraysCounts1(other)];

А должен возвращать Map