Finding where a React behavior lives is a retrieval problem, and Atlas attacks it from three angles at once: codebase_search for meaning, grep for exact text, and the lsp tool for the symbol graph. When you only know that a modal closes on outside click, but not that the hook is called `useDismissable`, codebase_search returns the declaration anyway, because Atlas indexes code by AST declarations using tree-sitter rather than blind line windows. Then the lsp tool's findReferences shows every component under `src/components/` that mounts it, and prettier plus Vitest with React Testing Library keep your follow-up change honest.
How do I find which React component implements a behavior I can only describe?
Describe the React behavior to Atlas's codebase_search and the semantic index returns candidate declarations even when your words do not appear in the source. A query like the toast that auto-dismisses after a few seconds surfaces the hook in src/hooks/, in 2026, without you knowing its name.
Naming is the whole difficulty in a React codebase. You know the product behavior (the dropdown closes when you click outside it) but not the identifier (`useOutsideClick`, `useDismiss`, `useClickAway`, all plausible). Atlas's codebase_search queries a semantic index, so plain-language questions return ranked declarations with real file paths under `src/components/` and `src/hooks/`. Atlas searches code with hybrid semantic and keyword retrieval fused by reciprocal rank fusion, which means the semantic side finds the paraphrased match while the keyword side still nails a literal token like `useEffect` or `addEventListener`. Because Atlas indexes code by AST declarations using tree-sitter, a hit is a whole component or hook declaration, not a truncated window that cuts a JSX return in half. That is why the top hit in a React repo is usually a `.tsx` component or a custom hook, opened at its declaration.
How do I confirm a React search hit with grep and read?
Atlas confirms a codebase_search hit in React with grep, which takes a real regex plus include and path filters and runs through ripgrep. Grep an exact token like onPointerDownOutside across src/**/*.tsx, filter out node_modules, then open the best of the top 3 candidates with Atlas's read tool.
Semantic search proposes, grep confirms. Once codebase_search has ranked a candidate React hook, grep the literal identifier to see exactly which files reference it, filtered to the paths that matter (`src/components/`, `src/hooks/`, `src/pages/`). Atlas's grep takes a real regex plus include and path filters and runs through ripgrep, so an include of `*.tsx` keeps your build output and `node_modules` out of the result set. Then open the winner with Atlas's read tool. A wrong path is not silently ignored: read fails loudly with File not found plus a Did you mean list, so a mistyped `src/componets/Modal.tsx` produces a correction rather than an empty answer that you mistake for absence. In a React project where the same component name appears in a barrel file, a stories file, and a test file, that loud failure is what stops you from concluding the behavior does not exist.
How do I find every component that uses a React hook?
Use the lsp tool's findReferences operation to see every callsite of a React hook, and workspaceSymbol to jump to the declaration by name. findReferences reads the language server's symbol graph, so it returns the real caller set rather than a text match that also hits 3 non-callers: a comment, a mock, a story.
Grep tells you where a string appears. The lsp tool tells you where a symbol is actually used. In a React codebase those differ constantly: `useModal` appears in `Modal.stories.tsx` as a doc string, in `Modal.test.tsx` as a mocked import, and in six real components that call it. Atlas's lsp tool's findReferences operation returns the language server's answer, which is the set of genuine references, and its workspaceSymbol operation jumps to the declaration by name when you already know what the hook is called. Combined, they let Atlas summarize the call path back to you with concrete file and line references: this hook is declared at `src/hooks/useModal.ts`, and it is consumed by these components under `src/components/`. That summary, not a list of grep hits, is the deliverable of locating a behavior in React.
Why does Atlas ship three search tools for React instead of one search box?
Atlas ships codebase_search, grep, and the lsp tool because the 3 are complementary, not redundant. Semantic search finds a React hook you cannot name, ripgrep finds an exact string the index may rank low, and the language server finds the true reference set. One fuzzy search box would lose 2 of the 3.
Each of Atlas's three retrieval tools fails where another succeeds in a React repo. codebase_search cannot guarantee an exhaustive list, because ranking is ranking. Grep cannot find a concept, only a string, and in a React app the same behavior is spelled `onClose`, `handleDismiss`, and `close` across three components. The lsp tool cannot see a string-based or dynamic usage, such as a component name passed through a registry object. Atlas runs all three: codebase_search for meaning, grep for exact text with include and path filters through ripgrep, and the lsp tool for the symbol graph. Atlas can also fan this out, since Atlas fans out work to subagents that can run in the foreground or in parallel background sessions, which is how a wide sweep across a large `src/` tree stays fast.
Is it safe to let Atlas explore a React codebase?
Yes. Locating a React behavior uses only 4 read-only Atlas tools, codebase_search, grep, read, and the lsp tool, and every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs. Nothing under src/components/ changes while Atlas is looking.
Exploration in Atlas is separated from editing by design. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, so a search pass over your React project cannot quietly become a write. When you do act on what you found, Atlas computes a unified diff for every file edit and surfaces it for approval before writing, and Atlas snapshots file changes as git patches so edits can be diffed and rolled back. For teams that will not send source to third-party servers at all, Atlas can build its code index with local Ollama embeddings, keeping code off third-party servers, so the semantic index over your `src/components/` tree is built on your own machine. After a change, run prettier and then Vitest with React Testing Library through Atlas's bash tool before you commit.
Step by step
- 01Describe the React behavior in plain language to Atlas's codebase_search, for example the logic that closes a dropdown on outside click. The semantic index returns ranked declarations with file paths even when your words never appear in the source.
- 02Read the ranked hits and note the candidate files, which in a React project are usually a .tsx component under src/components/ or a custom hook under src/hooks/.
- 03Confirm with Atlas's grep, which takes a real regex plus include and path filters and runs through ripgrep. Filter to *.tsx so node_modules and build output stay out of the results.
- 04Open the best candidate with Atlas's read tool. A wrong path fails loudly with File not found plus a Did you mean list, so a typo never reads as absence.
- 05Run the lsp tool's findReferences operation on the hook or component to see every real callsite, and use workspaceSymbol to jump to the declaration by name.
- 06Have Atlas summarize the call path back to you with concrete file and line references, from the hook declaration down to each consuming component.
- 07If you then change the behavior, review the unified diff Atlas surfaces before it writes, and run prettier over the touched files.
- 08Run Vitest with React Testing Library through Atlas's bash tool to confirm the components that consume the behavior still pass, installing anything missing with pnpm.
Frequently asked questions
- how to find which react component handles a behavior
- Describe the behavior to Atlas's codebase_search rather than guessing the identifier. The semantic index returns candidate declarations with real file paths even when your words do not appear in the source, then grep and the lsp tool confirm the hit.
- how do I find all usages of a react hook
- Run the lsp tool's findReferences operation on the hook. Unlike grep, findReferences uses the language server's symbol graph, so it returns real callsites rather than also matching the hook's name in a stories file or a comment.
- grep vs semantic search for finding code in react
- Grep finds exact text and runs through ripgrep with include and path filters. codebase_search finds meaning, which matters in React where the same behavior is spelled onClose, handleDismiss, and close. Atlas ships both because they are complementary.
- atlas says file not found when reading a tsx file
- Atlas's read tool fails loudly with File not found plus a Did you mean list rather than returning nothing. In a React repo that usually means a typo in the path under src/components/, and the suggestion list gives you the correct spelling.
- can atlas index my react code without sending it to a server
- Yes. Atlas can build its code index with local Ollama embeddings, keeping code off third-party servers, so the semantic index over your src/ tree is computed locally.
- how do I jump to a react component declaration by name
- Use the lsp tool's workspaceSymbol operation, which jumps to the declaration by name. Use findReferences when you want every callsite instead, and codebase_search when you do not know the name at all.
- does atlas change my react files while searching
- No. codebase_search, grep, read, and the lsp tool are read-only, and every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs. Any later edit arrives as a unified diff you approve before Atlas writes.
- how do I verify a change after finding the react code
- Run prettier over the touched files, then run Vitest with React Testing Library through Atlas's bash tool. Install anything missing with pnpm. Atlas surfaces the unified diff for approval before it writes any change.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Locate Where a Behavior Is Implemented with Atlas in 2026
How to locate where a behavior is implemented with Atlas in 2026: codebase_search for meaning, grep for exact text, and the lsp tool for the symbol graph.
Atlas for React in 2026
Adopt Atlas, the terminal-native AI coding agent, for React development in 2026. Enhance your workflow with intelligent code search, refactoring, and testing for React components and hooks.
Write unit tests for untested code in React with Atlas (2026)
Add real tests to an untested React component in 2026. Atlas copies your repo's Vitest with React Testing Library conventions, writes the spec, and actually runs it with pnpm.
Audit a React Repository with Parallel Subagents in Atlas, 2026
In 2026, React developers use Atlas with parallel subagents to sweep entire repositories for code problems without blowing the main session's context window. Leverage pnpm, Vitest, and prettier.
Debug a single failing test in React with Atlas in 2026
Pinpoint and fix failing React tests with Atlas, the terminal-native AI coding agent. Use Vitest, React Testing Library, and pnpm to quickly resolve issues in your React codebase.
Research a Third-Party API Before Integrating It in React with Atlas (2026)
How Atlas researches a third-party API before you write a React integration in 2026: websearch finds current docs, webfetch pulls the page, permissions gate every request.
Rename a Symbol Across Your React Repo in 2026 with Atlas
Refactor React functions, classes, or constants across your entire codebase with Atlas. Leverage LSP, grep, and intelligent edits for precise, verified renames in 2026.
Trace a runtime bug from a stack trace in React with Atlas in 2026
In 2026, React developers use Atlas to trace runtime bugs from production stack traces directly in the terminal. Pinpoint the exact line and fix issues without a debugger, leveraging pnpm and Vitest with React Testing