Kentavr16

используй pageCount = 1, c нулем значений. Также логично вообще не отображать пагинацию если нет элементов для отображения.

Просто оберни все приложение в роутер. Ты не используешь контекст, а навлинк использует.

Путей решений большое количество, и они зависят от твоих хотелок.
Вариант а - с кульбитами, но я бы так сделал. Пишешь небольшой бекенд на экспрессе для своего приложения. На беке с помощью cron например раз в день/час/несколько минут делаешь запрос на нужное апи, записываешь в своей бд ответ. Вопрос с лимитом запросов решен. далее делаем пагинацию на своем сервере (очень простое действие) и отправляешь пользователю человеческий ответ по АПИ, который будет соответствовать всем твоим запросам и нуждам. На фронте остается допилить простое СПА без извращений и сложностей.
Вариант б - сохраняешь ответ на клиенте, обновляешь кеш раз за n-ное время, как предложено выше. В таком случае проще всего действительно использовать локалстор для хранения ответа по АПИ. Если хочется более продвинутой работы, обрати внимание на indexedDB -есть несколько интересных адаптеров для реакта, которые упрощают работу.
Вопрос с сохранением данных при переходе на другую страницу решается просто (я догадываюсь что под другой страницей ты подразумеваешь роутинг в react SPA). Это либо хранение состояния на верхнем уровне приложения, либо стейт менеджер. Внимание - стейт-менеджер только упрощает(!!!) обращение со сложным стейтом в относительно больших приложениях. Это не панацея, по факту он делает то же самое что и обычный хук стейта. Тебе скорее всего не принципиально, но при желании пришить условный zustand можно. Это вкусовщина.
Можно вообще написать кастомный хук для работы с локалстором/индекседДБ и юзать на каждой странице, считывая при заходе на каждую страницу данные и одновременно проверяя их "свежесть". Тогда стейт менеджеры точно не нужны от слова совсем.

Собственно в бд и хранить. На момент написания вопроса не понимал основ БД.

вытяжка из комментария -
Best practice - спрятать токен в httpOnly куке, чтоб js не мог его прочесть и авторизовываться просто через куку в хеадере запроса.
Можно вот тут почитать, к примеру https://habr.com/ru/company/ruvds/blog/512866/ (обратите внимание на комментарии)
В любом случае Вам необходимо завести через реакт контекст (к примеру) стор, доступный в любом месте приложения. Оборачиваете всё приложение в контекст провайдер, на первой странице (или при загрузке приложения) запрашиваете какие-либо данные с бэка (данные пользователя например, если авторизация через куку, либо получаете jwt-токен в ответ на ввод логина) сохраняете в переменную в контексте (isAuth например), а в целевом компоненте навигации используете эту переменную как условие выводить одно или другое. Можно вызывать useEffect(() => {какой-то код},[имя переменной]), который будет дергаться только когда "имя переменной" обновится...

Отвечу сам себе - используя параметры УРЛ, контекст или редакс.

Глупая ошибка - я просто не импортировал функцию которую нужно передавать в диспатч.

попробуй

if(socketRef.current && socketRef.current.readyState === 1 && message)

Много с сокетами в реакте не работал, но мне кажется что это плохой код. Компонент может ререндериться несколько раз, и сокет будет дергать на каждом ререндере. Хотя бы добавить проверку в первом эффекте что реф пустой.

Вопрос решился благодаря наводке Дмитрий и мозговому штурму szQocks. Куки не приходили из-за того, что в запросе на сервер я использовал как адрес IP - 127.0.0.1:8000/login. Браузер распознавал это как нарушение CORS для установки куки (подробнее в комментариях к вопросу). Осложнило решение проблемы то, что запрос распознается как успешный. Консоль браузера пуста, увидеть проблемное место можно только во вклатке "сеть" при выборе соответствующего запроса. В моем случае помогла смена URL запроса на localhost.

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

const widget = document.createElement('div');
      document.body.appendChild(widgetContainer);
           ReactDOM.render(
        <Widget />,
        widget
      );

Можно сделать обертку над реактом, но это уже все технические моменты

Наконец дошло) Так как ты делаешь запрос на локальный адрес, await axios.get("/api/products") , аксиос ищет ресурс относительно корня проекта. У тебя был запущен локальный сервер разработки реакта, и он его поймал каким-то образом. Я сначала сам не понял в чем соль, но установил себе аксиос и сделал локальный запрос, с локальным путем как у тебя. Мне пришел ответ от работающего в данный момент сервера апач, также оформленный как HTML, с той только разницей что там писалось о том что ресурс не найден. Что забавно.

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

Советую просто поиграть со свойством scroll при установленном overflow: hidden. вот тебе пример. (Листание по клику на первый див.)
А динамически вычислять сколько текста влезет на страничку при изменении расширения, размера текста и тд - дело неблагодарное.
Пример написал на чистом js, но в реакте будет еще проще как по мне. Что-то вроде продублировать компонент который рендерит страничку, установив другое значение скролла.

если я правильно понял, то вам нужно ознакомиться с концепцией дочерних роутов. далее пример из оф.документации:

<Routes>
  <Route path="/" element={<Dashboard />}>
    <Route
      path="messages"
      element={<DashboardMessages />}
    />
    <Route path="tasks" element={<DashboardTasks />} />
  </Route>
  <Route path="about" element={<AboutPage />} />
</Routes>

Whenever the location changes, looks through all its child routes to find the best match and renders that branch of the UI.

в помощь следующим ищущим вопросы стоит закрывать, даже если сами нашли ответ. Happy hacking.