Kentavr16

fetch('https://site.com/api/get/json', {
headers: {
Accept: 'application/json',
Authentication: 'Bearer Token',
}
})
.then(resp => resp.json())
.then(json => console.log(json))

Само приложение маленькое, организовывать хранение стейта с помощью условного redux не вижу смысла

ну тогда просто храни в контексте

Приложения есть, например https://www.displayfusion.com/
https://www.nirsoft.net/utils/multi_monitor_tool.html
А встроенных возможностей нет
Но, честно говоря, мне кажется, запустить нужное приложение и нажать Win+Up, Win+Shift+(Left/Right) не очень долго.

Использовать подгтовеленные выражения:

connection.query('INSERT INTO your_table VALUES (?)', [text_to_insert], function(err, rows, fields) {
   if (err)
     console.log('Error Occurred');
 });

У тебя в тегах вебпак, а значит тебе нужны именно его алиасы.

Если ты используешь cra, то придётся костылить, через craco или подобное.

Это алиасы путей. Гуглить их.
https://dev.to/larswaechter/path-aliases-with-type...

То есть что условно лучше - огромная таблица с кучей строк или же большое количество таблиц в бд?

Очень правильный вопрос, но преждевременный.
С точки зрения нормализации, да и просто нормального написания запросов - одна огромная таблица с кучей строк. Для ускорения поиска по ней есть индексы.
Когда эта огромная таблица будет создавать проблемы, будете эти проблемы решать. При нормальном железе ориентироваться можно на 1млрд строк, обычно на таком кол-ве производительность InnoDB очень сильно деградирует. Кол-во ориентировочное, т.к. многое зависит от длины строки; при короткой строке, невысокой нагрузке и возможности ждать, будет работать.

Скорее всего тебе нужно 2 таблицы. Users и Tasks. Вторая - дочерняя и таким образом у одного юзера есть несколько тасков или ни одной.

Это называется Нормализация БД.

getElementsByClassName() возвращает не ваш input, а живую HTML-коллекцию с единственным элементом. У коллекции нет свойства value.

- let input = document.getElementsByClassName('form-control');
+ const input = document.querySelector('input.form-control');

Удобно работать с объектами Date.

const makeDate = HHMM => {
  const [H, M] = HHMM.split(':').map(Number);
  const D = new Date();
  D.setHours(H);
  D.setMinutes(M);
  D.setSeconds(0);
  return D;
};

const oo = n => n.toString().padStart(2, '0'); // 5 => '05'

const fillTime = (startHHMM, finishHHMM, intervalMinutes) => {
  let startDate = makeDate(startHHMM);
  let finishDate = makeDate(finishHHMM);
  if (startDate > finishDate) { // объекты Date можно так сравнивать
    [startDate, finishDate] = [finishDate, startDate]; // поменять местами
  }

  const dates = [];
  const D = new Date(startDate);
  while (D <= finishDate) {
    dates.push(new Date(D));
    D.setMinutes(D.getMinutes() + intervalMinutes);
  }

  return dates.map(D => [D.getHours(), D.getMinutes()].map(oo).join(':'));
};

console.log(fillTime('15:56', '18:15', 17));
// [ "15:56", "16:13", "16:30", "16:47", "17:04", "17:21", "17:38", "17:55", "18:12" ]

Эти ваши "гуру" просто ничего кроме примитивного PHPMyAdmin'а не знают. База ставится на хостинге, MySQL Workbench на рабочем компьютере. Подключение через ssh туннель, это штатная опция Workbench'а.

Стоит ли изучать sql, или же сразу заняться изучением ORM?

Все люди которые ратуют за использование ORM с годами все равно приходят к очень сильной
и мотивированной необходимости знать SQL. Этот язык сегодня является латынью баз данных.
Вы сможете говорить с бизнесом на одном языке если будете в переписке активно использовать
например язык DDL таблиц. Ваши аргументы будут выглядеть убедительно если в переписке будут
фрагменты например любой консоли MySQL, psql, SQL*Plus e.t.c. Короче знание SQL - это признак
джентльмена. Путь в приличное общество.

И наоборот, вы будете вообще НЕПОНЯТЫ если попробуете показать ORM объект на Node или не дай
бох на Java/JPA техниках аннотации. Бизнесу эти аннотации неинтересны и неинформативны.

Да и вам самомму смоделировать любой сложности выборку или отчет будет бытрее в SQL чем в фрейморках
ООП-отображения.

Что касаемо перформанса. К сожалению все современные ORM реализуют только самые базовые возможности
оптимизации запросов. Насколько я знаю Hibernate (по состоянию на 2015 год) так и не умел обращаться
с Oracle Hints. А любой сложный ентерпрайз начинается там где вы выжимаете из запроса не 100 а 1000%
возможностей. И здесь вам нужно управлять проприетарными функциями воздействия на оптимизатор.

Вообще для меня например цикл оптимизации ORM запросов начинается с того что я выбрасываю из
стека ORM. Заменяю на native. И долго наблюдаю его и оптимизирую. И когда достиг критерия готовности
то пытаюсь затащить обратно в ORM. Иногда не заходит. Это те случаи когда ORM оказался плох.
Эти случаи сложны, синьорны. и по каждому из них можно здесь в хабре открывать статью как минимум.

Но не все так плохо. Существует взгляд на ORM с обратной стороны. Это фреймворки наподобие MyBatis.
Они в первую очередь решают проблемы БД а уж потом дают опции объектных возможностей. Короче
Батис - это ОРМ наоборот. Где эволюция системы идет не от кода к БД (как любят хипстеры) а от
имеющихся вызовов процедур
и запросов к объектам респонса.

moment.js

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

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

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

Советую изучать с низов, самостоятельно, чтобы было понимание каждого шага, всего что происходит.
* операционные системы, процессор и многопоточность, сети,...
глубоко изучать это не требуется но базовые понимания нужны чтобы не получать медленное приложение только потому что не знал что каждый твой запрос в tcp это 'туда-сюда', и это медленно (десятки миллисекунд), что одновременно два человека пытающиеся что то изменить на сайте нужно разруливать чтобы не было конфликтов и т.п.
* бакэнд и фронтэнд
буквально что значит запрос и генерация ответа, какие бывают способы организации этого бакэнда (http rest и к примеру websocket), не понимание разницы между бакэндом и фронтэндом у новичков рождает абсурдные вопросы как из javascript изменить переменную php (и наоборот)... в чем разница между генерацией страницы на сервере и в браузере.
* html, css,..
верстка и дизайн, отдельный мир браузерных стандартов, исторических наслоений,. когда стоит применять фреймы, почему шрифты по разному выглядят, разные устройства и размеры экранов, разные способы взаимодействия (сенсорный экран, мышь, клавиатура)...
* базы данных
еще более огромный мир атомарных транзакций, индексов, нормальных форм и прочего
* девопс
без умения выбрать инструмент, настроить тулчейны, среду разработки, среду исполнения (веб сервер), настроить бакапы и прочее пытаться что то разрабатывать это как в слепую гулять по лесу, будешь постоянно на ветки натыкаться
...
это я еще про системную аналитику не сказал, обычно прежде чем что то создавать, нужно продумать как это все делать, что такое технический долг и т.п., а еще есть тестирование, обслуживание, работа с отказами (сервер сдох, база упала, как все восстановить), обновление на живую и прочие веселья

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