Сергей Сунцев

Вполне можете использовать, но не забывайте, что slice, что spread operator они делают копию только плоского объекта(массива).

const arr = [0, 1, [2,3]]
const newArr = arr. slice(0)
newArr[2][0] = 'new data'
console.log(arr[2][0]) // new data

Если вам нужно избегать мутации для глубокого объекта, то используется либо JSON.stringify, JSON.parse, либо сloneDeep из lodash. Или сами можете написать функцию обхода объекта.
Есть еще специализированные библиотеки immutable(deprecated) или immerjs.

Забыл обернуть компонент в connect из redux

Не увидел в вашей реализации redux.

Вам нужно в store добавить два поля: список клиентов и активного клиента.
Пока у вас активный клиент равен null, то показываем список клиентов.
При клике на клиента добавляем в поле "активный клиент" объект из списка всех клиентов и отображаем по нему информацию.

Соответственно поля список клиентов и активный клиент держим в селекторах, для этого используем Reselect

Лучше всего запросы делаются в мидлварах.
Можете сами написать функцию автоматического получения данных, а можете воспользоваться либами
redux-api-middleware
Либо
redux-api-call

Также вполне можно, особенно, если у вас бэк распределенн по разным местам, использовать redux-thunk, или redux-saga
Вот статья, где есть примеры подключения

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

Оба подхода вполне рабочие.
Но если вы не знакомы ещё ни с одним, то я бы настойчиво советовал вам Redux
Покуда он более популярный, его проще отлаживать и работу с ним в разных компаниях найти гораздо проще.

Но если вам очень нравятся декораторы, то mobx welcome

Описаный тобой путь вполне приемлим.

Могу ещё посоветовать:
1) Выносить всю логику запросов в саги, тогда все экшн криэйтеры будут являться чистыми функциями, что очень удобно.
2) Выносить подключения в мидлвары, что явно сокращает количество бойлерплейта и стандартизирует обращения с апи.

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

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

Тут у тебя будет приложение из 2х частей: серверная и клиентская.
1) Для вставки на сайт не обязательно юзать ифрейм, ведь можно скриптом добавить бандл сборки куда нибудь в body сайта и реализовать небольшой фиксированной всплывашкой.

2) При заходе на страницу пользователь автоатом шлет запрос на коннект. В нем происходит :
* Соединение к сокет серверу.
* Добавление пользователя в комнату.
Как я понимаю, раз вставляьться сайт будет много - куда, а сервер у нас один то надо как то привязывать конкретного пользователя к комнате, либо сохранять в урле уникальный идентификатор комнаты, где бы пользователь смог продолжить общение с тех. поддержкой. Либо запрашивать какие то данные, типа почты. Либо условится, что при выходе со страницы пользователь теряет прогресс общения.

Хороший вопрос, но что касается модели данных, то некоторые паттерны в этом плане за нас уже придумали и они довольно не плохие. к примеру redux-ducks, их можно разбивать, как в примере выше, а можно и группировывать в одном файле. Собственно саги они в самом конце располагаться должны, вот мой пример организации компонента с сагами

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

Нашел ответ.

Нужно определить payload и отправлять значение параметром в sagaGetUsers.next()
к примеру

describe('users sagas', () => {
  
  test('look on a default offset users at list', () => {
    const sagaGetUsers = getQueryUserSaga()
    const payload = 'default_filter=none'
    expect(sagaGetUsers.next(payload).value).toEqual(take(GET_QUERY_USERS_REQUEST))
    expect(sagaGetUsers.next().value).toEqual(select(filtersSelector))  
  })
})