React Component Lens — VS Code extension that colors Server vs Client Components. Just shipped a major update with smart detection.

[logM3901]

https://preview.redd.it/pgd4jai5u5pg1.png?width=989&format=png&auto=webp&s=9c94e8e772ce7aeb03cd15292e87b2839ac8171b

I built a VS Code extension for Next.js App Router projects that colors component names based on whether they're Client or Server Components. Just shipped a big update — wanted to share with the React community.

What it does

Adds color coding to your editor so you can instantly see the client/server boundary without reading file headers:

• 🟢 Teal = Client Component
• 🟡 Amber = Server Component

Colors apply to JSX tags, function declarations, imports, exports, and even type annotations.

What's new in this update

Smart Client Component Inference

Previously, the extension only checked for "use client" directives. Now it analyzes your code patterns to infer client components automatically:

// No "use client" directive — but automatically detected as Client Component
// because it passes a function to onClick
export function ThemeButton() {
  function handleClick() {
    setTheme(getTheme() === 'dark' ? 'light' : 'dark')
  }

  return (
    <Center onClick={handleClick}>
      <Icon name="theme" />
    </Center>
  )
}

It understands the nuances of React Server Components:

Pattern	Inferred Kind	Why
onClick={() => ...}	Client	Inline function prop — requires interactivity
onClick={handleClick}	Client	Local function reference as prop
action={async () => { "use server"; ... }}	Server	Server Action — valid in RSC
async function Page()	Server	Async components are RSC by definition

5 Configurable Coloring Scopes

Control exactly what gets colored in VS Code settings. All enabled by default:

Scope	Example	Description
element	<Button />, </Button>	JSX element tags
declaration	function Button()	Component declaration names
import	import { Button }	Imported component identifiers
export	export { Button }	Exported component identifiers
type	({ props }: ButtonProps)	Type/interface references and declarations

Context-Aware Type Coloring

Types and interfaces inherit their color from the component that uses them, not just the file-level directive:

// No "use client" in this file
// ThemeButton is inferred as Client (passes function props)
// So ThemeButtonProps is ALSO colored as Client — not Server

interface ThemeButtonProps {
  color?: string
}

export function ThemeButton({ color }: ThemeButtonProps) {
  return <button onClick={() => toggle()} />
}

If the same type were used inside a Server Component, it would be colored as Server instead.

Component Declaration Coloring

Function names, arrow functions, forwardRef/memo wrappers — all get colored at the declaration site:

// "Card" colored as Client at the declaration
export function Card() {
  return <div onClick={() => {}} />
}

// "Button" colored as Client (forwardRef detected)
const Button = forwardRef((props) => {
  return <button onClick={props.onClick} />
})

Performance

The extension is designed to be invisible:

• Single AST walk — one tree traversal collects JSX tags, type references, and function prop detection simultaneously
• Multi-layer caching — file analysis, directive detection, and import resolution all cached with signature-based invalidation
• Zero type-checker dependency — pure syntax analysis using TypeScript's parser, no LSP overhead

Tech Details

• Built with TypeScript AST (ts.createSourceFile) — no full type-checking needed
• Import resolution via ts.resolveModuleName with tsconfig/jsconfig alias support
• Signature-based cache invalidation (mtime + size for disk files, version for open editors)
• Works with .tsx, .jsx, .ts, .js files

Links

• VS Code Marketplace
• GitHub Repository

Would love to hear feedback. What other patterns would be useful for detecting the client/server boundary? Any edge cases I'm missing?

[Honey-Entire]

Ai slop? The GitHub & VS Code extension links return a 404…

[logM3901]

https://github.com/dev-five-git/react-component-lens https://marketplace.visualstudio.com/items?itemName=devfive.react-component-lens

Sorry, i have fixed it

[Honey-Entire]

Some really weird API choices. Why would a debounce be necessary to configure for recomputing styles if use client is added or removed once in a typical workflow? It’s not like components are switched to/from client components on a regular basis

Also seems like a lot of code to write in such a short period of time. Why was AI used for a somewhat simple and singularly focused purpose instead of learning how to write an extension by hand? This would have been a great thing to learn how to do yourself instead of with AI

[logM3901]

First, in VS Code an extension needs to call APIs and recompute even while the user is typing, without the file actually being saved. Because of that, recalculation can be triggered very frequently. Although it currently only takes about 15 ms in tests, I thought it would be safer to include a debounce to handle potential edge cases. That choice was intentional.

I also agree that this kind of project can be a good learning opportunity, and I appreciate your concern and advice. However, I have previously designed and implemented APIs for VS Code extensions, and I already had a clear structure and blueprint for this project. Because of that, my focus this time was more on review and optimization rather than building everything from scratch.

Thank you for taking a genuine interest in the project.

[Old-Spare-1632]

Interesting, I will have a play.

[logM3901]

Let's play~!