Precise Data Type Detection
Replaces typeof to solve inaccurate type checking issues (e.g., typeof null === 'object'), returns lowercase precise type string
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.
/**
* Precise data type detection
* @param value Value to be detected
* @returns Type string (string/number/array/object/null/date etc.)
*/
function getType(value: unknown): string {
return Object.prototype.toString.call(value).slice(8, -1).toLowerCase();
}
// Usage Example
console.log(getType('hello')); // 'string'
console.log(getType(null)); // 'null'
console.log(getType([])); // 'array'
console.log(getType(new Date())); // 'date'When to use it
Ideal for scenarios requiring precise type differentiation, such as form validation or type checking before data processing
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
Object.prototype.toString exposes the internal classification used for built-in values. Slicing the bracketed result produces a predictable lowercase label for arrays, dates, regular expressions, null, and other values that typeof groups too broadly.
What to watch for
Custom classes still report their constructor-oriented tag, and Symbol.toStringTag can change the reported value. Treat the result as runtime description rather than proof that an object satisfies a business interface or TypeScript contract.
Production use
Use this helper at debugging, serialization, or validation boundaries where several built-in kinds genuinely require different handling. Within typed application code, prefer narrow type guards that communicate the exact capability a caller needs.
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.