ES Modules, Imports & Dependency Boundaries
Modern React code is generally organized with ES modules. Named exports make APIs explicit, while default exports can be convenient for single-primary-component modules.
Avoid creating import cycles accidentally. A common healthy dependency direction is UI → feature/application layer → data utilities. If a low-level utility imports a feature component, the dependency graph can become difficult to reason about.
Path aliases can improve readability, but they should not hide architectural boundaries. An import such as @/features/users is useful when it communicates ownership clearly.
Named exports
export type User = {
id: string;
name: string;
};
export function formatUserName(user: User) {
return user.name.trim();
}
// consumer
import { formatUserName, type User } from "./user";💡 Named exports make the public surface of a module explicit.
Key Takeaways
- Use module exports to define intentional APIs.
- Avoid circular dependencies.
- Aliases improve ergonomics but should not replace architectural discipline.