Михаил Р.

<template v-for="(value, key, index) in copied" #[`item.${key}`]="{item, index}">
    <span @click="copied[key] = index; setTimeout(() => copied[key] = null, 2000); copy(item[key]);">
    ....
</template>

Если попробовать поразмышлять..

useState подразумевает плюс-минус простой стейт, который удобно обновлять через либо setState(newValue), либо через setState(prevState => ({ ...prevState, key: newValue })).

useReducer для более сложных кейсов, где хранить логику обновления в компоненте становится нецелесообразным и/или будет слишком раздуваться компонент. Или же где логика переиспользуется. Впрочем, то же самое можно сделать и через useState, создав свои хуки, которые под капотом юзают useState/useReducer.

На выходе, самым логичным на ум приходит более плавная миграция в redux на useReducer.

Проблема в том, что redux не нужен в 90%+ проектах, и его можно было заменить голым реактом с его инструментами.

Моё мнение - если тебе смысл переменной не очевиден, то нужно делать полноценное имя переменной.

Короткое, например, имеет смысл для параметра в лямбде (array.filter(x => x % 2 === 0)) или в какой-нибудь функции наподобие

function sum(a, b) {
 return a+b;
}

Если тебе к твоей однобуквенной переменной нужно ещё и комментарий писать, который её расшифрует - значит переменная точно не должна быть однобуквенной.

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

Экономить ресурс нажатий на кнопки клавиатуры не надо, как и не надо экономить буквы на экране.

Хорошо составленный вопрос содержит половину ответа :) По самой постановке вопроса, по описанию, по языку, который используется (не языку программирования, а именно языку общения, манерам, стилю, жаргону, фене), по его уместности в данной обстановке (особенно для вопросов типа "как сейчас заработать на фрилансе"), по полноте информации можно судить - стоит отвечать серьезно или же просто потроллить. Или вообще не тратить время :)

Вот тут датасеты разные есть https://datasetsearch.research.google.com/

Это называется open graph

Изучить оба языка, проанализировать js-код, вычленить алгоритм, реализовать его на Python.

У вас классическая проблема обработки пользовательского ввода. Решается она по-разному в зависимости от контекста, в котором используются данные. Так как вы не указываете контекст, то и ответ будет соответствующе широким.

1. Запрос первоначально поступает в node.js (конкретно в движок v8, отвечающий за сетевое взаимодействие). Здесь возможны уязвимости, при которых специальным образом сформированный запрос может привести к отказу в обслуживании (DoS), несанкционированному доступу к памяти (вспоминается эпичнейшая уязвимость heartbleed) и иным спецэффектам.

2. Далее запрос поступает в express, где он парсится и преобразовывается в объект req. Здесь так же могут быть уязвимости, эксплуатируемые путем отправки специально сформированного запроса.

Пункты 1 и 2 исполняются до вашего кода, поэтому всё что вы можете здесь поделать - это вовремя обновлять софт и библиотеки.

3. Далее ваш код занимается обработкой данных. Важный момент в этом - санация и валидация данных.

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

Валидация - это проверка данных на корректность. Например, вы ожидаете номер телефона в поле phone. После санации останется проверить, что длина номера не нулевая и не больше 15.

Если данные предполагается передавать дальше, скажем, на удалённый JSON REST сервис, то вы должны будете корректно экранировать строку перед добавлением её в JSON, иначе случайная кавычка сломает ваш запрос.

Либо если данные будут вставляться в базу данных, то необходимо экранировать данные (либо вставлять данные через подготовленные запросы) чтобы не получить SQL injection уязвимость.

Вот тут как раз и появляется зависимость от контекста. В контексте базы данных - один способ экранирования. В контексте json - другой. В контексте HTML (при выводе данных пользователю) - третий. В ещё каком-нибудь другом контексте будут свои способы обезопасить данные.

Если рассматривать конкретно пароль, то с ним всё просто. Как правило, пароли не хранятся на сервере в открытом виде и предварительно подвергаются преобразованию в криптографически стойкий хеш (например, argon2 или scrypt). Сам хеш уже имеет фиксированный размер и известный набор символов. Поэтому санировать пароль не нужно, а при валидации просто проверить минимально допустимую длину, несовпадение с логином, email и может ещё какие-нибудь проверки, навязанные бизнесом или применяемыми стандартами.

Реакт придерживается концепции "чистых" функций. Т.е. таких функций, которые всегда дают одинаковый, предсказуемый результат при одинаковых входных параметрах. В режиме разработки, с включенным strict-mode реакт помогает выявить непредвиденные эффекты и состояния, возникающие в результате нарушения концепции, вызывая дважды все функции, которые он считает "чистыми". Как это работает?
Предположим, вы написали функцию, которая по сигналу "свет" - включает свет. Но если свет уже включен - функция его выключает. Вы довольны и счастливы - послали сигнал "свет" - свет включился, послали еще один сигнал "свет" - выключился. Но в режиме strict-mode - вы обнаружите, что свет не включается, потому что реакт шлет второй сигнал "свет", который выключает после первого сигнала! И опять, возникает вопрос - да зачем это нужно? А затем, что вы не можете предсказать результат действия сигнала "свет", не зная текущего состояния! Возникнет острая необходимость - включить свет, а вы не знаете - включен он сейчас или нет... Пошлете сигнал "свет", когда он включен - получите выключение.
Примерно такие варианты поведения выявляет strict-mode.

11 миллионов inserts в день - это 127 в секунду. При такой нагрузке справится любая современная БД. Ну я не знаю таких чтоб не справлялись. Делайте только короткую буферизацию и batch-insert пачками по 100 - 1000 чтобы оптимизировать сетевой roundtrip.

Есть специализированные NoSQL системы такие как RocksDb, Tarantool в которых именно много оптимизаций сделано было для быстрой вставки. Они выдерживают и во много раз быстрее.

И в данной задаче нужно также спросить бизнес - как быстро данные нужны к чтению пользователя. Нужно сию секунду чтоб они отобразились на UI или можно подождать пару минут или часов.