Максим

Для первого варианта: попробуйте file-loader (а не просто file).

Для второго варианта: картинку надо брать из public директории.

output: {
    path: path.join(__dirname, 'dist'),
    filename: 'bundle.js',
    publicPath: '/static/' // название директории
  },

<img src='./static/popup-illustration.png' />

Во втором случае картинка не попадет в webpack, а будет отдана как есть.

Чего-то здесь не хватает... логика поиска проблемы правильная. Если в вашем редьюсере в консоль падает то, что нужно, значит следуйте дальше: в компонент, где этот редьюсер подключен и смотрите внутри mapStateToProps так же с помощью консоли, изменились данные или нет. Правильно ли вы их подключили и т.д. (получается вам надо проверить и SideBar и SideBarChat)

Запрос к апи разумеется в экшене (ну если быть точнее, то в AC - action creator, функции, которая диспатчит ваши экшены). Сессию храните где вам удобнее. Если бы это был JWT - можно было бы хранить в localStorage, хотя по этому поводу много споров (безопасино или нет в LS хранить).

function mapStateToProps(state) {
    console.log(state) // и здесь смотрите, есть ли у вас в state - state.potato, если нет, значит забыли это сделать в корневом редьюсере. А если есть, то смотрите что у вас хранится в state.potato.products
    return {
//potate-store
        products: state.potato.products
    }
}

Скиньте свой корневой редьюсер, который вы передаете в configureStore функцию, если не разберетесь.

React-modal хорошая библиотека, ничего лишнего, я бы рекомендовал оставить ее.
Как сделать модалку:
на том уровне, где у вас отрисовывается каталог, или даже выше - вы рисуете модальное окно и ему передаете признак, по которому оно открыто, например: isProductModalOpen (true / false). Этот код находится в "контейнере", приконекченном к redux.

Далее при клике на кнопку подробнее, вы бросаете экшен OPEN_PRODUCT_MODAL + айдишник товара (который будете запрашивать с сервера) или + всю инфу о товаре, если она у вас уже есть и вам ничего не нужно запрашивать.

Редьюсер, отвечающий за модальные окна принимает этот экшен и обрабатывает. В частности устанавливает значение, на которое вы опираетесь в контейнере и делаете true для флага isProductModalOpen

По закрытию модалки - так же улетает экшен, который обрабатывается в редьюсере и признак isProductModalOpen ставится равным false.

Готово!

Такой подход позволяет делать несколько модальных окон разных типов.

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

p.s. если найду видео добавлю, там была презентация. пока не нашлось.

import React, { Component } from 'react';

class SearchBar extends Component {
  constructor(props) {
    super(props);

    this.state = { term: ' ' };
  }

  render() {
    return ( // в круглых скобках возвращаем, если более 1й строки
      <div>
        <input onChange={event => this.setState({ term: event.target.value })} />;
      </div>
    )
  }
}
export default SearchBar;

Насколько я понял, это связано с работой OrderedMap.
OrderedMap.map по умолчанию возвращает не массив, а объект.

Откуда берется название?
По факту откуда - не важно. Важно, там где оно есть его передать. Если это title страницы, можно вытащить его стандартным методом (document.title). Можете хранить одно значение "предыдущая страница" или всю историю брождений по вашим "страницам" в редьюсере или sessionStorage (если без redux или не хотите засорять), а класть данные туда с помощью коллбэка в onpopstate

Следовательно, если у вас redux - то нужно писать так:

window.onpopstate = function(event) {
  sendLastPage(document.location, document.title);  // ваш_экшен_крейтор(данные_для_передачи)
};

Если без redux - то аналогично, складывая в sessionStorage

Если вы будете использовать ref, то значит вы будете иметь доступ к DOM элементу, значит и валидацию надо делать "дедовским" способом, через навешивание обработчиков onChange на все ваши ref'ы (на всю вашу форму тоже получится, зависит от задачи).

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

Основы по браузерным событиям (learn.javascrip.ru).

Разумеется что нет. Рендерится (перерисовывается) только "та часть" (тот компонент), в которой были изменены пропсы/стейт + все дети если в них нет оптимизаций (например, они могут быть сделаны как stateless, pureComponent или иметь shouldComponentUpdate - тогда перерисовываться не будут при описанных условиях).

вижу обновили вопрос: да, только футер.

case ADD_PRODUCT_TO_CART_SUCCESS: {
  return state.setIn(["entities", payload.productUid], {...payload.product, count:  ВАШЕ_КОЛИЧЕСТВО});
}

В этом коде мы берем все что было в payload.product и по 1 полю добавляем в новый объект ( фигурные скобочки = новый объект), а так же добавляем поле count. Количество (count) вы так же, наверняка, будете передавать в экшене. Получится: count: payload.count (или как вы назовете поле в вашем экшене...)

Пример:

{ type: ADD_PRODUCT_TO_CART_SUCCESS,
    payload: { productUid, product, count: ваше_количество } // сюда count можно передавать из функции с помощью которой ваш экшен был создан...
  }

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

Пример: есть у вас в localStorage имя пользователя. И вы в коде пишите, что-нибудь такое:

case SET_DISPLAY_NAME: {
  return {
    ...state,
    name: window.localStorage.getItem('name') ? window.localStorage.getItem('name') : action.payload,
  }
}

Следовательно, если вы подадите на вход функции, имя Вася, то оно вам вернет Васю только если "в sideeffect локал_сторадже" нет ничего. Здесь вы не можете быть уверены, что если подать Васю, вам всегда вернется Вася.

По примеру с комментариями - не думаю что хороший пример. Айдишники генерировать будет бэкэнд ваш. Вы добавляете новый комментарий путем отправки его на сервер, с сервера приходит статус "ОК" и ваш комментарий уже с айдишником.

Бывает, что айдишники нужно генерировать самому, тогда они отлично генерятся в acftionCreator'ax. Например, делаете вы систему уведомлений, и у каждого уведомления должен быть свой id (например, тут сервер вам не нужен, вы ничего туда не отправляете, просто визуальная часть). В таком случае, я бы не стал генерировать id через middleware, а просто делал бы это в "экшенах".

Тем не менее, с генерацией айди все тоже самое, что и с localStorage. Вы не уверены, что подав на вход: имя, текст комментария и почту - получите ТОТ же результат, что и в прошлый раз с такими же входными параметрами (айдишники то разные будут!)

Нет никаких defaultValue у select.
Если вам нужно сделать какое-то значение в select выбранным по умолчанию, то просто укажите value у тэга <select>

документация