Антон Спирин

render() {
  const { someStateKey } = this.props;  

  if (!someStateKey) return null;

  return (
    {/* component JSX code */}
  );
}

Есть два хороших подхода к организации кодовой базы, которые подходят для большинства проектов: File Type First и Feature First:

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

Дата мапперы в зависимости от задач можно использовать в редьюсерах, в mapStateToProps и asyncActions. Главное чтобы по проекту все было стандартизировано.
В mapStateToProps пишут преобразования необходимые лишь для одного компонента.

Большое количество бойлерплейта это плата которую вы платите за использование redux. Можно писать все константы и редьюсеры руками, можно использовать библиотеки вроде redux-actions и ей подобные. В первом случае вы получаете плюс к гибкости, читаемости и статическому анализу, во втором меньше кода. Я в большинстве проектов предпочитаю первый вариант. Так же создаю шаблоны файлов в Webstorm для asyncActions, contstraints, редьюсера, страницы, компонента и законнекченого компонента.
В специфичных проектах с множеством CRUD запросов и похожих сущностей есть смысл написать CRUD Boilerpalte.

Тыц

Например так:

import React from 'react';
import { render } from 'react-dom';
import configureStore from './store';

const store = configureStore();

store.dispatch(init());

render(
  <Provider store={store}>
    <Router>
      <App />
    </Router>
  </Provider>,
  document.getElementById('root')
);

Речь идет о next.js и next-redux-wrapper? Используйте componentDidMount:

componentDidMount() {
  this.props.store.dispatch(someAction());
}

Скорей всего ошибка в редьюсере. Передаете в spread оператор null или undefined.
{ ...someValue }

Если имеется ввиду вызов вне компонентов React или async aciton, то так:
В вашей точке входа:

export const store = configureStore();

// some code

В целевом файле:

import { store } from './index';
import { someAction } from './actions/some';

store.dispatch(someAction());

Но это не очень хорошая практика. Правильней написать asyncAction и вызывать его.

const initialState = {
  type_transport_id: null,
  brand_id: null,
  automodel_id: null,
  year: null,
  body_id: null,
};

export default function model(state = initialState, action) {
  const { type, payload } = action;

  switch(type) {
    case SET_TYPE:
      return {
        ...initialState,
        type_transport_id: payload,
      };
 
    case SET_BRAND:
      return {
        ...state,
        brand_id: payload,
        automodel_id: null,
        year: null,
        body_id: null,
      };

    default:
      return state;
  }
}

Либо кейс SET_BRAND можно еще так представить:

case SET_BRAND:
  return {
    ...initialState,
    type_transport_id: state.type_transport_id,
    brand_id: payload,
};

Вы путаете с ducks pattern.
Это не технология, а лишь подход к организации кодовой базы проекта.

В подавляющем большинстве случаев, нет абсолютно никакого смысла хранить состояние форм в store.

Ответы:
1. Использую либо контролируемые компоненты, либо refs. Состояние форм, в случае с контролируемыми компонентами, хранится в state родительского компонента.
2. Все зависит от проекта и требований. Где-то достаточно пары проверок в onSubmit, а где-то форма может генерироваться по данным, полученным с сервера и валидироваться по полученным правилам.

Видео туториалы от Дэна Абрамова.
Курс от Максим.
React/Redux Links

Для решения вашей задачи, по-хорошему, не нужен redux. Если вы целенаправленно хотите реализовать с использованием redux, то перепишите пример по ссылке строчка за строчкой и попробуйте разобрать. Не получится - изучайте документацию, вы ведь вроде изучать начали. Если есть конкретные вопросы помимо "ничего не понимаю", задавайте.

1. React + koa/express + mongoDB
2. React + firebase
3. Gatsbyjs
4. Create React App
5. Next.js
6. Razzle
7. Rekit
etc

Подключаем redux-thunk. Пишем async action:

function fetchSomeData(params) {
  return async (dispatch, getState) {
    try {
      const { data } = await Api.fetchSomeData(params);
      dispatch(fetchSomeDataSuccess(data));
      // для доступа к store можно использовать getState
      return data;
    } catch (e) {
      dispatch(fetchSomeDataFail(e));
      return e;
    }
  }
}

Подключаем к компоненту:

const mapStateToProps = state => ({ ... });
const mapDispatchToProps = {
  fetchSomeData,
};

export default connect(mapStateToProps, mapDispatchToProps)(SomeComponent);

И из-за этого не работает роутинг.

withRouter(connect(...)(MainLayout));

И зачем нужно писать экшен, если можно напрямую диспатч вызвать без посредников?

Что именно не понятно? Зачем писать функцию? Или почему бы не импортировать store в каждый компонент вручную?
Первое, don't repeat yourself. Второе, сейчас компоненты вообще ничего не знают о store и о месте его хранения, в противном случае будут. Но вам никто не мешает делать как вам удобней.
Исбыточную конструкцию:

dispatch => ({
  onSetScale: (event) => {
    dispatch(setScale(event);
  }
})

Можно сократить до:

{
  onSetScale: setScale,
}

Я не передаю actions через connect, а вызываю так:

componentDidMount() {
  this.props.dispatch(action());
}

Плюс такого решения в том, что можно быстро перейти к месту объявления action. В больших проектах это экономит кучу времени.

reducers/index.js третья строчка. Посмотрите какой экспорт в файле и какой вы делаете импорт.

Почему неправильно-то? Главное чтобы при изменении порядка элементов, состояние обновлялось иммутабельно.
А задавать полученное состояние если используете в проекте React версии ниже 16.3 можно примерно так:

const computeDerivedState = props => ({
  someData: props.someData,
});

class Example extends Component {
  state = {
    ...computeDerivedState(this.props),
    someState,
  };
  
  componentWillReceiveProps(nextProps) {
    if (nextProps.someData !== this.props.someData) {
      this.setState(computeDerivedState(nextProps));
    }
  }
}

Если используете в проекте React ˆ16.3, то вместо componentWillReceiveProps и computeDerivedState используйте getDerivedStateFromProps и прочитайте эту статью.

const result = array.reduce((acc, el) => {
  const key = 'Type' + el.type;
  acc[key] = acc[key] ? [...acc[key], el] : [el];

  return acc;
}, {});

И легально ли этим заниматься в редьюсере ? Может быть middleware лучше подойдет для этого?

Легально. Главное придерживаться одного стиля в организации кода, чтобы не было так, что в одном месте данные преобразуются в редьюсере, в другом в middleware.
Помимо этого, под частные потребности компонента данные можно преобразовывать в селекторах, передаваемых в mapStateToProps.

Решение: вешать ref на input поле

Хорошее решение.

ref делать для каждого поля уникальным.

Нет смысла. Используйте один ref в компоненте TextField, в каждом созданном экземпляре компонента он будет уникальным.