Object Property Filtering (Pick)
Creates a new object with only specified properties, ideal for removing unnecessary fields from API requests
Implementation
Copy the complete example or adapt its typed interface to your project. Comments are kept inside the snippet so the intent travels with the code.
/**
* Pick specified properties from object
* @param obj Target object
* @param keys Array of properties to keep
* @returns New object with only specified properties
*/
function pickObject<T extends object, K extends keyof T>(obj: T, keys: K[]): Pick<T, K> {
return keys.reduce((acc, key) => {
if (obj.hasOwnProperty(key)) {
acc[key] = obj[key];
}
return acc;
}, {} as Pick<T, K>);
}
// Usage Example
const user = { id: 1, name: "John", email: "[email protected]", password: "secret" };
const safeUser = pickObject(user, ["id", "name", "email"]);
console.log(safeUser); // { id: 1, name: "John", email: "[email protected]" }When to use it
Perfect for sanitizing form data before API requests, removing sensitive fields, or creating minimal data objects
Review the input assumptions and browser or runtime support before adopting a utility unchanged. Small helpers are easiest to maintain when their contract stays narrow.
Reasoning and trade-offs
How it works
The key list drives construction of a new object, and only owned properties present on the source are assigned. The generic return type narrows the result to the selected keys without mutating the original value.
What to watch for
TypeScript types cannot prove that runtime key input is trustworthy. Getters can run during access, symbol keys require deliberate support, and copying a property does not deep-clone the referenced value stored under it.
Production use
Use pick at API boundaries to create narrow payloads or view models from a larger record. Prefer an explicit allowlist for sensitive data because it remains safe when new source properties are added later.
Before you ship
- Confirm the input contract with tests that cover empty, invalid, boundary, and representative real-world values before sharing the helper across a codebase.
- Keep the function focused on one responsibility and name any project-specific policy explicitly instead of hiding it inside a generic-looking utility.
- Measure behavior in the browsers or runtime versions your product supports, especially when timing, storage, DOM state, locale, or network access is involved.
- Document the return type, mutation behavior, failure mode, and performance characteristics beside the call site so future maintainers can evaluate changes safely.
- Compare the example with current official platform documentation when it relies on a browser API, language feature, or runtime behavior that may change over time.
- If the helper crosses a trust boundary, validate again on the server and avoid treating browser-side checks, TypeScript annotations, or formatted output as a security guarantee.
- Add a small regression test whenever a real edge case is discovered; concrete examples preserve the reason behind a guard more reliably than a general comment.