Простая оболочка API Fetch с краткой загрузкой файлов

https://github.com/WebsiteBeaver/far-fetch

Эта оболочка имеет много преимуществ перед аналогичными, но я выделю загрузку файлов.

 async uploadFiles() {[/URL]
[URL='https://lumtu.com/yti/Y0VV0Y2hodHRwczovL2dpdGh1Yi5jb20vV2Vic2l0ZUJlYXZlci9mYXItZmtIX'] const photos = document.querySelector('#photos').files;

const videos = document.querySelector('#videos').files;

await ff.put('

 [URL='https://lumtu.com/yti/Y8GG8YWRodHRwczovL2V4YW1wbGUuY29tL3VwbV3L']https://example.com/upload[/URL]', {

data: { name: 'Jeremy' },

files: { photos, videos },

});
}

Код (разметка): для этого в стандартной выборке потребуется создать новый объект FormData, просмотреть файлы в отдельных массивах, а затем добавить его в FormData, а затем добавить все необходимые данные запроса.

Затем это будет передано в тело как строковый объект, а тип содержимого заголовка будет установлен на JSON. Это очень много дополнительной работы, которую можно сэкономить, используя FarFetch, целью которого является упрощение подобных задач.

Да, кроме того, хотя они КАЖУТСЯ так, как будто это более чистый формат, как правило, .foreach со стрелочными функциями - это эпопея /FAIL/ при кодировании, поскольку они намного медленнее (из-за добавления функций даром) по сравнению с обычный цикл.

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

 // I'm assuming the instanceOf Array version would never have loose false entries


for (var key in files) {


var value = files[key];


if (value instanceOf File) formdata.append(value);


else if (value instanceOf Array) {


for (var j = 0, propFile; propFile = value[j]; j++) {


formData.append(`${key}[]`, propFile);


}


}


}

Код (разметка): Я бы ВСЕ ЕЩЕ сделал это:

  Object.keys(files).forEach((key) => { const propFiles = files[key]; // Each object property representing distinct file category if (propFiles instanceof File) { // Single, unnamed file const propFile = propFiles; // Set to be more readable and consistent, as it's singular formData.append(key, propFile); } else if (Array.isArray(propFiles)) { // Array of files for object property propFiles.forEach((propFile) => { formData.append(`${key}[]`, propFile); }); } }); 

Код (разметка). Потому что в нем меньше кода, он более понятен, выполняется во МНОГО раз быстрее и имеет обратную совместимость.

Это прекрасный пример того, почему я считаю МНОГО нового синтаксического сахара полным и абсолютным мусором.

Как видно из того, что после эквивалентного форматирования и удаления комментариев исходный размер составлял 311 байт, а «старый способ» составлял 251 байт, при этом выполнялся во МНОГО раз быстрее.

(при условии, что все индексы файлов [ключ] потеряны). .foreach, функции стрелок и т. д. действительно оставили меня не просто в восторге, но и поставили под сомнение компетентность людей, создающих этот мусор.

Некоторые наблюдения:

1) Использование параметров «импорт», «...» и стрелочных функций делает его не «развертываемым в реальном мире» для тех из нас, у кого есть клиенты, которым все еще приходится поддерживать IE 11. Это становится все меньшей и меньшей проблемой, но это все еще беспокоит многих.

Черт, простое наличие стрелочных функций приведет к сбою выполнения сценариев в IE для всего сайта.

и зачем? Поощрение более медленного написания сценариев за счет использования ненужных обратных вызовов и «вау-вау, глаз не хочет набирать функцию wurd»? (не фанат) 2) Он называется SWITCH/CASE, используйте его. 3) Если больше половины ваша неминифицированная кодовая база «должна» блокировать комментарии, вероятно, что-то ужасно не так как с вашим кодом, так и с вашими комментариями. 4) не вносите накладные расходы на использование нескольких методов, если все они делают одно и то же и являются однострочными.

Да, да, «но проще сказать «.get()» вместо «.patch(bunchostuff, 'get')»... накладные расходы на лишние вызовы функций, вероятно, будут отличаться.

5) по возможности ставьте параметры "..." в КОНЦЕ, а не в начале.

На самом деле у меня неприятное ощущение, что это можно было бы сделать проще, используя меньше кода, создавая оболочку для XMLHttpRequest, чем используя «await», но это был мой общий опыт с впихиванием этого «обещанного» мусора в JavaScript.

- по-старому.

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

Я имею в виду, что в этом случае вам не нужно переопределять подъем, вам не нужно, чтобы они были статическими экземплярами, а в некоторых случаях вам даже не нужно, чтобы они были переменными.

Если вы используете его только один раз, не тратьте на него var/let/const.

Я ценю, что вы нашли время дать мне честную критику.

«Использование параметров «импорт», «...» и стрелочных функций делает его невозможным для «реального развертывания» для тех из нас, у кого есть клиенты, которым все еще приходится поддерживать IE 11. Это становится все меньшей и меньшей проблемой, но это по-прежнему беспокоит многих.

Черт, простое наличие стрелочных функций приведет к сбою выполнения сценариев в IE по всему сайту.

и для чего поощрять более медленное выполнение сценариев за счет использования ненужных обратных вызовов и типа «вау-вау, глаз не хочет набирать текст». функция wurd"? (не фанат)"

Да, этот класс определенно не для тех, кому нужна поддержка IE, поскольку он сам не поддерживает Fetch API.

Для этого лучше подходит Axios, и я вообще не считаю себя его конкурентом.

Разные классы для разных случаев использования.

Лично мне, например, не нужна поддержка IE, но вам она явно нужна.

«Это называется SWITCH/CASE, используй»

Я могу взглянуть на код и рассмотреть возможность переключения некоторых if на переключатель/регистр.

"не вводите накладные расходы на несколько методов, если все они делают одно и то же и являются однострочными. Да, да", но проще сказать ".get()" вместо ".patch(bunchostuff, 'get' )"... накладные расходы на избыточные вызовы функций, вероятно, будут отличаться."

Также доступен обычный метод fetch().

«по возможности ставьте параметры '...' в КОНЦЕ, а не в начале».

Я еще раз взглянул на свой код и обнаружил, что они в конце.

За исключением случаев, когда я вызываю

 .post()

или

 .get()

, которые, конечно же, должны переопределять другие параметры.

Как будто никто не должен вызывать put(), а затем менять метод в настройках, верно?

«Настоящий смех: у меня неприятное чувство, что это можно было бы сделать проще, используя меньше кода, создавая оболочку для XMLHttpRequest, чем используя «await», но это был мой общий опыт с втиснением этого «обещанного» мусора в JavaScript по-старому».

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

Спасибо, что поделились своим мнением. Я предпочитаю более новый метод, поскольку мне не нужно проверять hasOwnProperty(), но я обязательно тщательно обдумаю все ваши мнения.