Write idiomatic TypeScript and JavaScript with efficiency patterns

Gives idiomatic-efficiency guidelines for TypeScript and JavaScript across seven areas: array and object operations, destructuring and spread, async and promises, functions and closures, TypeScript types, React, and TS/JS-specific anti-patterns. Each area pairs a verbose or non-idiomatic pattern directly against the preferred equivalent.

Use this skill when a task matches language-specific super-code guidelines for TypeScript. It's scoped narrowly on purpose: these cover line-level pattern choices, like filter/map versus a loop or type versus interface, not overall architectural decisions. Applying every rule mechanically is itself flagged as a mistake in its own right - over-compression can reduce readability, so a reviewer's judgment about a specific case should always win over blindly collapsing a pattern just because a rule exists for it.

Array and object operations favor a chained filter-and-map over an imperative push loop, reduce over a manual running-total loop, object spread over an Object.assign-then-override sequence, and optional chaining over an explicit existence check before property access:

const result = items.filter(i => i.active).map(i => i.name.toUpperCase())
const total = orders.reduce((sum, o) => sum + o.amount, 0)
const city = user.address?.city

Destructuring and spread favor object destructuring over separate variable assignments pulled off the same object, array destructuring over manual index access, array spread over a chain of concat calls, and rest-destructuring to omit a single key over a mutating delete on a shallow copy. Async code favors async/await wrapped in try/catch over a chained then-then-catch promise pipeline, Promise.all for genuinely independent operations run in parallel over sequential awaits that needlessly serialize unrelated work, and awaiting an already-async function directly instead of wrapping it in a redundant new Promise executor. Awaiting inside a map callback without Promise.all is called out specifically as a real mistake, since it silently sequences work that was supposed to run concurrently, quietly turning a parallel operation into a slow serial one.

For functions and closures, an arrow-function expression body replaces an unnecessary block-and-return, a default parameter value replaces an if-guard reassignment inside the function body, and plain top-level module statements replace an immediately-invoked function expression used for no real isolation reason. In TypeScript's own type system, the compiler is trusted to infer an obvious, simple return type instead of writing it out explicitly; an unknown type paired with a type guard, or a proper generic constraint, does the job a bare any escape hatch would otherwise do unsafely; a single-use prop gets an inline object-shape type rather than a redundant standalone interface, with that interface only getting extracted once the shape is genuinely reused in two or more places; and a runtime instanceof check replaces a type assertion that silences a real type error and can crash unpredictably if the assertion turns out to be wrong. As a general rule of thumb, type suits unions, intersections, and simple aliases, while interface suits extensible object shapes meant to be built on later. React gets its own set of concerns: derived state gets computed directly during render instead of mirrored a render late through useEffect and an extra state variable; useCallback gets reserved for a handler actually passed into a memoized child or used as an effect dependency, not wrapped around every event handler out of habit; an object-literal prop gets memoized with useMemo or hoisted rather than reallocated fresh on every render; and a stable, meaningful item id serves as a list key in place of the raw array index whenever the list can reorder or be filtered. Ten smaller, more mechanical issues round out a dedicated anti-pattern table: loose equality against null, a manual typeof undefined string comparison, double-negation boolean coercion, var left in place of const/let, for...in iteration over an array, an uninterpolated template literal, a leftover console.log in production code, hand-iterating Object.keys instead of Object.entries, ternaries nested more than two levels, and a silently swallowing empty catch block.

Someone reviewing a pull request or cleaning up their own draft who needs the exact preferred replacement for a specific line, not a general style philosophy - the anti-pattern table alone gives ten concrete swaps that would otherwise each need their own explanation in a code-review comment.