semki096

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

Точнее, так и стоит делать, когда тебе на самом деле нужна только часть функционала от либы.

Если нет API, то делаете форк. Устанавливаете в проект свой форк. И пользуетесь. Ваша копия развивается не зависимо, npm будет подтягивать все ваши обновления.
А потом можно будет смержить изменения из оригинальной библиотеке в вашу

А почему должны быть проблемы? Plesk это просто удобный интерфейс к тем-же самым функциям.

setState асинхронный метод, используйте колбек что бы после того как состояние изменится иметь актуальные данные

this.setState({
      messages : responce.data
    }, () =>  console.log(this.state.messages));
  ;

this.setState({
  data: [
    ...data.slice(0, data.length - 1),
    { ...data[data.length - 1], year: "2141" }
  ]
});

или гибче

this.setState({
  data: data.map((item, index, source) =>
    index !== source.length - 1 ? item : { ...item, year: "2141" }
  )
});

или справа

this.setState({
  data: data.reduceRight(
    (acc, item, index) => [
      ...acc,
      index !== 0 ? item : { ...item, year: "2141" }
    ],
    []
  )
});

а можно слева

this.setState({
  data: data.reduce(
    (acc, item, index, { length }) => [
      ...acc,
      index !== length - 1 ? item : { ...item, year: "2141" }
    ],
    []
  )
});

а можно пофантазировать

this.setState({
  data: Array.from(
    { length: data.length },
    (n => () => (
      n++, n !== data.length - 1 ? data[n] : { ...data[n], year: "2141" }
    ))(-1)
  )
});

Вентилятор подыхает, пора заменить.

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

Баз подойдет много. Mongo подходит. PostgreSQL тоже подходит с их новым типом JSONB и текстовым индексом. На одном из семинаром главный Постгресщик Бартунов хвастался что на тестах производительности этот тип данных обгоняет Mongo. Хотя ХЗ как это проверить на кастомных проектах.

Берите одно из двух исходя из стоимости владения.

Типа такого:

class WS extends React.Component {
  constructor(props) {
    super(props);
    this.state = { messages: [] };
    this.ws = new WebSocket("ws://api...");
  }

  componentDidMount() {
    this.ws.onmessage = responce => this.setState({ ...this.state, messages: [ ...this.state.messages, responce.data ] });
  }

  componentWillUnmount() {
    this.ws.close();
  }
}

или на хуках

import React, { useEffect, useState } from 'react';

function ws() {
  const [message, setMessages] = useState([]);

  useEffect(() => {
    const ws = new WebSocket("ws://api...");
    ws.onmessage = responce => this.setState({ ...this.state, messages: [ ...this.state.messages, responce.data ] });
    return () => ws.close();
  }, []);
}

Как можно заметить, на хуках логика не размазана по всему компоненту, а находится в одном месте.

А еще лучше обернуть все это в React Context и подписываться на него в нужных компонентах через useContext (или Consumers). Тогда и очередь сообщений модно копить со всеми нужными мета-данными (например, временем получения).

при чем тут json? подойдет любая база которая умеет хранить строки, если одна база не будет успевать то нужна распределенная, балансирующий узел, кластеры, вот это все
и если надо быстро складывать то это скорее что-то из NoSQL

для json лучше всего подходит Mongo.
Но я бы подумал над тем что за данные у вас - если вы просто добавляете и добавляете +- одинаковые записи и по ним потом надо поиск например делать - то лучше подойдет elasticsearch. А если вы что-то еще делаете - то лучше подойдет что-то другое.
Главное не формат данных для хранения а операции над ними. Хранить то и в текстовом файле можно.

MongoDB. JSON-подобные документы это формат в котором она хранит свои данные.

Формат данных в MongoDB
Одним из популярных стандартов обмена данными и их хранения является JSON (JavaScript Object Notation). JSON эффективно описывает сложные по структуре данные. Способ хранения данных в MongoDB в этом плане похож на JSON, хотя формально JSON не используется. Для хранения в MongoDB применяется формат, который называется BSON (БиСон) или сокращение от binary JSON.
BSON позволяет работать с данными быстрее: быстрее выполняется поиск и обработка.....

JSON - это формат структуры для обмена данными.
А база - это хранилище данных структуры.
Поэтому, любая подойдёт.

Свойство экземпляра класса, видимо.

...
   constructor(props) {
      ...
      this.speed = 1000;
      ...
    }
...

setInterval(this.func, this.speed)
Судя по вашему коду, speed — интерфал между выполнением func

Ход конём: эмулируйте базу через API веб-сокет-сервера для своих клиентов.
Никаких задержек и полная свобода действий.

Веб-сокет - любой.
Ларавел - здесь лишний.

PS: запомните, что "круто" - это не наличие названия Laravel(или любого другого) в вашем проекте, а грамотная архитектура и выбор оптимальных инструментов для её реализации в рамках поставленной задачи.

На стороне сервера можно делать что угодно. Можно самостоятельно все сделать, можно использовать что-то типа https://socket.io/

На клиенте нужно подписаться на обновления сокета, например через useEffect связав с данными в useState.
Еще можно обернуть подключение в провайдер React Context.

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

Вариант первый.
Контроллер на php вызывается не посредственно со страницы на которой находится компонент ajax запросом. Тогда данные для этого компонента можно передать в ответе, а в компонент они попадут например через Redux или если запрос отправляется из самого компонента в который должны попасть данные то в ответе они уже будут в Вашем компоненте.

Вариант вотрой.

На странице вообще не известно когда дёргается контроллер, и Вам нужно сделать свзять не клиент - сервер, а сервер клиент. Тогда Вам нужно смотреть в сторону сокетов и их реализации либо на php либо что более вероятно через прослойку на node.js