JSX (JavaScript XML) is a syntax extension for JavaScript that allows us to describe the structure of UI components.
It allows you to write HTML-like code directly in your JavaScript code.
It makes it easier to define and render React elements by resembling the structure of HTML.
JSX gets transformed into JavaScript by tools like Babel or SWC before it's rendered in the browser.
You can embed any valid JavaScript expression inside JSX by wrapping it in curly braces {}. This allows you to toggle classes, calculate values, or map through arrays dynamically.
Since JSX is closer to JavaScript than HTML, React uses camelCase property naming conventions instead of HTML attribute names.
A JSX expression must have exactly one outermost element. If you need to return multiple elements, you must wrap them in a parent (like a <div>) or a Fragment (<>...</>).
You need to add a new button component that shows a label passed via props. How would you write the JSX for this component?
If you accidentally write <div>{user.name}</div> but user is sometimes undefined, what will React render and how can you guard against it in JSX?
While working on a feature, you notice the UI stops updating after a conditional JSX block returns null. Walk me through why that might happen and how you'd debug it.
Your team wants to switch from using className strings to a CSS‑in‑JS solution. How would you refactor existing JSX to accommodate the new styling approach while keeping the component logic intact?
A large codebase has mixed JavaScript and TypeScript files, all using JSX. What are the performance and maintenance trade‑offs of introducing a custom Babel plugin to enforce a specific JSX pragma across the repo?
During a server‑side rendering rollout, you encounter a mismatch error between client and server markup caused by JSX that accesses window. How would you redesign the component to avoid this issue?
Your organization is migrating a legacy React app that uses plain React.createElement calls to JSX. What architectural considerations and migration strategy would you propose to minimize risk and ensure consistency?
We plan to share a component library across multiple teams, some of which use different bundlers and JSX transforms. How would you design the library's build and publishing pipeline to support these variations while keeping the public API stable?