React Component Name Converter

React Component Name Converter

PascalCase writes HelloWorldExample. React requires it. In JSX, a lowercase tag name is compiled to a string — becomes the HTML element — while a capitalised one is treated as a variable reference. So a component named myButton renders nothing and produces no error; renaming it MyButton is what makes it work. The convention is enforced by the compiler, not by a style guide.

Conversions

Input	PascalCase
hello world example	HelloWorldExample
XMLHttpRequest	XmlHttpRequest
user_first_name	UserFirstName
Total Order Count	TotalOrderCount

Acronyms are where conventions diverge. XMLHttpRequest stays intact in PascalCase, but Go's own style guide requires initialisms to be fully capitalised — ServeHTTP, not ServeHttp — while C# convention capitalises only the first letter of an acronym longer than two characters.

The Same Text in Other Cases

Case	Result
camelCase	helloWorldExample
snake_case	hello_world_example
SCREAMING_SNAKE_CASE	HELLO_WORLD_EXAMPLE
kebab-case	hello-world-example
Train-Case	Hello-World-Example
dot.case	hello.world.example

JSX Reads Capitalisation as Meaning

In JSX a lowercase tag compiles to a string —

becomes the HTML element — while a capitalised one compiles to a variable reference. A component named myButton therefore renders an unknown HTML element and raises no error at all, which is among the more confusing failures a React beginner meets.

The same rule governs member expressions: works because Foo is capitalised, regardless of what follows the dot.

Converting in Code

``javascript const pascal = (s) => words(s) .map((w) => w[0].toUpperCase() + w.slice(1).toLowerCase()) .join(''); `

Lower-casing the remainder of each word destroys deliberate internal capitals. parseJSON becomes ParseJson, which is correct C# and wrong Go — the convention has to be a parameter, not a hard-coded rule.

Converting at the API Boundary

The recurring friction is that JavaScript uses camelCase and Python, Ruby, Go and SQL use snake_case. The fix is to convert in exactly one place — the client that talks to the API — rather than letting both conventions into the same codebase.

`javascript const toCamel = (s) => s.replace(/_([a-z])/g, (_, c) => c.toUpperCase()); const toSnake = (s) => s.replace(/[A-Z]/g, (c) => '_' + c.toLowerCase());

// Recursively, for a whole payload const convertKeys = (value, fn) => Array.isArray(value) ? value.map((v) => convertKeys(v, fn)) : value && typeof value === 'object' ? Object.fromEntries(Object.entries(value).map(([k, v]) => [fn(k), convertKeys(v, fn)])) : value; `

Two things to watch: keys that are user data rather than field names must not be converted, and the round trip is not always lossless — userID → user_id → userId changes the original.

Where Each Convention Is Mandatory

Not stylistic — these will break if you deviate:

Context	Requirement
Environment variables	Uppercase with underscores; POSIX reserves lowercase
Custom HTML elements	Must contain a hyphen
Python modules	Cannot contain hyphens; the import statement will not parse
SQL identifiers	Folded to one case unless quoted, so camelCase does not survive
React components	Must start uppercase, or JSX treats it as an HTML tag

Renaming Safely

A find-and-replace across a codebase will hit strings, comments and unrelated identifiers. Use your language server's rename symbol instead — it understands scope. For a bulk rename across files, restrict the pattern with word boundaries and review the diff before committing:

`bash grep -rn '\buserId\b' src/ # look first ``