Alexandroppolus

Варианты:
1) выкинуть на мороз первый useEffect. При смене activeTab (это ведь происходит по клику на каком-то элементе?) заодно делать setPage(1).
2) дублировать в useRef текущие значения стейта, обновлять во втором эффекте, и не вызывать загрузку при определенной комбинации. Немного костыльный вариант, советую всё таки первый.

useEffect(() => {

    socket.current = new WebSocket(`ws://localhost:8000/message`)

    socket.current.onopen = () => {
      console.log('connected')
    };
    
    socket.current.onmessage = (event) => {
      const message = JSON.parse(event.data);
      setMessages((messages) => [...messages, message]);
    };

    socket.current.onclose = () => {
      console.log('socket was closed')
    };

    socket.current.onerror = () => {
      console.log('socket get some error')
    };

    return () => {
        socket.current.close();
    };
  }, [])

Рискну предположить, что Table - это и есть Component1.

Ты передаешь в Component1 проп children, но в самом компоненте этот проп, к сожалению, не используется.

надобно:

function Component1({children}) {
  return (
<StyledComponent1>
      <p>Wrapper</p>
      {children}
</StyledComponent1>
  );
}

куда именно воткнуть children внутри Component1 - это уж сам решай, но куда-то придётся.

в Component2 и Component3 тоже следует сделать так. Ну и читать доку, пока голова не отвалится.

Похоже, у тебя на всё про всё только один useState для modalActive, и при клике по кнопке Info все модалки всплывают на свет божий.

храни в стейте name (или id) выбранного персонажа
для модалки устанавливай проп active={item.name === activeName}

reply.replies = [newReply,...reply.replies]
setReplies(rootReplies=>[...rootReplies])

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

есть 3 варианта:
1) Продолжать использовать дерево в useState. Но менять его надо иммутабельно. То есть если у какого-то узла что-то поменялось, то надо заменить узел и все его паренты, а не только корневой массив.
2) Нормализовать данные в плоскую структуру. Каждому реплаю присваивается уникальный id, все реплаи складываются в объект, где ключем будет id. В массиве replies у каждого объекта будут лежать не сами объекты, а только id, и потом надо будет их соединять во время рендера. Этот вариант канонично используется для redux, но как зайдет для useState, навскидку не совсем понятно.
3) Использовать MobX с этими его observable.deep (или просто observable). Как всегда, самый простой и удобный вариант.

Рекурсивная наблюдаемость объектов (выставляемая по умолчанию в makeAutoObservable и успешно примененная в bStore) не залетает в пользовательские классы. Считается, что класс (в твоем случае AStore) должен сам настроить внутри себя наблюдение.

об этом написано в документации https://mobx.js.org/observable-state.html
ctrl+F "primitives and class instances are never converted to observables"

У тебя там бесконечная рекурсия, если IsMultiVoices истинно

const cash = CashTypeSelector(state => state.cash)

Судя по ошибке, в cash попадает не число, а объект {cash: number}

Что такое CashTypeSelector? Что лежит в Редуксе?

как исправить

const cash = CashTypeSelector(state => state.cash.cash);

в компоненте Feed нет return. Зря ты с ним так..

Тут нет проблемы, это Реакт так работает. На первом рендере у тебя пустой массив, потом придет ответ на запрос, поставит массив, и компонент перерендерится.

Как вариант, можно получать track где-то снаружи, передавать в Home в пропсах и рендерить Home, если треки загружены (если массив не пустой)

Зависит от надобностей. Если требуется оперативно (синхронно) обрабатывать текущее значение, то вариант 1, только тем ещё нужно передавать value. Это "управляемый компонент" - по сути, ты просто выносишь стейт из инпута наружу. Бонус: можно как-то форматировать текст на лету, либо просто вручную взять и поменять. Вариант 1 считается каноничным, потому что вынос стейта наверх - одна из базовых концепций Реакта.

Вариант 2 - изменения в одну сторону - от инпута. То есть теряется возможность управлять инпутом снаружи.

В варианте 3 обычно используют ref (забудь про id, это антиреакт). Подходит, когда тебе пофиг, что там пишется в инпуте, и надо забрать его значение (и как-то обработать) только, например, по нажатию на кнопку. Тема слегка раскрыта здесь.

Надо отметить, что авторы Реакта пилят новую доку, и можешь почитать там философию про стейт - https://beta.reactjs.org/learn/managing-state

https://codesandbox.io/s/red-haze-ypkug2

что поменялось:
регулярка стала /^\d+$/ , чтобы проверять всю строку целиком
в Input добавил обработку пропсов onBlur, onFocus, value
для второго поля написал кастомный validate, который использует первое

ещё такой момент: при изменении первого поля не происходит перевалидация второго. Второе перепроверится, только если его потрогать.