Implement FileInput Component

[TiFu-RNA]

Story: Blazor File Input Component

As a Blazor application developer,
I want a reusable and configurable file input component,
so that users can select or drag and drop one or more files with clear feedback, validation, and the ability to remove selected files before upload.

Functional Requirements

• Create a new Blazor FileInput component that follows the project’s existing architecture, coding conventions, naming standards, and component patterns.

• Support both single-file and multiple-file selection through a configurable parameter.

• When multiple files are enabled, display each selected file individually and allow users to remove files separately.

• Provide a drag-and-drop area that:

  • Clearly indicates when files are being dragged over it.
  • Handles all relevant drag events consistently.
  • Accepts dropped files.
  • Can be clicked to open the native file-selection dialog.

• Support the standard Bootstrap contextual colors.

• Support the component sizes used by the existing design system.

• Avoid custom CSS unless it is required to deliver the expected behavior.

• When custom CSS is necessary, define it using overridable CSS variables so consumers can customize the component.

Validation

Provide parameters for configuring file validation, including:

• Maximum allowed file size.
• Allowed file types or extensions.
• Maximum number of files, where applicable.
• Any additional validation supported by the project’s existing validation patterns.

Validation behavior must meet the following requirements:

• An empty allowed-file-types collection means that all file types are permitted.
• Invalid files must not be silently accepted.
• Display a clear validation message identifying the rejected file and the reason for rejection.
• Validation must work consistently for both file-dialog selection and drag-and-drop.
• In multiple-file mode, one invalid file must not prevent otherwise valid files from being selected, unless existing project conventions require the entire selection to be rejected.

Hint Text

• Provide an optional parameter for displaying supporting text below the component.
• The hint should use the project’s standard small/help-text styling.
• Example: Only .docx and .pdf files are allowed.

Accessibility

• The component must be keyboard accessible.
• The drop area must expose an appropriate accessible label and focus state.
• Validation and file-selection changes must be communicated using the project’s established accessibility patterns.
• Removing a selected file must be possible without using a pointer device.

Documentation and Examples

Update all relevant Docusaurus documentation, including:

• Component overview and usage instructions.
• API documentation for every public parameter, event, and supported value.
• Single-file selection example.
• Multiple-file selection and individual removal example.
• Drag-and-drop example.
• Bootstrap color variants.
• Available component sizes.
• File-size and file-type validation examples.
• Unrestricted file-type example.
• Hint-text example.
• Validation and error-state behavior.

Acceptance Criteria

1. Consumers can configure the component for either single-file or multiple-file selection.
2. Selected files are visibly listed in multiple-file mode and can be removed individually.
3. Users can select files by clicking the drop area or by dragging and dropping files onto it.
4. The component provides clear visual feedback throughout the drag lifecycle.
5. Bootstrap contextual colors and supported sizes can be selected through public parameters.
6. File size, file type, and configured file-count rules are validated.
7. All file types are accepted when the allowed-file-types collection is empty.
8. Rejected files produce clear, actionable validation messages.
9. Optional hint text can be displayed below the component.
10. The component follows existing coding, testing, accessibility, and styling conventions.
11. Any necessary custom styling uses consumer-overridable CSS variables.
12. Automated tests cover selection, drag-and-drop behavior, removal, validation, parameter combinations, and relevant edge cases.
13. Docusaurus demos and API documentation are complete and accurately reflect the implemented component.