NikitaLikosov

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

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

Совет один - настройте https и перестаньте бояться "взломов". Лучшей защиты чем чем это вы все равно ничего не сделаете сейчас.

Конечный автомат — это ограниченное количество состояний, входные сигналы для перехода между состояниями и выходящие при этих переходах, а также сигналы текущего состояния. В теории их делят по выработке сигналов, но на фронтенде всё смешивается всё равно.
И важно помнить, что для фронтенда "конечный автомат" применяется в большей степени для процесса, а не значений. То есть, состояниями будут, например, являться:
• инициализация/загрузка документа — что до события download,
• открытое модальное окно,
• передача данных из формы,
а сигналами будут как раз события:
• ondowload сигнал для перехода из состояния загрузки в состояние готовности,
• клик по определённой кнопке — это сигнал для закрытия модального окна, например.
• submit формы
• response или reject — ответ на форму,
ещё сигналы из таймеров подойдут:
• таймаут загрузки, как самое очевидное,
• циклическая подгрузка, типа для новостей.
И по теории автоматов должно быть так, чтобы переход из одного состояния в другое всегда сопровождался определённым сигналом. Например, бесконечная лента записей из состояния просмотра по сигналу "докрутили до конца" переходит в состояние "подгрузка". Но ведь пользователь может крутануть назад и вперёд, что опять породит сигнал "докрутили до конца", но из состояния "подгрузка" не должно быть переходов по этому сигналу, а потому не должно быть и повторного запроса на сервер.

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



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

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

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

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

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

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

но и нагрузка большая на сайт не предвидится

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

document.getElementById('button').addEventListener('click', function(e) { //тут ID-кнопки
  e.preventDefault();
  if (this.innerText == '0') {
     return;
  } else if (this.innerText == '1') { 
     alert('Значение 1');  
  } else {
     window.open('https://site.ru');
  }
});