Robur

возможно, как-то так

const [data, setData] = useState(null)
async function doStuff() {
  const data = await fetch(...)
  setData(data)
}
....
 <Button onClick={doStuff} />
...

this.strokeNamesString у вас не имеет никакого отношения к модели, а к той функции в которой вы вызываете await Char.updateMany.

Нельзя использовать в update функцию JS которая будет применена к каждой записи, вместо этого вы можете использовать pipeline, и какое-то выражение для $set, если там есть нужный вам функционал.
https://docs.mongodb.com/manual/reference/method/d...

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

Чтобы стать хакером на винде, надо пройти первый тест - поставить линукс. Вы с этим не справились.
Вернитесь и разберитесь, пока не научитесь решать нерешаемое а не "через недельку надоело" - хакером вам не быть.

По его специальности 100% не дарить. то что ему надо он уже нашел и прочитал, а ненужное - ненужно.

Подарите вот такую
https://www.litres.ru/robert-satton/ne-rabotayte-s...

положите его в href тега a

Это так скажем предыстория (вода),

это вначале надо было написать, сэкономили бы читающим кучу времени.

Формально вышка вам будет нужна только при устройстве в бюрократические конторы в россии или для более простого получения рабочей визы за рубежом.
Не формально - Если вы действительно потратите свое время на изучение алгоритмов, структур данных, и прочего именуемого Computer Science - то разницы не будет. Пока что большая часть самоучек которых я встречал, не находят для этого времени или желания. Это не пару месяцев времени потратить.

но оно и не всем надо, обычный UI делать например, или прослойку между базой и HTTP (90% всей работы "WEB-программиста") - вообще ничего из CS не пригодится. учите язык, инструменты, фреймворки, апи всякие и вперед.

. Есть какие-то готовые решения для больших объемов работы?

Конечно, называется копирайтер

Если данных мало - то можно в локалсторадж, если много - кешируйте на уровне HTTP, пусть браузер разбирается.
Сервер знает когда данные поменялись и может сигнализировать браузеру через etag например

const filtered = array.filter(...оставить только вчерашние, сегодняшние, завтрашние...)
const grouped = lodash.groupBy(filtered, 'date')

ctrl-s жмете в браузере, потом подчищаете руками неровности.
Ну или достать с файлопомоек начала 200-х какой-нибудь site downloader.

то-то слышал про GET, POST, но не знаю как начать и с чего.

Вот с этого и начните, почитайте про HTTP

Изучая функциональное программирование.

Тем немного больше чем .map и reduce.

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

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

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

Про js и npm, другие области не знаю.
Это большая серьезная проблема у которой нет простого решения.

Если вам важно отсутствие бекдоров - то единственный выход - свой репозиторй в котором весь код доверенный.
Иначе даже если вы поставите модуль с 10к звезд, у него в зависимости 20-го уровня вложенности будет какой-нибудь left-pad, в который возьмут и положат бекдор.

Посмотрите на штуки типа https://snyk.io/. Я не знаю до какой степени они делают аудит модулей.

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

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

Просто расскажите как есть - не использовали потому что тут нет смысла, а вообще вы можете использовать их без проблем (если можете).

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

Хочу пойти работать в среднюю/крупную компанию, чтобы темп не был супер бешенный и чтобы было нормальный процесс обучения/помощи джунам

Ок, спасибо что поделились. Или тут есть замаскированный вопрос?

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

Что вы хотите протестировать в этом компоненте такого, что
1. относится к логике этого компонента
2. может незаметно сломаться
3. настолько важно чтобы окупить затраты по написанию-сопровождению теста?

присваивание переменной? это ломаться не должно.
Работу .map (тот пример что вы описали)? это внешняя логика, да и вообще - встроенный функционал.
То что в Recipe вы передаете recipe? это не может сломаться, пока вы сознательно не удалите. В этот момент тест тоже станет не валидным, и он вам ничем не поможет, его надо будет менять.

В общем - не надо его тестировать. Разве что для тренировки, попробовать как оно.