Никита Геннадич

Во-первых в setState в корень предыдущее состояние передавать не нужно, так под капотом к нему так и так подмешается предыдущее состояние, в не зависимости от того, что вы туда передадите. Примерно так:
state = { ...prevState, ...newState };

Во-вторых не правильно передавать в setState this.state, так как setState выполняется асинхронно и ваше текущее состояние может успеть измениться. Если надо обновить состояние на основе предыдущего, в setState по-хорошему надо передавать функцию, в которую первым аргументом при вызове придет ваше состояние:

this.setState(prevState => ({
  some_data: {
    ...prevState.some_data,
    ...input,
  },
});

Самый лучший вариант - не использовать стейт. Вообще. Зачем он для чекбоксов? Это настолько раздуто и избыточно в 99% случаев, что хочется рвать волосенки на голове каждый раз, когда кто-то это использует. К счастью, React предоставляет uncontrolled inputs, чем я вам и рекомендую воспользоваться. Поскольку каждый раз, когда для таких компонентов используется стейт, означает, что данные сохраняются для последующей обработки, а последующая обработка в 99% случаев - отправка формы или иные ее события.

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

Первый вариант будет лучше если у вас форма и компонентов много. Можно обрабатывать все одним хандлером:

const handler = (e) => {
  const { target } = e;
  const value = target.type === 'checkbox' ? target.checked : target.value;
  const { name } = target;

  setForm( f => ({ ...f, [name]: value }));
};

Второй, если checkbox один и приложение должно как-то реагировать на его изменение. Но хандлер для лучшей читаемости, лучше вынести в переменную. Если это built-in компонент вроде input:

const handler = () => {
  setX(!x);
};

И если это кастомный компонент, то необходимо использовать useCallback, чтобы предотвратить лишние перерисовки:

const handler = useCallback(() => {
  setX(!x);
}, []);

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

Link от Next.js принимает только один параметр, поэтому пришлось всё содержимое в Link обернуть в React.Fragment.

import React, { Component } from 'react';
import { withRouter } from 'react-router-dom';

class Example extends Component {
  handler = () => {
    this.props.history.push('/cources');
  };
  
  render() { /* ... */ }
}

export default withRouter(Example);

Возможно, вам подойдет простой вариант с компонентом Link:

import React, { Component } from 'react';
import { Link } from 'react-router-dom';

class Example extends Component {
  render() {
    return <Link to="/cources" />;
  }
}

export default Example;

{Object.keys(cities).map(cityId => (
  <div key={cityId} className="card-panel">
    {cities[cityId]}
  </div>
))}

Проблемы решены:
первая из них решилась из подсказки самого окна
sc.exe query vboxdrv
в моем случае сервис был выключен. Далее сервис/службы -> включение. Перебираем типы запуска и пытаемся запустить.

вторая из них решилась выполнением первой из рекомендации с официального форума https://forums.virtualbox.org/
а именно:
sfc /scannow
1. Выполняем ждем -> нашлись ошибки -> перезагрузка.
2. Повтор шага 1.
3. Профит

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

Доброго времени суток!

У компонента Route есть параметр render.

<Route
  render = { props => logged ? <Product /> : <Redirect to='/' /> }
  exact
  path='/products/:id'
/>

И важно, в доках об этом конечно сказанно, но я повторюсь.
component имеет приоритет над render, так что использовать их вместе не стоит.

На сколько я помню, блютус не очень любит столько подключений

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

В качестве кодека берите VS1003
В качестве приемника и передатчика сойдет NRF24L01

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

На счет каналов, тут надо ставить на 2 колонки один NRF24L01, в формате MP3 записано где R и L, а VS1003 сам умеет выдавать звук куда надо

Я увидел в Вашем вопросе две части.

Как правильно организовать деплой (выкладку работоспособного кода на сервер)?

В самом простом случае Вам подойдет связка ssh + git pull на сервере. В этом случае на сервер будут доставлены патчи коммитов, которые есть в репозитории, но еще не появились на сервере, т.е. «только обновления файлов, которые сейчас существуют». Этот метод довольно подробно обсудили в ответах на другой вопрос.

Если хочется автоматизировать процесс, что похвально, то я вижу три доступных инструмента для этого: Capistrano, Mina (мой персональный фаворит) и Vlad the Deployer. Все три проекта схожи по сути. Принцип их работы таков:

1. Подключиться к целевому серверу.
2. Залить обновление кода из репозитория.
3. Выполнить предписанные Вами инструкции (перезапуск демонов, сброс индексов, обновление структуры БД и прочее).
4. ...
5. PROFIT!

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

Как организовать процесс тестирования?

Если Вы еще не определились с методикой тестирования (Test Driven Development, Behavior Driven Development, Лень-Driven Development), то Вам следует для начала заняться именно этим.

Скорее всего, тесты будут выполняться на Вашей локальной машине, пока Вы пишете код. Используя RSpec, я держу открытым Guard. Guard отслеживает изменения в коде и запускает набор юнит-тестов, которые покрывают измененный код. Весь процесс занимает не больше минуты-двух, и особо не напрягает. Как только я вижу провалившийся тест, я меняю код до тех пор, пока он не станет зеленым. Пока тестов мало (это не самый лучший знак, к слову), Вы работаете один, локального запуска перед деплоем может оказаться достаточно — например, чтобы проверить релиз на доступность критического функционала: регистрации, покупки, создание постов и т.п.

В какой-то момент речь может зайти о Continious Integration. Это возможность иметь стабильный билд в любой отрезок времени, а так же принимать решение о годности каждого отдельного коммита. Сопряжено с деплоем кода на integration-сервер и запуском на нем тестов. Скорее всего, это Вас не интересует, если Вы не работаете в команде. Но, для полноты картины, Вы можете понаблюдать за билдами на Travis CI известных Open Source проектов: Symfony 2 и Ruby on Rails.

Таким образом

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

Приведите в порядок Ваш репозиторий с кодом, используйте mina для деплоя и запускайте тесты на Вашей локальной рабочей машине. Как только Вы почувствуете, что этого не достаточно — Вы наверняка уже будете знать, куда шагать дальше.

https://jsfiddle.net/space2pacman/0f9ug7r3/1/