Document upload

What it is made of

GdCard — the step, capped at 560px
GdDropzone — the target, with its own accept and hint
GdFileRow — one receipt per file, across uploading, done and failed

The component pair is documented on Slider & upload; this page is their composition.

The block

Supporting documents

A site plan is required. DA forms and elevations help the certifier answer faster.

RP80432-site-plan.pdf2.4 MB · PDF

elevations-north-east.pdf

62%

Supporting documents — a lodgement in progressDrop something on it. The first two rows are staged states; the zone itself is live.

Code

<GdCard>
  <p class="title">Supporting documents</p>
  <p class="hint">A site plan is required. DA forms and elevations help the
     certifier answer faster.</p>

  <GdDropzone
    accept=".pdf,.dwg,.jpg"
    multiple
    hint="Up to 20 MB · PDF, DWG, JPG"
    @files="onDocs"
  />

  <GdFileRow
    v-for="f in docs"
    :key="f.name"
    :name="f.name"
    :meta="f.meta"
    :state="f.state"
    :progress="f.pct"
    @remove="remove(f)"
  />
</GdCard>

Rules

Say what is required versus helpful ABOVE the zone — not in the error after someone chose the wrong file.
State the limits in the dropzone's own hint — the size cap and the accepted formats, in words, beside the target.
Keep one row geometry across uploading, done and failed. Do not add or remove elements per state.
Put a failure's reason IN the row and leave it there. Retry sits beside it.
Never report a failure with a toast alone. It evaporates, and the file it was about does not.

Behavior & Anatomy

The requirements go before the choice, not after it

The card says what is required versus helpful BEFORE anyone chooses a file. A person who learns the site plan was mandatory from the rejection has already spent the attention they had for this step, and the second attempt is made by someone annoyed rather than someone informed.

One geometry across every state

The rows keep one geometry across uploading, done and failed — a list that jumps as files land reads as breakage, and it reads that way at exactly the moment the user is deciding whether the upload worked.

A toast is not a reason

A failure's reason is IN the row and stays there; a toast that evaporates is not a reason, it is a notification that a reason once existed. Retry lives beside it so the fix is where the problem is.