React 19 for Vue 3 Developers, Part 1: What a component actually is, how props work and how you put one component inside another.

So you know Vue 3. You know it well. You can reach for <script setup> in your sleep, you have opinions about ref versus reactive, and you have shipped real apps.

And now, for one reason or another, you have landed in React. Maybe it was a new job, maybe a client project, maybe a team that already made the choice before you arrived. Either way, here you are, staring at a file full of curly braces and wondering why everyone is so calm about it.

Here is the good news, and it is genuinely good news: you are not starting from zero. Not even close. The overwhelming majority of what you already understand about building component-based UIs transfers directly. Components, props, one-way data flow, composition over inheritance, the way you break an interface into pieces, it is all shared vocabulary.

What changes is the syntax, a handful of mental defaults and a few places where the analogy you are carrying over from Vue will quietly mislead you.

This is the first article in a series where we map Vue 3 onto React 19 piece by piece. The format is always the same: the Vue thing you already know, its React counterpart, and then the honest part where I tell you exactly where the comparison falls apart so you do not get burned.

Today we start at the foundation: what a component actually is, how props work and how you put one component inside another.

Image generated with AI

A Component Is Just a Function

Let’s get the biggest conceptual shift out of the way first, because everything else hangs off it.

In Vue, a component is a thing. It is an object (or a <script setup> block that compiles into one) with a defined shape: a setup, some props, a template, maybe some lifecycle hooks. The framework instantiates it, tracks its reactivity and re-renders the parts of the template that need updating when your reactive state changes.

In React, a component is a function. That is the whole definition. It is a JavaScript function that takes some input and returns some markup. There is no special object, none of Vue’s defineComponent or compiler-macro ceremony doing work behind your back. If it is a function whose name starts with a capital letter and it returns JSX, React will treat it as a component.

Here is the same trivial component in both worlds.

Greeting.vue

Greeting.jsx

Let’s break it down. In the Vue file, we have two distinct zones: the <script setup> where our logic lives, and the <template> where our markup lives. The compiler stitches them together. In the React file, there are no zones. The logic and the markup live in the same function body, and the markup is the return value. That <h1> is not a string and it is not a template; it is JSX, which we will get to in a second.

Notice the capital G in Greeting. That is not a style preference, it is necessary. React uses the casing of the name to decide whether <Greeting /> means “render my component” or “render a plain HTML element called greeting.” Lowercase is reserved for DOM elements. This trips up everyone at least once.

JSX Is Not a Template

The thing that feels most foreign coming from Vue is JSX. In Vue, your template is HTML-shaped, and you sprinkle in special attributes (v-if, v-for, v-bind, @click) that the compiler understands. The template is its own little language sitting on top of HTML.

JSX is the opposite philosophy. Instead of putting JavaScript powers into your HTML, JSX puts HTML-shaped syntax into your JavaScript. There are no directives because you do not need them. You have the entire language available already.

This is the single biggest adjustment, so let’s look at the three things you do constantly in a template and how each one translates.

Interpolation

Interpolation.vue

Interpolation.jsx

Single curly braces instead of double. Inside those braces, you can put any JavaScript expression, exactly like you can inside {{ }} in Vue. Same idea, one fewer brace.

Conditionals

There is no v-if. There is no directive at all, because a conditional is just JavaScript, and you already know how to write a conditional in JavaScript. In practice, you reach for the ternary operator or short-circuit evaluation with &&.

Conditional.vue

Conditional.jsx

Ignore the useState line for now, that is Part 2’s whole topic. Focus on the markup. Where Vue gives you v-if and v-else as a matched pair, React gives you a ternary inside curly braces. When you only have an “if” with no “else,” you will usually see the && pattern instead:

That reads as “if isLoggedIn is truthy, render the paragraph.” It works because false && ... evaluates to false, which React simply renders as nothing.

Big disclaimer though: be careful with && when the left side is a number. {items.length && <List />} will happily render a literal 0 on the screen when the array is empty, because 0 is falsy, but React still renders it as text. This is one of those papercuts you will hit, so reach for a real boolean (items.length > 0 && ...) or a ternary when in doubt.

The one thing that ternary did not need, but which you will reach for constantly, is a Fragment. A React component’s return has to be a single root. Our ternary already resolves to a single element, so it returns fine on its own, but the moment you have two siblings with no natural wrapper, you have to group them. Vue (v3) happily lets a component have multiple root nodes. React makes you wrap them in an empty <></>, which is the Fragment:

It is the same instinct as dropping a <template> wrapper around the contents of a v-for or v-if in Vue when you do not want an extra DOM element. (You can also hand back an array or null, but a single root is the everyday case.)

Lists

List.vue

List.jsx

No v-for. You map over the array yourself with plain Array.prototype.map, returning a piece of JSX for each element. If you have ever written a v-for, you already know the shape of this, you are just doing the iteration in JavaScript instead of in an attribute.

Notice the key. This is one place where the analogy holds perfectly.

React’s key does the exact same job as Vue’s :key. It helps the reconciler match elements between renders so it can update them efficiently instead of tearing them down and rebuilding. The difference is purely cultural. In Vue, forgetting :key is a lint warning you might ignore. In React, the key is on you every single time you map, and forgetting it produces a console warning that you will see constantly until you internalize it.

While we are here, a couple of small JSX quirks that catch Vue developers: it is className, not class, because class is a reserved word in JavaScript. And event handlers are camelCased props, so @click becomes onClick and @input becomes onInput. There is no @ and there is no v-on.

One heads-up for form fields: idiomatic React reaches for onChange, and unlike the native DOM change event, React’s onChange fires on every keystroke (the way Vue’s @input does), so do not expect blur-time behavior from it.

Props Are Just Function Arguments

In Vue 3, you declare props with the defineProps macro, and the compiler wires them up into a reactive props object.

UserCard.vue

In React, remember that a component is just a function. So props are just the first argument to that function. There is no macro, there is no declaration step, there is just a parameter. The convention is to destructure it right there in the signature.

UserCard.jsx

And you pass them down the way you would expect, which looks almost identical to Vue minus the colon prefix for bound values.

For a static string, you write it bare (like above), just like Vue. When you want to pass a non-string value (a number, a boolean, an object, a function), you wrap it in curly braces: <UserCard age={42} isAdmin={true} />. That is the React equivalent of Vue’s v-bind or the : shorthand. In Vue :age="42" tells the compiler “evaluate this as JavaScript,” and in React {42} does the same job.

One-way data flow is identical between the two frameworks, and this is worth pausing on because it is a place your instincts are correct. Props flow down, and a child should not reassign its own props. In Vue you will get a dev warning if you reassign a prop (though Vue will not catch a deep mutation of an object prop). In React, props are simply a plain object that the parent owns, and reassigning them does nothing useful, so the same discipline applies for the same reasons.

Here is where the analogy breaks, though, and it’s important. Vue props are reactive in the deep, automatic sense you are used to. When the parent changes a value, Vue’s reactivity system surgically updates exactly the bits of the child’s template that depend on it. React props are not reactive in that sense at all. They are just the arguments from the most recent render. When a parent re-renders and passes a new value down, the child function reruns top to bottom with the new argument. There is no fine-grained tracking happening. That difference is the whole reason Part 2 of this series exists, so file it away for now and we will dig into it properly there.

children Is Your Default Slot

The last foundational piece is composition: putting components inside other components. In Vue you use slots. The default slot is the catch-all for whatever markup a parent nests inside your component’s tags.

Panel.vue

React has a direct equivalent, and it is delightfully boring once you see it. Whatever you nest inside a component’s tags arrives as a prop called children. That is it. It is a normal prop with a special name that React populates for you.

Panel.jsx

Let’s break it down. The nested <p> becomes the value of children, and you render it by dropping {children} wherever you want it to appear. If the default <slot /> is the only slot you have ever really needed, then honestly children will cover the vast majority of your day-to-day, and the mapping could not be cleaner.

Here’s the catch, though. Vue’s slot system is richer than a single children prop. You have named slots for distributing content into multiple locations, and you have scoped slots for handing data from the child back up to the parent’s markup. React has no built-in syntax for either of those, because it does not need new syntax. It just uses props.

For multiple “slots,” you pass JSX as named props:

Layout.jsx

A named slot is just a prop whose value happens to be JSX. And for scoped slots, the equivalent is the render prop pattern (React’s own docs cover it under that name), where you pass a function that the child calls with data and that returns markup. That is its own meaty topic and it is the one part of this comparison that genuinely takes some getting used to, so I will not cram it in here. The thing to hold onto is the principle: anywhere Vue gives you a dedicated slot feature, React leans on the fact that a prop can hold JSX or a function, and you compose from there.

Wrapping Up

Let’s recap the mental reset, because that is really what Part 1 is about.

A React component is a plain function that returns JSX. JSX is JavaScript with HTML-shaped syntax, so instead of directives you use the language directly: ternaries and && for conditionals, .map() for lists, and the same key discipline you already know from Vue.
Props are just the function’s first argument. You destructure them, and one-way data flow works the way your instincts expect.
And children is your default slot, with named props and render props covering the richer slot patterns.

The one thing I want you to carry into the next article is this: React props are not reactive the way Vue props are. They are a snapshot from the latest render, and the component function reruns to produce the next one. That single fact is the key that unlocks how state, effects and re-rendering work, which is exactly where we are headed next.

For the canonical reference as you go, keep the React docs open in a tab, especially the “Describing the UI” section, which covers components, JSX and props in depth.

Happy React-ing!

If you want to start playing around with a React UI library, check out the 50+ components you can use with KendoReact Free.