Можно ли получить данные от Api не дожидаясь полной загрузки?

Question

[Mdmitr]

Запрос к сети должен быть один.

Данные должны отображаться по мере загрузки.

fetch('https://jsonplaceholder.typicode.com/todos')
   .then(response => response.json())
   .then(json => console.log(json))

Один fetch запрос и получение данных частями, чтобы не ждать загрузки всего json.

Это вообще можно сделать?

Answer 1

[Алексей Ярков]

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

Comments

[Mdmitr]

Немного не то, есть большой json который может загружаться ооочень долго, к бэкенду доступа нет и не будет. Есть ли возможность загрузить этот json частями
Вот пока загружается json показать загруженные данные

а пагинация будет на фронте

[Алексей Ярков]

Mdmitr, если к бэкенду нет доступа, то никак. Пока ответ от сервера не получен - данные не нарисуешь.
Во всяком случае я не знаю способа.

[Роман]

Алексей Ярков, Mdmitr, почему никак, очень даже как)))
делаете свой промежуточный сервер, который получая запросы от клиента, на низком уровне (уровень соединения tcp/ip) перенаправляет запрос на нужный сервер, читая его ответ из сокета частями по мере загрузки. Для этого вам понадобится реализовать поверх голого tcp/ip соединения поддержку протокола http/https со всеми хеадерами и прочим, а так же хитрый парсер для получаемых данных, способный выковыривать самодостаточные куски json-а по некоторому признаку.
НО!!! хоть это теоретически и возможно, такое решение будет дичайшим костылем (ктото возможно назовет его микросервисом ))))))

[Алексей Ярков]

Роман, ну как вариант можно ))
Я что-то и не додумался сразу.

[Mdmitr]

Роман, ну я думал можно как-то увеличить скорость загрузки json, но websocket слишком круто

[Вадим]

Без доступа к бэку - нет. Вы же кидаете запрос и браузер отдаёт вам ответ только когда бэк полностью скомпанует ответ и вернёт его в ваш браузер по сети.
Если бэк не отдаёт вам часть, то и взять её вам неоткуда.

[Алексей Ярков]

Mdmitr, про websocket это вы придумали уже ))

[Роман]

Алексей Ярков, сижу уже неделю жду ответа от возможного работодателя

чат

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

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

Я: Виктория, доброе утро.
Неделя прошла, напоминаю о себе)

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

[Mdmitr]

Алексей Ярков, ну ладно, отмечу решением

[GrayHorse]

Это делается с импользованием ReadableStream. Ответил ниже.

В случае с JSON'ом автору придется писать свой SAX-парсер, т.к.JSON.parse это DOM-парсер (работает лишь с полным JSON файлом).

Answer 2

[Vitsliputsli]

Можно, у XMLHttpRequest есть состояние readyState, при его смене генерируется событие readystatechange. Состояние Loading устанавливается несколько раз, а именно, каждый раз, когда получен очередной пакет, соответственно вы можете оперировать с буфером получаемых данных до его полной загрузки.

Answer 3

[GrayHorse]

В отличие от XMLHttpRequest Fetch API поддерживает полноценный стриминг.

Берешь из респонса ридер response.getReader() и считываешь данные вручную по частям по мере поступления. JSON файл, естетственно, парсить придется тоже вручную, т.к. JSON.parse не будет работать с невалидным JSON, чем недокаченный файл и будет являться.

Делается по аналогии с этим: https://learn.javascript.ru/fetch-progress

---

С XMLHttpRequest можно сделать недостриминг при использовании responseType: "text" (по-умолчанию). В таком случае при каждом вызове onprogress или onreadystatechange можно читать обновленный (с добавленными данными) xhr.responseText.

Comments

[Vitsliputsli]

Можете пояснить в чем разница между ними (кроме того что fetch более современное решение)? И что значит полноценный стриминг и недостриминг в данном случае?

[GrayHorse]

XMLHttpRequest хранит данные до самого конца загрузки в ридонли переменной.
Пример: XMLHttpRequest получил блок данных [1], и передал в его колбеки. Получил блок данных [2], передал в колбеки и [1], и [2]. Получил [3], передал [1][2][3].

При считывание же данных из ReadableStream они из него исчезают. Т.е. он хранит данные лишь до момента, когда их считают. Получил [1], отдал [1]. Получил [2], отдал [2]. Получил [3][4], отдал [3][4] (если ты считываешь/обрабатываешь данные медленнее, чем они скачиваются).

Если, например, нужно скачать файл и посчитать его хеш, то при использовании fetch дополнительная память не потребуется вообще: как только получил часть файла – передал ее хеш-функции, а после ее собрал сборщик мусора. При использовании XMLHttpRequest весь файл будет висеть в памяти до конца загрузки, даже если он не нужен.

В случае, если считанные данные надо преобразовать и хранить в памяти, то опять-таки таки из-за того, что XMLHttpRequest хранит в себе скачанные данные, которые уже считаны и обработаны, потребление памяти будет в два раза больше, чем при использовании fetch.

[Vitsliputsli]

Спасибо, интересный момент.