Антон Спирин

Выполнить в директории склонированного проекта:
npm i

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

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

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

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

Virtual DOM React не имеет никакого отношения к DocumentFragment. Отсюда назревает ответ на ваш вопрос, что реализация отличается всем.

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

Virtual DOM это лишь упрошенная модель DOM-древа, никаких алгоритмов Virtual DOM не использует, это делает ReactDOM при сверке древа. Никаких вставок Virtual DOM в реальный DOM не происходит. Хотя бы по причине полной несовместимости.

Если вам действительно интересно как происходит работа с Virtual DOM и сверка в React, то можете прочитать одну из многочисленных статей на эту тему.

JSX код компонента и HTML-элементы это совершенно разные вещи. Так делать нельзя.

Ваша задача, по-хорошему, решается одним css правилом:

.my-svg-selector:hover {
  fill: red;
}

О преимуществах и недостатках использования иммутабельного обновления данных написан не один десяток статей. Библиотека React использует эту концепцию для отслеживания изменений состояния и свойств компонентов.

И зачем при выполнении setState() делать копию массива users, если в новый массив все равно копируются только ссылки на объекты, а не сами объекты? Только для того, чтобы в state появилась ссылка на новый массив и React задетектил изменение?

Именно для этого.

Зарубежом книга не переиздовалась. Уловки местных издателей или ошибки поправили. Смело читайте старую. И на будущее - всегда проверяйте первоисточники.

Состояние коллекции пользователей лучше хранить в одном редьюсере.
Если в приложение подразумевается работа с одной активной сущностью, то для нее лучше сделать отдельный редьюсер. В этом случае может быть удобным использовать один ключ для редактирования, сохранения и удаления.
Если подобные ключи нужны для работы с коллекцией, например быстрое редактирование, добавление и удаление в таблице. То можно использовать коллекцию состояний:

{
  isFetching: {
    'ALL': false,
    '122bc-e43gf-24002-12ea1-ca785': true,
  },
}

Где всегда есть свойство для всех сущностей и опционально добавляется для нужных элементов по id.

Вам надо снести старые пресеты babel-preset-stage-0 и babel-preset-env, и поставить @babel/preset-stage-0.
Как правильно написать конфигурацию сотрите в репозитории babel-loader.

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

Стандартной практикой является создать директорию actions и хранить действия в одноименных c редьюсерами файлах. Пример:

хотелось бы получить что-то подобное

Какая-то ерунда. Смешали действия и combineReducers, какого эффекта при этом пытаетесь добиться непонятно.

Советую использовать библиотеку redux-act. Сокращает бойлерплейт.

В calculateCalories вместо вызова setState следует возвращать вычисленное состояние:

class Day extends React.Component {
  state = this.calculateCalories();

  calculateCalories() {
    /* ... */
    return {
      calories,
      fat,
      protein,
      carbs,
    };
  }

  handleClick = () => {
    this.setState(this.calculateCalories());
  };
  
  render() {
    ...
  }
}

Еще почитайте про статический метод getDerivedStateFromProps. Возможно подойдет.

Ну и если не подразумевается изменение состояния, то нет особого смысла туда писать данные, их можно использовать напрямую из props.

Видимо, потому что на странице отсутствует возможность скролла. Весь контент помещается в высоту окна.
Если это так, то для подобных кейсов используют событие mousewheel. Для кроссбраузерной обработки этого события, если важна одинаковая скорость скролла в разных браузерах, надо использовать адаптер, вроде normalize-wheel

Умные люди научили меня не мутировать state и делать примерно так

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

против такого способа выступает официальная документация, где сказано - не мутируй state и избегай forceUpdate(), это может привести к непрогнозируемым багагм.
Так я хочу спросить - ПОЧЕМУ так нельзя делать и КАКИЕ негативные последствия это может иметь?

Ну вы же сами пишите, что читали, что это может привести к непрогнозируемым багам.

Мне кажется, что в простых ситуациях, мутация state и немедленный вызов forceUpdate() будет работать не хуже setState, при этом код будет внятней и эффективней.

А как вы собираетесь контролировать эти простые ситуации?
Каждый раз внося изменения в код, вам придется изучать все древо, чтобы понять, что у вас обновляется мутированием, а что иммутабельно.
Код с винегретом из мутирования и иммутабельного обновления будет очень трудно поддерживать, а баги, скорей всего, будут вылезать в самых неожиданных местах.

Если вам нравится подход с мутациями, то вы можете попробовать использовать с React библиотеку MobX.

Тут написано только про точечную и скобочную запись

Это и есть property accessors.

но я знаю что есть get и set.

Если вы про геттеры и сеттеры, то к ним так же обращаются с помощью property accessors.

Условный рендеринг.

Оберните App в withRouter:
export default withRouter(App);

Добавьте условие:

const shouldShowFooter = this.props.location.pathname !== '/basket';

Отображайте футер по условию:
{shouldShowFooter && <Footer />}

Подъем состояния:

const Foo = () => {
  const [shouldShowBar, setShouldShowBar] = useState(true);

  const handleBarClose = useCallback(() => {
    setShouldShowBar(false);
  }, []);

  return (
    <>
      {shouldShowBar && <Bar onClose={handleBarClose} />}
    </>
  );
};

Если это простое модальное окно, которое надо показывать по клику и подобные окна планируется использовать во многих местах, то для удобства их использования можно реализовать обертку, в которой будет использоваться прием render-props:

const Foo = ({ onConfirm }) => {
  return (
    <ModalWrapper
      onConfirm={onConfirm}
      body="Hello"
    >
      {showModal => (
        <Button onClick={showModal}>Show modal</Button>
      )}
    </ModalWrapper>
  );
}

Это позволит не плодить во всех компонентах, где одни будут использоваться, логику их состояния.

Если это билд create-react-app, то будет. Create React App: Deployment
Если это билд изоморфного приложения с SSR и express сервером, то нет.
Если третий вариант, то надо больше деталей, чтобы сказать точно.

Что-то изменится если это будет блог/интернет-магазин?

Если нужна нормальная индексация в поисковых системах или шаринг в социальных сетях, то нужен SSR или пререндер страниц. Тут простым хостингом не обойдешься.

Попробуйте добавить в лоадер
exclude: /node_modules/
А в tsconfig.json можно добавить:
"allowSyntheticDefaultImports": true,
и использовать нормальный импорт в коде:
import React from 'react';

Проблема, насколько понял, в том, что свойство "allowSyntheticDefaultImports" установленно в значение false, лоадер парсит библиотеки в node_modules, а дефолтные импорты React сделать с текущими настройками не может.

Метод находится в прототипе.
Конструктор вызывается при создании экземпляра.
Когда вы создаете экземпляр, прототип уже давно определен.