Иван

Вообще использование в render конструкций типа:
{this.state.data[0].title}
очень плохой стиль. По возможности избегайте его.
Чтобы компонент рендерился поле загрузки данных:

render() {
  const { data } = this.state;
  const isAllDataReady = data && data.length > 0;

  return (
    <div>
       {!isAllDataReady && <Preloader />}
       {isAllDataReady && (
         <div>
           <h4>App component</h4>
           {data[0].title}
         </div>
       )}
    </div>
  );
}

Центральный показатель для бизнеса, а следовательно и руководителей, как людей представляющих интересы этого самого бизнеса - это коэффициент возврата инвестиций (ROI). Соответственно, сотрудник должен приносить компании больше денег, чем потребляет. Естественно, что чем выше разрыв между затратами и прибылью, тем лучше, поэтому фонд оплаты труда руководитель должен держать на том минимальном уровне, который гарантирует бесперебойную работу сотрудников. Один из факторов этой бесперебойности - низкая текучка. Сотрудников терять нежелательно. И чем ценнее для компании сотрудник, чем более он профессионален и/или чем больше на него завязано, тем дороже обходится его потеря. Натурально в деньгах. Придётся затратить больше, чем обычно, денег на поддержание работы без него. Придётся затратить деньги и время (те же деньги) на поиск, найм, введение в работу, возможно, обучение нового сотрудника. При этом он может оказаться совсем неподходящих и цикл придётся повторить. Или может оказаться просто хуже прошлого и эффективность отдела снизится. Поэтому, когда сотрудник приходит просить прибавку, руководитель оценивает может ли этот сотрудник уйти или только блефует, насколько легко его будет заменить, какой урон компании будет нанесён его уходом. Потом руководитель оценивает стоимость расширения ФОТ - есть ли резервы, какой сейчас ROI, будет ли больший ROI от реинвестиции этих средств во что-то другое? Если уход сотрудника будет стоить меньше, чем увеличение ФОТа, сотруднику откажут.

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

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

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. Вы не уверены, что подав на вход: имя, текст комментария и почту - получите ТОТ же результат, что и в прошлый раз с такими же входными параметрами (айдишники то разные будут!)

prompt возвращает string при нажатии Ok и null при нажатии Отмена:

var x = prompt("введите число");
console.log(typeof x); // string

Можно переписать так если надо просто приводить к числу:

var x = +prompt("введите число");
console.log(typeof x); // number при условии, что строку можно привести к числу

Строгое равенство при сравнении разных типов всегда возвращает false:
'0' === 0 // false

Если вам надо делать проверки на нажатие Отмена, ввод пустой строки или нечислового значения, приведение стоит делать после этих проверок:

var input = prompt('Введите число: ');

if (input === '') {
  alert('Пустая строка');
} else if (input === null) {
  alert('Вы нажали "Отмена"');
} else if (Number.isNaN(+input)) {
  alert('Вы ввели не число');
} else if (+input === 0) {
  alert('Вы ввели 0');
} else if (+input > 0) {
  alert('Вы ввели число больше 0');
} else {
  alert('Вы ввели число меньше 0');
}

isLoading - состояние только компонента item ? Так храните его в item )

Опционально добавляется регулярное выражение в query string запроса, доступное по ключу description2__regex.
Если вопрос только по синтаксису, то испльзуются шаблонные строки.

let { attachment } = data.response[1];

attachment = attachment[attachment.type];

На моей практике такие штуки только запутывают код. If you ask me, как говорится, я бы это расписал на несколько редьюсеров сам. Проще читать, проще поддерживать.
Я считаю, что код надо писать для людей, а не для машины.

В 6-й строке
price = $('#cart_price_' + id).html()
попробуйте заменить на
price = parseFloat( $('#cart_price_' + id).text())

Вычисление total:

var tot = 0;
$('.total').each(function (t, e) {
  tot += Math.round(parseFloat($(e).text()) * 100);
});
tot /= 100;

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

то есть
function(num1[, ...[, numN]])
говорит, что это может быть и
function(1) и function(1,1,1,1,1)

А например запись типа:
function (x, y[, z])
означает, что x,y - обязательные параметры, z необязательный. Поэтому можно вызвать и
function (1,2) и function(1,2,3), но не function(1,2,3,4)