Почему не обновляются props после dispatch?

Покажите код где стор диспатчите.

Как сделать новое наблюдаемое свойство в наблюдаемом объекте?

Егор Живагин, не было объективных причин использовать с react. В маленьких примерах, конечно, красиво выглядит.

Как отловить момент смены направления скролла?

весь код скиньте. Не понятно, где вы этот метод вызываете.

Как сделать новое наблюдаемое свойство в наблюдаемом объекте?

Егор Живагин, знаю я что такое observable. Есть опыт. Не пробовал mobx, но настораживает. Это не альтернатива redux, тут серьезно надо архитектуру планировать, если писать, что-то сложнее ExampleApp.
По мне это шаг назад. Flux архитектура разрабатывалась как альтернатива таким подходам, решающая многие архитектурные проблемы.

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

Как сделать новое наблюдаемое свойство в наблюдаемом объекте?

Нескромный вопрос. Зачем вам вообще observable в react?

Как использовать High-Order-Reducer, react/redux?

cester, вы бы задачу описали доходчиво, что в итоге получить хотите, а то говорите про HOR, а в итоге нужен boilerplate, так как HOR у вас только withTodo.
Вы бы еще свой код скидывали, а не абстрактный.
Селекторы теперь вроде таких:

export const getIsLoadedSelector = ({ apps }) =>
  customReducer.todoReducer.delete.isLoaded;
export const getIsLoadedSelector2 = ({ apps }) =>
  customReducer.todoReducer2.delete.isLoaded;

Для селекторов используйте reselect. В этой библиотеке реализована меморизация и при изменении состояния на аналогичное не будет лишних вызовов.
combineReducers можно использовать сколько угодно.

Скиньте свой настоящий код и внятно опишите задачу, без этого не ясно, что вам лучше посоветовать.

Как правильно унаследовать компоненты чтобы не дублировать код?

Dubrovin, насчет js вы сильно заблуждаетесь. Нет никакого смысла оставлять код в ES6. Так как, например, классы это лишь синтакисческий сахар над прототипами и ничего более.
Не знаю зачем вам ES6 в готовом коде, нет ни одной объективной причины не транслировать его в кроссбраузерный код, как делают все. К тому же для разработки вы можете добавить source maps. Сейчас ваш код не кроссбраузерный. Про полифилы, я полагаю, вы тоже не слышали.
Попробуйте найти хоть один объективный ответ на вопрос почему вы не транслируете код. Я думаю, что кроме каких-то придуманных суеверий не найдете, а минусы вашего подхода очевидны. Советую тестировать ваш код в разных версиях браузеров.

Насчет css-modules это уже вам точно не подходит, так как рендер у вас на беке. БЭМ не надо воспринимать как аксиому и набор истин, это лишь методология для стандартизации и изоляции css кода. Многие проекты использующие фреймворки давно от БЭМ отказались в пользу лаконичного, модульного css, с которым гораздо проще работать.

Зря не используете шаблонизаторы и фреймворки на бэке. Делаете много лишней работы которая реализована во фреймворках. Если ваш компонент Component завязан на реализации, а не абстрагирован от нее, то это очень плохо.

Еще вы неправильно используете let в коде. let принято использовать для значений которые изменяются, для не изменяющихся значений принято использовать const.
Так же не ясно чем вы руководствовались когда определяли _this, вместо того чтобы использовать стрелочные функции. И не ясно, что делает toggleValue в конструкторе. Не ясно почему не определен базовый компонент.

Вот вам навскидку, банальнейший, правда, сырой пример, как можно избежать дублирования и макарон в коде https://jsfiddle.net/rockon404/dwk7xsj4/
Не стоит использовать это решение не подумав и не доработав. Это так, поразмышлять.
Представьте как можно написать Switch унаследованный от Component, с приблизительно таким интерфейсом создания:

const checkBox = new Switch({
  el: ...,
  toggler: 'checkbox__input',
});

const mySwitch = new Switch({
  el: ...,
  toggler: 'checkbox__switch',
});

Как правильно унаследовать компоненты чтобы не дублировать код?

Dubrovin, ваш подход к организации модулей устарел. Вам достаточно использовать babel и вы сможете писать модульный код в со всеми удобствами ES6 и хоть stage-0.
Webpack + babel отличное решение для сборки js. На выходе вы получите один минифицированный поддерживаемый всеми браузерами бандл или при желании несколько с выделенной common частью.
По модулям это не он их так пишет, а библиотека выдает изолированный сгенерированный код. А он пишет:

.select {}
.loading {}
.item {}
.icon {}

вместо:

.select {}
.select__item {}
.select__item__icon {}
.select--loading {}

SPA не означает, что в приложении одна страница, а лишь то, что все(а можно и не все) приложение загружается в браузер, роутинг осуществляется на клиентской части, а работа с сервером только через JSON. Для всяких панелек конфигурации и прочих dashboard SPA отлично подходят.

Что-то конкретное в вашей ситуации посоветовать тяжело, я так понимаю на беке у вас Twig + css + js и все это надо друг с другом дружить, при этом полностью отсутствует задача рендера на клиенте?

Как использовать High-Order-Reducer, react/redux?

cester, как-то так, если я все правильно понял:

import { combineReducers } from 'redux';

const createAsyncReducer = entityName =>  (state, action) => {
  const { type, payload } = action;

  switch (type) {
    case entityName + '_REQUEST':
      return {
        ...state,
        isFetching: true,
      };

    case entityName + '_SUCCESS':
      return {
      ...state,
      isFetching: false,
      data: payload,
      error: null,
    };

    case entityName + '_FAILURE':
      return {
        ...state,
        isFetching: false,
        error: payload,
      };

   default: return state;
  }
}

const todoReducer = withTodo(createAsyncReducer('TODO'));
const todoReducer2 = createAsyncReducer('TODO2');

export const customReducer = combineReducers({
  todoReducer,
  todoReducer2,
});

Но тут стоит добавить initialState.
Итак вы не получаете actionTypes.
Возможно упрощать не стоило. Либо генерировать и их.

Как использовать High-Order-Reducer, react/redux?

Александр, это интерфейс из приложения над которым сейчас работаю. reducer подключается в entitiesReducer, saga в rootSaga, selectors - это функции селекторы для выделения нужных элементов из объекта состояния, actions - тут все понятно, actionTypes и api опциональные ключи которые в основном не используются. Реализацию скинуть не могу, так как писал не я, но там нет ничего сложного.

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

Про то, что в вашем решении не нарушается Flux расскажите кому-нибудь другому. Вы либо не понимаете идеологии, либо прикидываетесь.

Как использовать High-Order-Reducer, react/redux?

Александр, начинается, переключили внимание со своей не работающей шарманки на мой код.
Да, я по-невнимательности не заметил, что именно автор хочет и что содержится в todosReducer и todosReducer2, и в корне неправильно понял суть задачи. Моя ошибка, невнимательность. Написал полную бурду.

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

Ваш хелпер на самом деле недо подобие redux CRUD boilerplate. Который, помимо всего еще и нарушает концепции FLUX.

К тому же, во время обновления одного пользователя сработает общий loadingProp и errorProp, что неправильно. Как и то, что ключ для сущности можно завести только в корне store.
Я бы порекомендовал остерегаться таких решений и использовать полноценный CRUD boilerplate работать с которым будет значительно удобней чем с вашей шарманкой.

Посмотрите как выглядит интерфейс нормального CRUD генератора:

const {
  reducer,
  saga,
  actions,
  selectors,
  api,
  actionTypes,
} = generateCrudBoilerplate(
  'products',
  {
    getList: () => `/api/products`,
    getOne: id => `/api/product/${id}`,
    add: payload => `/api/product/`,
    remove: id => `/api/product/${id}`,
    edit: (id, payload) => `/api/product/${id)`,
  }
);

Посмотрите как выглядит ваша шарманка. Делайте выводы.

Как правиль загрузить api в react?

mr jeery, ну это что-то вроде:

const fetchInitialDataApi = () => axios.get('http://swapi.co/api/people/?format=json');

или:

const fetchInitialDataApi = () => fetch('http://swapi.co/api/people/?format=json')
          .then(res => res.json());

В случае с fetch, вроде надо поменять строку:
const { data } = await fetchDataApi();
на:
const data = await fetchDataApi();
Давно его не использовал, не помню.
Советую установить axios.

Как правиль загрузить api в react?

mr jeery, ну так делать нельзя:

if (action.type === 'GET_DATA') {
    return { data: API() }
  }

Вы ведь возвращаете промис и компонент успеет обновиться, до того как приходит асинхронный ответ. Поэтому данных не видно. Тут обязательно надо использовать middleware. redux-thunk вам для обучения за глаза хватит.

Как правиль загрузить api в react?

mr jeery, добавьте babel-polyfill

Как использовать High-Order-Reducer, react/redux?

cester, вам для вашей задачи надо не HOR реализовывать, а CRUD boilerplate.

Как использовать High-Order-Reducer, react/redux?

Александр, я импорты не добавлял для простоты примеров.

Как видите используется именно ваша шарманка и она не работает. Сожалею. Не используется только функция resetState.
Я в разработке давно использую stage-0. Ваши, советы о том как запустить ваш некорректно работающий велосипед не к месту.

1. Вы видимо даже не понимаете за счет, чего компоненты обновляются и что такое HOC. А в силу, видимо, своих поверхностных знаний о реализации архитектуры которую предоставляет redux, даже не осознаете, что рушите ее.

Для обновления компонентов, как минимум, нужен react-redux, которого в зависимостях нет. Вы, видимо, даже вопрос не поняли.

Зачем эти велосипеды? Используйте хоть window._store , интерфейс для его имутабельного обновления и HOC для обновления компонентов и разницы не будет, но вы зачем-то глумитесь над redux.
А самое главное сами не имеете четкого представления о том, что делаете. Вам, видимо, очень хочется иметь в названии вашей поделки префикс redux-.

2. Вы поняли? Вы, видимо, ничего не понимаете. Особенно о том, что делаете и зачем. Господи, вы еще и над реализацией redux глумитесь. Остановитесь.

3. Серьезно getState()? И дать на откуп разработчикам. макароны путей всего объекта состояния, а так же сделать приложение трудно изменяемым и плохо масштабируемым? Как вам кейсы использованием одного и того же ключа в разных частях приложения и для разных целей, redux полностью это исключает. А вы это поломали. Ошибки разработчиков в путях:
getState().some.path.somePath2.somePath3;
Видимо следует ловить через консольку?
А как вы собрались масштабировать store?
Переписывать пути во всем приложении?
Или тянуть в ваши функции селекторы.
Модульность? Теперь ничто не гарантирует, что я не поломаю своими ключами старый функционал.

Тут все недостатки не перечислить, так как нарушение самой концепции flux затемняет собой все остальное. Выше я уже писал и о сайд эффектах и middleware, масштабировании, devTools и прочем. Самое главное, что состояние теперь изменяется не диспатчем(хотя под вашей оберткой именно им), а самим разработчиком и это рушит все.

Опубликуйте сылку на свою шарманку на reddit и вас там распнут, и правильно сделают.

Как правильно унаследовать компоненты чтобы не дублировать код?

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

БЭМ макарон вообще можно избежать, если использовать css-modules. А с React Styled Components вообще можно забыть о селекторах.

Так же не ясно зачем вы клеите файлы конкатом и используете такую бороду в названиях:
ksf.classes.KsfSwitch = ...
У вас даже в таких мелочах костыли. Вы не знаете как правильно использовать модульную систему ES6?

К слову, вес библиотек:
React 16.2.0 + React DOM GZipped 31.8Kb
Vue 2.4.2 GZipped 20.9Kb
Preact 7.2.0 GZipped 4kb
Но для вашей задачи безразлично, хоть 300Kb. Только вы этого, видимо, не понимаете.

Как правильно унаследовать компоненты чтобы не дублировать код?

Dubrovin, очевидным решением в вашем случае было бы использовать React или Vue. Как раз для вашей задачи один их этих инструментов бы здорово подошел. Backbone это старая библиотека, но ее исходный код легко читаем и оттуда можно подчерпнуть немного знаний. Использовать ее сейчас я бы не советовал.
Где вы прочитали, что" фреймворки, как правило, тяжелые"? Что за нелепая оценка рациональности использования инструмента? Если вам большинство опытных программистов отвечает "шаблонно" использовать фреймворк, значит на то есть ряд очевидных причин. Погуглите причин очень много.
Вы, видимо, пока не поняли сути разработки, вы называете 'говнокодерами' тех кто использует jquery, хотя jquery бы сильно упростил вам жизнь с тем что вы делаете сейчас, но вы в силу неопытности этого не понимаете и по сути являетесь теми самыми "говнокодерами" о которых говорите, уж простите. Вы вообще ничего не понимаете в фронтенд разработке, но пишите, что сделаете лучше многих.
Все что вам надо было сделать это изучить React и написать это приложение за пару дней без боли, слез, велосипедов и вопросов на Тостере. В итоге, вы пытаетесь повторить ошибки неопытных разработчиков 2015 года, которые знатно тогда огребли на хайпе VanillaJS и давно переписали свои проекты на фреймворках.

Как использовать High-Order-Reducer, react/redux?

Александр, это в продакшене в двух проектах? Не смешите. Вы же написали это в середине декабря. При этом, эта шляпа даже не работает.
Такой вот простой кейс ломает содержимое вашего ключа:

const store = createStore({ counter: 0 });
const getState = store.getState;
const setState = store.setState;

const increment = () => {
  setState({
    type: 'counter',
    counter: getState().counter + 1,
  });
};

increment();

Такой тоже ломает:

const store = createStore({ counter2: { value: 0 } });
const getState = store.getState;
const setState = store.setState;

const increment2 = () => {
  const { value } = getState().counter2;

  setState({
    type: 'counter2',
    counter2: {
      value: value + 1, 
    },
  });
};

increment2();

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

Даже если вы это исправите, вы видимо не понимаете, что такое redux и принцип его работы. Что вам дает и гарантирует его использование. И зачем нужны и как работают редьюсеры, от которых вы с легкой руки отказались.
Вы со своей шарманкой даже store не сможете обновить по-человечески.
Вы просто ломаете всю концепцию redux, не задаваясь вопросом, а зачем я это делаю?
Зачем использовать эту шляпу, если в в функции действия попадает столько деталей реализации, что при правке или масштабировании придется переписывать все обращения к стору.
Про ReduxDevTools вы видимо не слышали, про сайд эффекты и middleware тоже. То есть серьезный код видимо не писали.
Попробуйте написать CRUD на этой шарманке и конкретно огребете.
Вы, видимо, совсем не понимаете, что такое redux и почему столько людей бьется над тем как с минимальным бойлерплейтом сделать использование лаконичным и при этом максимально гибким, просто взяли и "решили" проблему в 80 строчек кода, за вечер, поломав всю концепцию к е@#ням.

Попробуйте сами себе ответить на вопросы:
1.Зачем тут вообще redux? Вы ломаете всю его концепцию, он не работает как должен. Или вы просто не способны написать что-то более и используете часть готового решения? Неправильно используете, надо сказать.
2. Зачем тут типы действий? Пердолиться в консольку, как вы советуете в README.md? Какую выгоду выполучаете от их использования? Вы видимо даже не задумывались об этом.
3. Как правильно получить текущее состояние? Если с редьюсерами оно идет по цепочке и каждый редьюсер получает только ту часть которой управляет, то тут можно хорошенько огрести в сложном приложении.

Само слово Redux - несет в себе части слов reducer и flux, которые отражают идеологию этой библиотеки. В архитектурном решении которое предоставляет ваш велосипед нет ни первого, ни второго. Почему ваш велосипед называется reudx-light хз. Видимо потому, что redux в зависимостях, а свое хранилище написать вы бессильны и неправильно используете чужое.

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

Как правильно унаследовать компоненты чтобы не дублировать код?

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