JavaScript · Frontend

Stop Looping with find(): When Map Actually Earns Its Place in Frontend Code

By Mh · Aug 4, 2026

Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Nested find() calls in loops turn O(n) lookups into O(n²) scans that degrade under real data volumes. Recognizing the signal—array.map() containing array.find() by id—and reaching for Map eliminates that cost and clarifies which data owns the truth at any moment.

Summary

Most frontend data flows as arrays and plain objects, so Map stays on the bench. Three concrete scenarios show where it flips from overkill to the right tool: simple checkbox forms stay with id arrays; multi-select needing full objects moves to Map<id, item>; and the real payoff is merging API refreshes with unsaved user edits via Map<orderId, editData>. The pattern is always the same—build the index once, then get() instead of find().

The order-merge case is the most instructive. A batch collection table pulls fresh API rows while preserving user-filled amounts and remarks across refreshes. Storing only the user-edited fields in a Map, then spreading API data first and user edits second, keeps v-model from mutating source data and prevents stale API fields from overwriting fresh server state. The rule is simple: never save the whole row into the Map; save only what the user actually touches.

Takeaways

— A nested find() inside a map() is a signal that a key-to-data index would eliminate repeated scanning.

— Map.get() is an O(1) lookup; array.find() is O(n), which compounds inside loops into O(n²).

— Simple checkbox forms that only need an array of selected IDs should stay with arrays—Map adds ceremony with no benefit.

— When selection logic requires reading, deleting, or checking full objects by ID, Map<id, item> makes the code read closer to the business intent.

— After an API refresh, store only user-edited fields in a Map keyed by business ID, then spread API data first and user edits second to merge without mutating source data.

— Never save a full API row into a user-edit Map; stale fields like orderStatus or receivableAmount will overwrite fresh server data on the next merge.

Conclusions

Map's real value in frontend isn't as a data structure for storage—it's as a temporary index that decouples API truth from UI state, letting each refresh freely without losing in-progress edits.

The advice to store only user-touched fields in the Map, not the whole row, is a small rule that prevents a whole class of stale-data bugs that are otherwise hard to trace.

Many developers avoid Map because JSON serialization is awkward, but the scenarios shown here never need to serialize the Map—it lives as ephemeral UI state, which is exactly where it fits.

Concepts & terms

O(n²) scan from nested find()

When an array.map() callback calls array.find() on a second array, each item in the first array triggers a full scan of the second. With 1,000 items in each, that's up to 1,000,000 comparisons—quadratic growth that degrades quickly.

Map as an ephemeral index

A Map built from an array keyed by a unique ID serves as a temporary lookup table. It lives only in memory during a user session, never needs JSON serialization, and is discarded when the page closes—ideal for UI state that must survive API refreshes but not page reloads.

Source: juejin.cn ↗ Google Translate ↗ Backup ↗