Detect Duplicate Rows Before They Become Duplicate Records

A spreadsheet can contain duplicates before your application sees it.

Your database can also contain records that duplicate what is being imported.

Those are two different problems.

Bootstrapware Importer focuses on the first one.

Duplicate rows inside the uploaded file

Suppose email address identifies a contact:

[email protected]
[email protected]
[email protected]

Set duplicateKey="email". The importer flags repeated non-empty values (case-insensitive) before the user completes the import. The first row wins; later rows get an error such as Duplicate of row N.

That gives the person uploading the file a chance to resolve an obvious spreadsheet problem before it becomes a backend problem.

Your database still decides what already exists

Browser-side duplicate detection cannot know every uniqueness rule in your database unless you deliberately expose that state.

Usually it should not.

Your backend still handles whether this customer already exists, whether the row should update an existing record, whether the key is globally unique or workspace-scoped, and whether duplicates should be skipped, merged, or rejected.

Those are business rules.

Bootstrapware handles duplicates inside the uploaded dataset because that is part of making the spreadsheet understandable before submission.

Why the distinction matters

It keeps the importer reusable.

The component does not become tightly coupled to your database or authorization model.

uploaded file → mapping → validation → within-file duplicate detection → normalized rows → your backend's uniqueness rules

That is enough to catch a surprisingly common source of bad bulk imports without pretending the browser is your database.