matterai

Optimizing Re-renders and Memoization:

• Find components that re-render frequently or have heavy computations. Focus optimization efforts there;
• Wrap functional components in React.memo if they render the same output given the same props.
• For computationally heavy operations or derived data, use useMemo to memoize the result between renders. Compute the value only when its dependencies change;
• If you pass callbacks to child components (especially to optimized children that rely on reference equality), wrap those in useCallback to avoid re-creating functions on every render;
• If an object is meant to remain the same across renders (e.g., a static config), define it outside the component or use a useRef to keep a stable reference;

Unnecessary Renders with Hooks optimization:

• If you have large subtrees that don’t need to update under certain conditions, conditionally render them only when needed (using {condition && <Component />}) rather than always including them and toggling via CSS;
• In

matterai

Using TypeScript with React Components and Hooks:

• Always define the prop types for your components. Use TypeScript’s interface or type to describe the shape of props. For example: interface ButtonProps { label: string; onClick: () => void; disabled?: boolean }. Then const Button: React.FC<ButtonProps> = .... Similarly, if you use useState with an initial null or empty value, specify the type to avoid it being any.
• Avoid any: use unknown or generics to handle flexible data, or union types if something can be multiple shapes. For example, if a prop can be either string or number, type it as string | number rather than any. Enable strict flags in your tsconfig (strict: true) to help catch implicit any and other pitfalls.
• Leverage Type Inference: You don’t need to annotate everything. For instance, const [count, setCount] = useState(0) is inferred as number. But in cases where it can’t infer (like useState(null)), provide a generic type. Strike a balance between explic

matterai

Structuring Large React Applications:

• Use feature-based structure approach (grouping by features or domains) and layered structure (grouping by type of file: components, hooks, utils, etc.);
• Feature (domain) based example: you might have a src/features/ directory with subfolders like auth/, dashboard/, products/, etc. Inside each, you could have files like components/, hooks/, services/, and so on, related only to that feature. Shared resources (like common UI components or utility functions) live in a separate folder (e.g., src/components/ for reusable UI, src/utils/ for utilities);
• Avoid Deep Nesting: aim for a balance – group things meaningfully, but don’t create one-file-per-folder scenarios either.
• Use naming conventions for files: Use kebab-case for filenames, and some prefix component files with capital letters;

Managing Reusable Components and Utilities:

• Centralize Reusable Components: For truly shared components (used in multiple features), maintain a directory for

matterai

Component Structure and Organization:

• Use functional components and hooks instead of class components for most use cases;
• Divide components into presentational and container components: container components handle data fetching or state and pass data to presentational components, which focus on UI;
• Structure files by feature or domain in large apps. For example, group all files related to a feature (components, hooks, styles, tests) in one folder. Keep shared generic components (like UI elements) in a separate common folder;
• Ensure each component has a clear purpose. If a component grows too complex or handles unrelated concerns, break it into smaller components.

Hooks:

• Only call hooks at the top level of your components or custom hooks (never inside loops or conditionals);
• Always specify all necessary dependencies in hooks like useEffect and useCallback to avoid stale state or infinite loops;
• Use useMemo to memoize expensive calculations so they run only when inputs change, and `useCallb