only dispatch upload when file load returns error = false

[mattcoleanderson]

Summary of Changes

Pull request closes #3478

Recently loading of files was extracted into an async method. Doing so caused all files, regardless of validation to be uploaded. This change only dispatches and upload if the file loading doesn't return an error.

How to Test

List the steps to test the PR

cd tdrs-frontend && docker-compose up --build
cd tdrs-backend && docker-compose up --build

1. Open http://localhost:3000/ and sign in.
2. Add a disallowed file such as png
3. Verify that a validation error is present

Deliverables

More details on how deliverables herein are assessed included here.

Deliverable 1: Accepted Features

Checklist of ACs:

• When selecting a file, the extension should be checked against allowed extensions and show an error

Deliverable 2: Tested Code

• Are all areas of code introduced in this PR meaningfully tested?
  • If this PR introduces backend code changes, are they meaningfully tested?
  • If this PR introduces frontend code changes, are they meaningfully tested?
• Are code coverage minimums met?
  • Frontend coverage: [insert coverage %] (see CodeCov Report comment in PR)
  • Backend coverage: [insert coverage %] (see CodeCov Report comment in PR)

Deliverable 3: Properly Styled Code

• Are backend code style checks passing on CircleCI?
• Are frontend code style checks passing on CircleCI?
• Are code maintainability principles being followed?

Deliverable 4: Accessible

• Does this PR complete the epic?
• Are links included to any other gov-approved PRs associated with epic?
• Does PR include documentation for Raft's a11y review?
• Did automated and manual testing with iamjolly and ttran-hub using Accessibility Insights reveal any errors introduced in this PR?

Deliverable 5: Deployed

• Was the code successfully deployed via automated CircleCI process to development on Cloud.gov?

Deliverable 6: Documented

• Does this PR provide background for why coding decisions were made?
• If this PR introduces backend code, is that code easy to understand and sufficiently documented, both inline and overall?
• If this PR introduces frontend code, is that code easy to understand and sufficiently documented, both inline and overall?
• If this PR introduces dependencies, are their licenses documented?
• Can reviewer explain and take ownership of these elements presented in this code review?

Deliverable 7: Secure

• Does the OWASP Scan pass on CircleCI?
• Do manual code review and manual testing detect any new security issues?
• If new issues detected, is investigation and/or remediation plan documented?

Deliverable 8: User Research

Research product(s) clearly articulate(s):

• the purpose of the research
• methods used to conduct the research
• who participated in the research
• what was tested and how
• impact of research on TDP
• (if applicable) final design mockups produced for TDP development

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.65%. Comparing base (8ffdb0f) to head (2be4e0e).

Additional details and impacted files

@@           Coverage Diff            @@
##           develop    #3495   +/-   ##
========================================
  Coverage    90.64%   90.65%           
========================================
  Files          310      310           
  Lines         8908     8910    +2     
  Branches       677      678    +1     
========================================
+ Hits          8075     8077    +2     
  Misses         704      704           
  Partials       129      129           

Flag	Coverage Δ
dev-backend	90.44% <ø> (ø)
dev-frontend	92.08% <100.00%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
...-frontend/src/components/FileUpload/FileUpload.jsx	86.95% <100.00%> (+0.38%)	⬆️

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8ffdb0f...2be4e0e. Read the comment docs.

[mattcoleanderson]

@reitermb @victoriaatraft

In this ticket I discovered some buggy code that caused an invalid file to look like the following image. The dotted red line is the collapsed input for uploading a file:

The default look of an invalid file is the following:

However, the intent of the buggy code (after fixing it) was to look like the following as can be surmised from a comment added to the code ("Get rid of existing previews if they exist, and show instructions):

Given this, from a UX perspective which of the latter 2 images would be the best to display in the event that the user chooses an invalid file:

• Show the name of the invalid file that was chosen by the user
• Show the instructions for the file input

[reitermb]

Looking good a11y wise (and in terms of behavior)

[elipe17]

LGTM!

[raftmsohani]

LGTM