Максим

Здесь уже можно улучшить, сделав HOC компонент - PrivateRoute

Про редирект (в экшене вызывается callback) + запрос в компоненте.

p.s. Это все было решено на вебинаре. Пример (решение тестового задания, видео-разбор)

В components/header + вложенность, все как вы описали в вопросе.

Есть разные подходы к организации структуры, мне нравится подход по фичам (посложнее) или тупо деление на контейнеры/компоненты и все (полегче, но свалка, подходит для начала изучения).

так же разные подходы по организации были у людей, выполнивших второе тестовое задание (видео и текст). В комментах у видео есть репозитории, можете ознакомиться.

Пакет flow не нужен, нужен flow-bin (локально как минимум).
По настройкам у меня пустой .flowconfig и настройка в редакторе:
"flow.useNPMPackagedFlow": true,

Добавлю:

const funcName  = () => dispatch => {
  return dispatch({
    type: NAME_TYPE,
    payload: lol
  })
}

Превращается в:

var funcName = function funcName() {
  return function(dispatch) {
    return dispatch({
      type: NAME_TYPE,
      payload: lol
    });
  };
};

(это если было сложно прочитать)

Как уже ответили выше, dispatch становится доступным благодаря middleware redux-thunk. Для чего и зачем? Для того, чтобы мы могли "диспатчнуть" экшен в любой момент времени. Это обычно нужно для выполнения асинхронных запросов.

Пример:

export function getNews() {
  return dispatch => {
    dispatch(newsRequest())

    return httpGet(`news`) // начался асинхронный запрос
      .then(res => {
        if (checkResponse(res)) {
          dispatch(newsSuccess(res.data)) // когда завершился - вызываем dispatch, иначе откуда бы у нас в этой области видимости появилась переменная dispatch?
        } else {
          dispatch(newsFailure(res.message))
        }
      })
      .catch(error => {
        dispatch(newsFailure())
      })
  }
}

Используется старый props, новый еще не пришел в этот момент (render'a нового еще не было).
Вообще, все это можно сделать в одном экшене, нет необходимости писать 2 функции.

Если очень хочется, то перенесите this.searchPosts() в componentWillReceiveProps / getDerivedStateFromProps, но как уже написал выше - лучше все сделать в одном запросе.

Если приложение переписывается на react, то одновременно держать react-native + react базу поможет react-native-web пакет, но там нет FlatList до сих пор, ждут давно.

Для одинаковых компонентов - все просто, один файл. Если же для какого-то компонента требуется различный код, можно делать два файла xxx.web.js и xxx.ios.js (например), и на стадии сборки в сборку включать только те, что подходят под проверку (для веб собираете или для mobile).

Общие компоненты (uikit - кнопки, надписи, стили и тд) - все можно вынести в отдельный пакет / отдельную директорию. Вы пишите, что у вас уже есть - ок, используйте, если они готовы для этого (но я думаю вряд ли, надо как минимум адаптировать/переписать будет)

Судя по доке, должно быть
?HTMLDivElement

history.push

Статья (en)

Кратко: вы можете использовать browserHistory API или hashHistory API, которые позволяют перемещаться между URL-адресами, без перезагрузки страницы. Следовательно, у хистори есть метод пуш, который позволит перейти на новый адрес и сохранит предыдущий, чтобы работала кнопка "назад"