GrFileUpload

accept уходит и на <input type="file">, и первым валидатором в цепочку. Только атрибута мало: он ограничивает системный диалог, но перетащить в зону можно что угодно — без валидатора лишний файл дошёл бы до сервера.

<GrFileUpload accept="image/*,.pdf" :request="upload" multiple show-file-list />

Рядом — capture (камера на мобильном) и directory (webkitdirectory, Chromium и Safari).

Fallthrough-атрибуты компонент не перекладывает на input: class и style принадлежат зоне, и inheritAttrs: false увёл бы их с неё. Атрибуты самого input объявлены пропами явно.

showFileList показывает выбранные файлы; у каждого есть кнопка удаления, а retry() повторяет загрузку текущего набора — после ошибки выбирать файлы заново не нужно.

const uploader = ref<GrFileUploadInstance>()

uploader.value?.retry()
uploader.value?.removeFile(file) // удаление обрывает идущую загрузку: она была про прежний набор
uploader.value?.abort()

Удаление последнего файла возвращает состояние в idle: показывать ошибку от набора, которого больше нет, не о чем.

Куда уходят файлы, задаёт ровно один из двух пропов: action — URL для POST multipart, request — свой загрузчик. Передашь оба — отправит request, а action не участвует ни в чём.

Требование «ровно один» типом не выражается, и это ограничение Vue, а не недосмотр: defineProps принимает объектный тип или интерфейс, но не discriminated union — ключи схлопываются в плоский объект, и vue-tsc пропускает и «оба сразу», и «ни одного». Поэтому обе ошибки ловятся в dev-сборке предупреждением в консоли: без него первая всплывала бы на первом выборе файла, а вторая не всплывала бы вовсе — молча проигнорированный action по поведению неотличим от учтённого.

uploadMode решает, чем именно является набор файлов:

• batch (по умолчанию) — весь набор уходит одним запросом (request(files, ctx)). Состояние одно на набор: про отдельный файл сказать нечего, и статуса у него нет;
• per-file — на каждый файл свой запрос. request при этом зовётся с массивом из одного файла: контракт не меняется, и загрузчик потребителя (axios и прочие) продолжает работать без правок.

В пофайловом режиме у строки появляются статус (pending/uploading/ success/error) и процент, а у компонента — retryFile(file) и abortFile(file):

<GrFileUpload
  upload-mode="per-file"
  :concurrency="3"
  :request="upload"
  multiple
  show-file-list
/>

concurrency (по умолчанию 3) ограничивает число одновременных запросов: «пофайлово» без него означало бы «все сразу», и сотня файлов открыла бы сотню соединений.

Сводное состояние считается по худшему исходу: грузимся, пока грузится хоть один; ошибка, если после завершения есть хоть одна; успех — когда успешны все. Процент — среднее по файлам: взвешенная по байтам полоса дёргалась бы назад, когда большой файл стартует после маленького.

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

Пока файл едет, у его строки одна кнопка — «остановить» (значок circle-stop, имя «Cancel upload of …»), а «убрать» появляется, когда загрузка остановлена или закончилась: два одинаковых крестика рядом не различить. Строка списка занимает всю ширину колонки: имя слева и усекается многоточием (полное — в title), статус и кнопки стоят у общего правого края — и в узком контейнере длинное имя их не выталкивает.

Эмиты success, error и progress получают необязательный хвостовой аргумент file — он есть только в пофайловом режиме.

Полоса на GrProgressBar показывается сама, пока идёт отправка, и после успеха держится ещё hideProgressOnSuccess миллисекунд — по умолчанию 800. Задержка не косметическая: полоса, пропадающая в тот же кадр, в котором дошла до конца, читается как «загрузка сорвалась», а не «готово». 0 оставляет полосу навсегда — это режим для своего UI, который убирает её сам.

showProgress: false выключает дефолтную полосу целиком: она не нужна, когда прогресс рисует слот #progress или когда файлы мелкие и полоса успевает только мигнуть. progressTone красит её в фазе отправки, progressLabel даёт имя для скринридера.

Компонент дженерик по ответу: TResponse выводится из request и типизирует payload события success — any из публичной сигнатуры ушёл.

async function upload(files: File[]): Promise<UploadedFile> { /* … */ }

function onUploaded(file: UploadedFile) { /* payload типизирован */ }

<GrFileUpload :request="upload" @success="onUploaded" />

Параметр типа задаётся именно так, через request: в шаблоне SFC синтаксиса <GrFileUpload<UploadedFile>> не существует — это TSX, а не Vue-шаблон. Ветка action типом ответа не управляет: что вернёт сервер, знает только потребитель.

preview рисует миниатюру для файлов image/* в списке. Ссылка (URL.createObjectURL) отзывается при удалении файла, смене набора и размонтировании: без этого blob висит в памяти вкладки до перезагрузки.

Миниатюра декоративна (alt="") — имя файла рядом уже есть, и дублировать его диктору незачем.

<GrFileUpload v-model="files" :request="upload" show-file-list />

modelValue необязателен: без него компонент держит набор сам. Передан — набор следует за пропом, и его можно подменить или очистить снаружи, например после того как форма отправлена.

update:modelValue эмитится, когда меняется сам набор: новый выбор или удаление файла. Не путать с change — тот значит «загрузка завершилась», и это другой момент.

Разница с GrFormFile осталась в назначении, а не в наличии модели: GrFileUpload про отправку (action/request, прогресс, повтор, пофайловые статусы), GrFormFile — про поле формы.

action и request — граница другого рода: заданы оба, работает request; не задан ни один — dev-сборка предупреждает при монтировании, а не на первом выборе файла. Выразить требование типом (discriminated union) в SFC нельзя: defineProps принимает только объектный тип или интерфейс.

beforeUpload — проп-колбэк: он обязан вернуть «пускать или нет», а эмит значения не возвращает. Всё остальное — эмиты: exceed (файлов больше limit), progress, success, error, change, stateChange.

:on-exceed="fn" продолжает работать: у Vue эмит и приходит пропом-слушателем.

• Два быстрых выбора подряд идут внахлёст (валидаторы асинхронны). Актуален всегда последний: у запуска есть номер, и отставший тихо сходит с дистанции, не обрывая загрузку соседа.
• При размонтировании компонент абортит активный XHR и снимает таймер скрытия успеха — иначе загрузка продолжалась бы, а таймер дёргал бы состояние уничтоженного инстанса.
• Кастомный request не обязан звать onProgress. Тогда итоговый объём берётся из размеров файлов, а не из нуля: «100%» при total: 0 потребитель прочитал бы как «загружено ноль».

Доступный контрол — сам нативный <input type="file">; зона роли-виджета не получает, иначе input внутри неё теряется для скринридера (nested-interactive). Фокус input’а зона показывает через focus-within, disabled гасится фоном, а не opacity: прозрачность разбавляет выверенные на AA токены текста.

disabled и readonly приходят и от GrFormField, и от GrForm — не только из собственных пропов. readonly при этом действительно запрещает ввод: набор виден и уходит в форму, но диалог не откроется и drop не примут. Атрибута readonly у <input type="file"> в HTML нет, поэтому системный диалог гасится отменой действия по умолчанию — input остаётся в порядке Tab и объявляется как «только чтение».

Фазы загрузки объявляет живой регион (role="status"), существующий с первого рендера: регион, появляющийся сразу с текстом, часть AT не объявляет вовсе. Прогресс в процентах туда не идёт — диктор захлебнётся.