Никита Гущин

Из документации ( https://github.com/diegoddox/react-redux-toastr#to... ):

const toastrOptions = {
  timeOut: 3000, // by setting to 0 it will prevent the auto close
  // ...
}

Ставим таймаут в 0 и она не будет исчезать

Начнем с того, что redux - самостоятельное решение, которое можно использовать отдельно от стека react'а. По сему - API разрабатывается для общих нужд. В случае с connect - да, там используется subscribe.

Если вы разрабатывается на rxjs - можно сделать observable из вашего стора (хотя сейчас для этого есть более удобный способ). Также очень полезно подписаться если вы разрабатываете инфраструктурные модули. Вот в голову пришла идея - у вас есть localStoe - вам нужно синхронизировать какой-то кусочек state, чтобы понять, что state изменился - подписываетесь на store.

Для начала: не совсем понятно, что вы хотите инкрементить. В добавок вы мутируете объект action... Лучше сделать как-нибудь так:

export default function reducer(state=initialState, action) {
    switch (action.type) {
        case 'INCRE_TEST':
            return state.int + action.int
        default:
            return state
    }

}

И тут самое непонятное, как все это правильно собирать?
Не понимаю как подключить функцию к onClick

У вас все верно сделано, за исключением параметра функции

const mapDispatchToProps = dispatch => {
    return {
        onClick: int => {
            dispatch(increTest(int))
        }
    }
}

Получается, что в качестве параметра int у вас будет event. Можно просто передавать какое-то число:

const mapDispatchToProps = dispatch => {
    return {
        onClick: () => {
            dispatch(increTest(1))
        }
    }
}

А если хотите сделать именно с параметром, то передавайте его в обработчике клика:

<button onClick={() => this.props.onClick(1)}>Click onClick</button>

Это самый наглядный вариант, только негативно влияет на производительность, поэтому в реальных проектах не стоит так делать (нужно создать в классе Test отдельный метод, скажем, handleClick, в котором вызывать this.props.onClick(1) и уже его передавать в onClick кнопки)

Да, оперируйте id. Сохраняйте его в action и дальше фильтруйте

function removeSomething(id) {
  return { type: 'RemoveSomething_Action', payload: { id } }
}

function reducer(state = initialState, action) {
  switch(action.type) {
    //...
    case 'RemoveSomething_Action':
      return state.filter(el => el.id !== action.payload.id)
    // ...
  }
}

У вас так и сделано :)

Самое простое - сгенерировать 500-1000-whatever задач и посмотреть что будет с вашей системой.
Если говорить в общем - я думаю, что это плохое решение в большинстве случаев. Тем более, если предполагаются большие объемы данных...

• чем больше объектов, тем больше overhead на map\filter\objectAssign и операции со стейтом mapState\reselect.
  
• банальный расход памяти браузера (а если с телефона?)
  
• большое время загрузки и парсинга вашего json.
  

А если уж большинство этих данных пользователь и вовсе не увидит - то зачем? На моей памяти такая модель применялась в интернет магазине, где было не много товаров, но это позволяло пользователям пользоваться ресурсом в offline режиме.

PS
Проведите тестирование (имитацию худшего сценария) и по результатам вам уже будет видно подходит это решение или нет

Ниже пример решения, но насколько оно иммутабельно?

Это идеально: filter создает новый массив.

может быть только одна чистая функция, которая возвращается по умолчанию, или можно плодить там (естественно самое необходимое) функции

Можно использовать хелперы (тот же lodash\ramda). Главное, чтобы в результате у вас редьюсер был чистой функцией без сайд эффектов (это значит, что все функции, которые используете внутри - также должны быть чистыми).

Гляньте вот этот ответ React-Redux. Какой путь правильнее: вызов connect ...

Если кратко:

• Избавьтесь от коннектов, которые слушают большие куски стейта
  
• Используйте reselect, для вычислений стейта (например, когда собираете элемент из разных редьюсеров)
  
• Используйте connect элементах, которым нужны данные. Их может быть много. Список из 1000 connected-elements работает быстрее, чем список из 1000 элементов с 1м connected-element. Потому что даже PureComponent имеет свой оверхед и если дочерний компонент не обновился - это не значит, что diff алгоритм реакта не будет обрабатывать изменения в родительском компоненте
  

Приложение вы оборачиваете в провайдер: он должен быть только один. Далее - вызываете коннект там, где нужны данные. При этом старайтесь избегать больших "коннектов" которые мапят кучу стейта и экшенов - т.к. это ведет к невероятному количеству ненужных ререндеров и перерасчетов state...

Как пример - список с большим количеством элементов. Самая первая идея - сделать коннект к компоненту списка и передать ему items из state:

const Item = props => (
  <li>{props.data.title}</li>
)

const List = props => (
  <ul>{props.items.map(item => <Item data={item} />}</ul>
)

const ConnectedList = connect(
  state => ({ items: state.someItems })
)(List)

Но что произойдет, если один айтем из store изменится? Правильно - ререндер всего списка. Даже если вы сделаете Item как PureComponent - все равно получится огромный оверхед.

Второй вариант: коннектить список, но передавать туда только массив id элементов Плюс - коннектить каждый элемент, и получать данные из стора по переданному id. При этом хранить в сторе мы будем отдельно все айтемы (в виде хэшмапа itemId -> item) и отдельно массив с id, либо просто используйте reselect, который поможет вам сделать преобразование items => itemsIds избежав ререндеров (в примере я упущу этот момент, для краткости).

const Item = props => (
  <li>{props.data.title}</li>
)

const ConnectedItem = connect(
  (state, props) => ({ data: state.someItems.entities[props.id] })
)(Item)

const List = props => (
  <ul>{props.items.map(id => <ConnectedItem id={id} />}</ul>
)

const ConnectedList = connect(
  state => ({ items: state.someItems.ids })
)(List)

Другими словами - даже 1000 подконекченных к стору компонентов лучше, чем 1 большой коннект (не скажу, что в 100% случаев, но все же).
Подробнее про этот момент почитать можно тут somebody32.github.io/high-performance-redux

PS
И в целом, я заметил, что вы активно изучаете react - поэтому, рекомендую вот этот цикл статей Practical Redux. Там очень много годной информации по react+redux

Можно сделать так:

class MyComponent extends PureComponent {
  clickHandler = () => {
     // Так как это стрелочная функция - она будет забиндена при создании элемента (объекта)
  }

  render() {
    return (
      <SearchCollection onClick={this.clickHandler}/>
    )
  }
}

Или так:

class MyComponent extends PureComponent {

  constructor(props, context) {
    super(props, context)
    this.clickHandler = this.clickHandler.bind(this)
  }

  clickHandler() {
  }

  render() {
    return (
      <SearchCollection onClick={this.clickHandler}/>
    )
  }
}

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

Это не верно. Цепочка не ждет друг друга - поток не блокируется, так же как и node. Когда приходит ответ сервера - вызывается соответствующий callback. Но во время ожидания - ваш код работает (например - вы захотели отрендерить анимацию загрузки).

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

Потому что роуты не подходят. У вас :

<Router>
    <App>
      <Route exact path="/" component={Home}/>
      <Route path="/item0" component={Item0}/>
      <Route path="/item1" component={Item1}/>
    </App>  
  </Router>,

А на GH pages у вас роут /joonline/ . К счастью - есть простое решение - указать basepath (документация) относительно которой будут строиться все роуты приложения:

<Router  basename="/joonline"/>
    <App>
      <Route exact path="/" component={Home}/>
      <Route path="/item0" component={Item0}/>
      <Route path="/item1" component={Item1}/>
    </App>  
  </Router>,

Если у вас роутер не 4й версии, то можно попробовать добавить к роутам свойство wrapperClass

<Route path="/" component={App}>
  <Route path="list" component={ListComponent} wrapperClass="wrapper--list" />
</Route>

Идеологически, конечно, не очень хорошо мешать стили и конфигурацию роутов. Но зато: в своем компоненте App вы можете достать эти значения безо всяких редьюсеров\диспатчей:

render() {
  // routes - это массив роутов для текущей локации
  // если взять за основу конфигурацию роутов, которую я привел выше,
  // то при переходе по пути /list в массиве будет два элемента.
  const { children, routes } = this.props
  const wrapperClass = (_.findLast(routes, route => !!route.wrapperClass) || {}).wrapperClass
  
  return (
    <div className={wrapperClass}>
      {children}
    </div>
  )
}

let newState = Object.assign(state, {messages:action._data, loading:false});

В вашем случае вы мутируете объект state. А реакт (и экосистема) построена в функциональных парадигамах, одна из которых - иммутабельность. Т.е. мы берем предыдущий state, новый state и просто сравниваем их по ссылке:

newState === state // true в вашем случае

В вашем случае - state мутировал, но это все еще одна и та же ссылка и реакт\редакс думает, что никаких изменений не было. Как правильно вам уже подсказал Aves