Glossary + Explain Like I'm Five

[sylwiavargas]

tl;dr This thread contains plain English and explain-like-I'm-five definitions of the terms and concepts used throughout other discussions. Scroll to comments to find (or add) a term and explanations connected to it ✨

---

First of all, thank you for amazing discussions and articles shared here so far. It has been an amazing reading adventure 💕

As has been pointed out in another thread, complicated technical terminology often poses an obstacle for folks to learn new technology. I'd like to invite you all to co-create a glossary of terms that are crucial for this release but that are not commonly-used in the beginner/intermediate courses and tutorials.

In other words, let's help the new React developers out there get as excited about this release as we are!

Structure

Here's a structure I propose:

• Each of the terms will be located in its own comment section below, which will allow keeping explanations of the same terms together and help folks find the relevant content fast
• Add a definition/explanation as a reply to a specific comment. Please try keep it Plain English or Explain Like I'm Five (ELI5) format and/or link tweets, blog posts, or other threads in these discussions that you think may be helpful for beginners!
• If you think a new word could be explained -- please add it as a comment!

[sylwiavargas]

✨ CONCURRENCY

How do you explain concurrency? Add your definitions in the replies below 👇

[sylwiavargas]

Sy Brand explained concurrency in a video using a metaphor of feeding cats 😻

[gaearon]

Concurrency means that tasks can overlap.

Let's use phone calls as an analogy.

No concurrency means that I can only have one phone conversation at a time. If I talk to Alice, and Bob calls me, I have to finish the call with Alice before I can talk to Bob.

Concurrency means that I can have more than one conversation at a time. For example, I can put Alice on hold, talk to Bob for a bit, and then switch back to talking to Alice.

Note that concurrency doesn't necessarily mean I talk to two people at once. It just means that at any moment, I may be in multiple calls, and I choose who to talk to. For example, based on which conversation is more urgent.

Now, to translate the analogy, in React's case "phone calls" are your setState calls. Previously, React could only work on one state update at a time. So all updates were "urgent": once you start re-rendering, you can't stop. But with startTransition, you can mark a non-urgent update as a transition.

You can think of "urgent" setState updates as similar to urgent phone calls (e.g. your friend needs your help) while transitions are like relaxed conversations that can be put on hold or even interrupted if they're no longer relevant.

[kishoreandra]

"In a call with Bob", "In a call with Alice" ..

[MatanBobi]

Just an idea, I think it will be better to state that putting something on hold means there's only one resource shared (the call's bandwidth?) and that's basically co-operative concurrency and not real concurrency? In simple concurrency we'll have many calls open together (or just a conference call?) and we can interact with any of them at the same time.
Since React uses the JS runtime which is only single-threaded, that's more of a co-operative concurrency where we can pause tasks and return back to them later.

[sylwiavargas]

✨ SUSPENSE

How do you explain suspense? Add your definitions in the replies below.

[sylwiavargas]

#28 is a very helpful thread with two main analogies for Suspense

• @Skn0tt's analogy:

Imagine a component that needs to do some asynchronous task before it can render, e.g. fetching some data.

Before Suspense, such a component would keep an isLoading state and return some kind fallback (an empty state, skeleton, spinner, ...) based on it.

With Suspense, a component can now, during rendering, shout "HALT! I'm not ready yet. Don't continue rendering me, please - here's a pager, I'll ping you when I'm ready!1"
React will walk up the tree to find the nearest Suspense boundary, which is set by You and contains the fallback that'll now be rendered until the pager is ringing.

• @gaearon's analogy:

Another way I like to explain it is that it's like throw / catch but for loading states. When a component says "I'm not ready" (exceptional situation, like throw), the closest Suspense block above (like catch) shows the fallback instead. Then, when the Promise resolves, we "retry" rendering.

One key difference with traditional Promise-based programming is that Promises are not exposed to the user code. You don't deal with them directly. You don't Promise.all them or .then them or anything like this. Instead of "wait for Promise to resolve and run some user code", the paradigm is "React will retry rendering when it resolves". In some ways it's simpler but it takes some "unlearning" because the user loses some control they might be used to from traditional Promise-base programming.

[sylwiavargas]

✨ BATCHING AND AUTOMATIC BATCHING

How do you explain batching and automatic batching? Add your definitions in the replies below.

[gaearon]

Batching

Imagine you're making a breakfast.

You go to market to get some milk. You come back. Then you realize you need granola. You go to market to get granola. Then you come back. Then you realize you need cookies. You go to market and get cookies. Finally, you can eat your breakfast.

But surely there is a more efficient way to do it? Instead of getting each item the moment you think of it, it's a good idea to compile a shopping list first. Then you go to market, get everything you need, and make your breakfast.

That's batching.

In React's case, each individual item is a setState call.

setIsFetching(false);
setError(null);
setFormStatus('success')

React could re-render ("go to the shop") after each of these calls. But it's not efficient. It would be better to record all the state updates first. And then, when you finish updating all pieces of state, re-render once.

The challenge is when React should do it. How can it know that you're done updating the state?

For event handlers, it's easy:

function handleClick() {
  setIsFetching(false);
  setError(null);
  setFormStatus('success')
}

React is the thing calling your click handler.

// Inside React
handleClick()

So React will re-render right after:

// Inside React
handleClick()
updateScreen();

That's how React always worked.

Automatic batching

Coming back to this example:

setIsFetching(false);
setError(null);
setFormStatus('success')

What if doesn't happen during an event? For example, maybe this code runs as a result of a fetch. React has no idea when you're going to "stop" setting states. So it needs to pick some time to update the screen.

This is similar to how maybe you're not having breakfast, but just getting random cravings throughout the day. Do you go to the market the moment you feel you're hungry? Or do you wait a bit of time (say, 30 minutes), and then go to the market with a list of whatever you've come up with so far?

Previously, React used to re-render immediately in this case. This means you'd get three screen updates for three setState calls. That's not very efficient.

With automated batching in React 18, it will always batch them. Practically speaking, it means React will "wait a bit" (the technical term if "until the end of the task or the microtask"). Then React will update the screen.

[sylwiavargas]

✨ HYDRATION

How do you explain hydration? Add your definitions in the replies below.

[sylwiavargas]

Dan's explanation of hydration in #37 (under "what is SSR?" subheader) is on point 💯 Here's an excerpt:

The process of rendering your components and attaching event handlers is known as “hydration”. It’s like watering the “dry” HTML with the “water” of interactivity and event handlers.

For more context, refer to the thread.

[sylwiavargas]

From Bruno Nardini's tweet:

The analogy I like for "hydration" is that it loads dry, and then oil is applied to the gears to move it.

[meganesu]

From what I understand:

Hydration is only used with server-side rendering. When you use SSR, the process of rendering components in your browser has two steps:

1. Send the non-interactive, server-side rendered HTML and CSS to the browser. That way, your users have something to look at while they wait for the JS for your page to load.
2. "Hydrate" that HTML and CSS when your JS finishes loading, so that users can interact with things on your page (click buttons, toggle dropdowns, etc.).

(Still learning about SSR, so please lmk if I got anything wrong!)

[sylwiavargas]

✨ SSR

How do you explain ssr? Add your definitions in the replies below.

[laurieontech]

SSR can be explained well with food.

Suppose you go to a salad bar and get each of your ingredients to make your own salad. You put them together, layer things the way you want, and then eat it. That's client-side rendering. You're putting together the pieces (HTML, CSS, JS, yourself).

Alternatively, you can go to the salad bar and pick up a salad that's pre-made. It's all ready for you, all you have to do is eat it. That's server-side rendering. You get render ready HTML delivered directly from the server.

[sophiebits]

Most people think of React as running on the client (i.e., in the user's browser). When components get rendered, that results in changing the HTML that's on the page. When a user visits a webpage using React, first we need to download React and the JavaScript code for each React component, and then in their browser we run that code to figure out what HTML we want to show on screen. Once that happens, the user can see the app and interact with it.

Server-side rendering (SSR) is a tool designed to speed up that process so that pages using React load faster. When using SSR, we first run the components on the server that's sending the files for the page to the user. We take the HTML outputted by those components and send that HTML to the user's browser. As soon as that arrives, the user can see the full content of the page. Note that the HTML by itself is a snapshot of what the page should initially look like and it's not interactive by itself. So we still need to download React and the JS code for each React component, and then we need to tell React to "take control" of the HTML that's already in the page, which is called hydration. Once that finishes, the user can see the full content of the page and they can interact with it.

SSR helps make the initial page visible sooner but it doesn't make it interactive sooner because you still need to wait to download and run all the same JS code – with SSR, we're running all the components on the server now, but we're also running all of them on the client still. (Upcoming work on Server Components – a new experiment by the React team – will help make it so you can run some components only on the server which can help this, but it won't be ready for a while.)

In order to use SSR, you need to do two things: (a) make sure that each React component in your codebase only uses features that work on both server and client (there are some requirements, like not using the window object that's only available in browsers), and (b) change your server-side code to call React and do something with the resulting HTML. Some frameworks like Next.js come with SSR support out of the box, meaning that they have done part (b) for you.

[sylwiavargas]

✨ PASSIVE EFFECTS

How do you explain passive effects? Add your definitions in the replies below.

[gaearon]

There are two types of effects:

• useEffect = "effects"
• useLayoutEffect = "layout effects"

Sometimes when you say "effects" it's unclear if you mean both or just the first kind. This is why the first kind (useEffect) is sometimes called "passive".

We avoid this terminology anywhere in the docs, but we used it between in the core team discussions and maybe some comments on GitHub. I think that's where library maintainers may have picked it up. I wouldn't expect application authors to know or care about this terminology — but if you see it, all it means is useEffect, nothing more.

[sylwiavargas]

✨ DISCRETE EVENTS

How do you explain discrete events? Add your definitions in the replies below.

[gaearon]

"Discrete" events is not a concept we use anywhere in the docs. It's not a concept we expect React application developers to know or care about.

However, it comes up when we explain how automatic batching works. What we have to clarify is that for some events, like clicks, we guarantee that the screen is updated before the next event can happen. This is important for UIs like counters (imagine the user pressing the button two times very fast) or forms (where sending a form may disable it, and if it doesn't happen before the second click, you risk sending a form twice).

We call events like these "discrete". This means that each event is separately intended by the user. If I click twice, it's because I mean to click twice. If I type "h", "e", "l", "l", "o", it's because I mean to type "hello".

This is different from events like mousemove. I may move the mouse over ten different coordinates but I don't intentionally mean any of these separate coordinates. As a user I have no idea how many mousemove events I just performed. I only moved the mouse. We call such events "continuous" — as in, what matters is the latest one, not how many there happened.

These concepts only matter for React internally, because it may batch updates in multiple continuous events, but it would still update the screen for each discrete event in a row. However, as a React user, you probably won't need to think about this.

[sylwiavargas]

✨ PROMISE TICK

How do you explain promise tick? Add your definitions in the replies below.

[gaearon]

A Promise is an object that represents something that will be available in the future. You can think of a Promise as similar to a timer you might get in some fast food joints. When the timer rings, you pick up your order.

let food = await cook()
eat(food)

When you see code using await, it’s important to understand your function doesn’t execute all at once. Instead, each await “split” your function. There’s a part that runs before (cook() gives you a Promise). Then you say to resume when the food is done. Other code will be able to execute in the meantime. Finally, when the food is ready, you’ll jump back into this function, initialize the food variable, and eat it.

A “Promise tick” refers to the moment when JavaScript resumes your function that was waiting for a Promise. It’s called a “tick” because it’s like a timer. When the result is ready, Promises don’t resume your functions immediately. Instead they do it as soon as possible after the currently running code finished executing. You can think of this as a restaurant owner waiting to call your “timer” until their hands are free rather than the moment they’ve finished making the meal.

[sylwiavargas]

✨ FLUSH SYNC

How do you explain flush sync? Add your definitions in the replies below.

[gaearon]

flushSync is the name of the method that lets control when React updates the screen ("flushes" the state updates). In particular, it lets you tell React to do it right now ("synchronously"):

flushSync(() => {
  setState(something);
});
// By this line, the screen has been updated

"Flush synchronously" = "Update the screen now"

Normally, you shouldn't need flushSync. You would only use it if you need to work around some issue where React updates the screen later than you need it to. It is very rarely used in practice.

[sylwiavargas]

✨ CODE SPLITTING

How do you explain code splitting? Add your definitions in the replies below.

[laurieontech]

Not sure this is allowed, but I wrote a blog post to try and explain this: https://laurieontech.com/posts/code-splitting/

The summary is airline luggage limits. You can only have 50 pounds in a bag. But you need to bring 150 pounds worth of stuff. So you split it up into three bags so each of them can be flown at the same time, but still be under the limit.

[shrutikapoor08]

I also took a pass at explaining code splitting. It is here. . If this looks good, I will publish it.

[sylwiavargas]

✨ DEBOUNCING AND THROTTLING

How do you explain debouncing and throttling? Add your definitions in the replies below.

[gaearon]

What is debouncing and throttling?

Debouncing and throttling are too common techniques for dealing with things that happen "too often". Imagine you're meeting a friend, and they are telling you a story, but they struggle to pause when talking. Let's say you want to accommodate them while also responding to what they have to say, when possible. (I know this might be a bit contrived, but bear with me!)

Let's say you can never speak at the same time. You have a few strategies:

Synchronous

You could respond to each sentence the moment they finish it:

This might work okay if your responses are short. But if your responses are longer, this could make it very hard for them to finish the story. So this strategy isn't great.

Debounced

You could wait for them to stop talking. For example, if they pause for long enough, you could start responding:

This strategy works well if your friend is occasionally making pauses. However, if they're talking for a few minutes without a pause, this doesn't let you respond at all:

Throttled

You could decide to respond at most once a minute. Here, you keep count of how long you haven't spoken for. Once you haven't spoken for a minute, you insert your response right after the friend's next sentence:

This strategy is helpful if your friend wants you to respond as they go, but they don't ever create pauses for you to do it. But it's not great if they're creating pauses but you're still waiting out for no reason:

How does this relate to React?

Friend's "sentences" are events like button clicks or keyboard typing. Your "responses" are updating the screen.

You use debouncing or throttling when the user is doing something too fast (e.g. typing), and updating the screen in response to each individual event is just too slow. So you either wait for the user to stop typing (debouncing) or you update the screen once in a while, like once a second (throttling).

What about React 18?

The interesting thing is that startTransition makes both strategies unnecessary for many cases. Let's add one more strategy that you didn't have before React 18:

Cooperative

You start responding immediately the moment your friend finishes a sentence, without waiting. But you've agreed with your friend that they may interrupt you if they want to keep going. So in that case you'll abandon your attempt to respond. Right after the next sentence, you'll try again. And so on:

(You also agree that you will interrupt them if enough time has passed and you still haven't managed to respond. This prevents the case where you don't get to speak for too long.)

Note how in this strategy you're not wasting any time and also don't prevent your friend from continuing.
This gives you the best of all three previous approaches. (Who would have thought that being cooperative helps!)

In the coding example, this means that React starts rendering immediately after the user types. There's no need to delay doing it (like debouncing does). If the user types again, React will just abandon that work and start again. If rendering was fast enough to fit in the pause between events, then you haven’t wasted any time (by waiting unnecessarily). You’re also not wasting time on finishing a render that's no longer needed.

You can see a demo of the difference here. Try typing into the input. The more you type, the more complex graph we draw (artificially slowed down to show the point). See the different behavior between the three strategies. How do they behave when as you keep typing longer text into the input?

Which one feels smoother?

[samchan0221]

@gaearon
In your demo the works that we abandoned are totally client side works. But in many application we will be sending request to a server whenever we type. In this case even the rendering is abandoned the network request is still fired. So I think the debounce and throttle strategies are still relevant here? 🤔

[sylwiavargas]

✨ SUB-TREE BASIS

How do you explain sub-tree basis? Add your definitions in the replies below.

[gaearon]

I believe this refers to a sentence from #4:

These features are opt-in on a sub-tree basis without enabling StrictMode for your entire app.

This is confusing wording. "On a sub-tree basis" here means "for individual parts of the tree instead of the entire app". Here is how I would reword this sentence:

You can start using these features in a small part of your tree without enabling Strict Mode for your entire app.

I have edited it. Thanks for noting!

[sylwiavargas]

✨ STATE TRANSITION

How do you explain state transition? Add your definitions in the replies below.
follow up q: how do we know it's expensive?

[gaearon]

Colloquially, a “state transition” is the same as a “state change”. For example, maybe you change activeTab state from "home" to "profile". You could say this is a “state transition” from Home to Profile.

Usually by “transitions” people mean larger updates. Like when more things happen. Maybe some data needs to be fetched, a big part of the screen gets changed, maybe there’s some animation.

React 18 builds on this intuition and introduces an explicit concept of “transitions” (#41). My marking a state update as a Transition, you give a hint to React that it might involve a bunch of work. React allows Transitions to be interrupted by more urgent updates, like typing into an input. In the future, we also are considering integrating this concept with animations.

[meganesu]

✨ SERVER COMPONENTS

How do you explain server components? Add your definitions in the replies below.

[gaearon]

Server Components are a new experimental React feature. It likely won't be a part of React 18, but will follow at some point after. We highly recommend watching the intro talk that explains the idea because there's nothing quite like it, so it's hard to compare it with existing things.

Here's how you can think about it. You have a server (where your database might live) and a client (for example, a phone or a computer). The browser runs on the client. Your React app also runs on the client. So your components:

<Panel>
  <SearchField />
  <FriendList />
</Panel>

also run on the client (on a user's phone or computer).

This means that:

1. They don't work until the JavaScript <script /> tag with them finishes loading.
2. If they need to get some data from the server (like the friend list!), you need to write special code for that.

Server Components will allow you to put your components on the server. For example, if <Panel> and <FriendList> components themselves have no event handlers (like click) or state, there's no reason that they must execute on the user's computer. They could execute on the server, just like your API does!

Why is this better?

1. Now the only component in your <script /> tag is SearchField. No need to download the code for Panel or FriendList.
2. Now FriendList doesn't need special code to "fetch" data from the server. It can read data directly because it's already on the server.

So Server Components are a way to:

• Keep some React components on the server so that you don't send their code to the computer (this keeps your bundles smaller and your app faster!)
• Simplify data fetching (instead of a component "fetching" its data in effects, it can read it from the server directly because it is on the server)
• Think of server and client as a single tree instead of two disconnected parts that have to "talk" to each other.

[gaearon]

Maybe this isn’t quite ELI5. But tell me what’s confusing and I can try again.

[ad1992]

✨ HOOKS AND CUSTOM HOOKS

How do you explain hooks and custom hooks? Add your definitions in the replies below.

[shaundai]

There are several different ways to write components, but functional components are awesome because they allow you to do complex calculations and carry logic around in a very easy way. If you want to grab a long .json file with data and then take that data and render it as a table on someone's website for example, you could essentially do all of that with one function. Function components are perfect, but there's one "gotcha": they can't hold state.

Back in the day (before hooks) if you wanted to use state, you'd have to use multiple types of components (class components for anything with state and function components to do something with the information) and it was a lot less clean.

Enter HOOKS. Hooks let you "hook into" React features like state and lifecycle methods so that you can have beautiful and sleek code. Some hooks come "out of the box" (to get and update state, you have useState, or to change things using lifecycle methods you might use useEffect).

[gaearon]

I’d say both “function components” and “functional components” are fine colloquially. We’ve moved from “functional” to “function” when introducing Hooks because we were worried that functional programming purists would make a big deal out of Hooks “not being functional” in the sense of functional programming. (Though they kind of are — but that’s a separate topic.) I woundn’t nitpick on that except in the official docs. Where we’re going to just call them “components” since class components are fading away as a specialised, more legacy, concept.

[chantastic]

OMG. THIS DISCUSSION IS 🔥. Thank you @sylwiavargas!

[shaundai]

Absolutely love this!

[ad1992]

✨ FAST REFRESH

How do you explain hot reloading and fast refresh? Add your definitions in the replies below.

[meganesu]

Took a pass at this in my TIL repo:

Fast Refresh is a React feature that immediately rerenders components when you make changes to your code in an editor (like VS Code). With Fast Refresh, your browser view updates without losing component state, which leads to a better developer experience.

Fast Refresh is a new iteration on hot reloading. Hot reloading was intended to have similar benefits, but it didn't work well with functional components and hooks. It also didn't handle errors well, so you'd have to restart your app after making a typo. Fast Refresh improves on those shortcomings.

[Neha]

✨ APP STATE, COMPONENT STATE, UI STATE

How do you explain state and different types of state? Add your definitions in the replies below.

[gaearon]

Your React components transform information into UI. There are two types of information.

Some of this information never changes during a user session. For example, your website layout, the icons on your buttons, and the order of sections on the page.

Other information may change in response to the user interaction. For example, is a button hovered or not. How many times the user clicked “add”. The content of their shopping cart or a message they were typing.

Information that changes in response to user interactions is called “state”.

Any information has some lifetime. It’s attached to something. For example, regular JS variables are attached to the function calls. They only live for so long as you’re inside this function. When you exit a function, variables from that call stop “existing.” (Aside from closures, which occur when you nest functions, and which let a nested function “keep seeing” variables from the outer function call.)

In React, each time a component renders, it’s a separate function call. So if you tried to store some information like shopping cart content in a regular variable, it would simply disappear on next render. This is why React has a concept of “state variables” you define with useState. They are associated with a place in the tree — like, a particular text input or a shopping cart you see on the screen — rather than with a function call.

Where you declare a state variable matters. Here’s how to think about it. If you render something in two places on the screen, would you want them to be synchronised or not?

For example, rendering two comment fields doesn’t mean that you want one to update when you type in the other one. So it makes sense to place state inside the comment field. Each copy is independent.

But maybe you’re rendering an already submitted comment in two places. If you make an edit to one of them, and save it, it would be reasonable to expect that both of them need to reflect your edit. So the information about a list of comments needs to live somewhere outside your component — maybe, in their shared parent or in some kind of a cache.

This is what people mean by different kinds of state. These aren’t technical terms. But “UI state” usually means some state specific to a concrete UI widget. Like text input’s text. Whereas “app state” usually means some information that’s shared between many components and needs to be in sync. So it’s usually placed outside of them.

[Neha]

✨ RENDERS: RENDERS, RE-RENDERS, WASTEFUL RENDERS?

How do you explain Renders, re-renders, and wasteful renders and their impact on performance? Add your explanation in the replies below.

[gaearon]

When the user does something (like clicking a button), you might want to change what’s on the screen. The way you do it by setting state. In response, React does a “render”.

During a render, React calls the component whose state you set. Your component returns what should be on the screen. Then, React does the same for components below that one (because they might also show something different). This process is called rendering.

This might remind you of top-down planning. A design agency might receive an order. The art director sets a vision and hands off illustration, typography, or logo design, to people specialising in that. They, in turn, might hand off parts of that work to other colleagues. And so on. In the end there is a result composed of different people’s work.

This is similar to how what ends up on the screen is composed of different components’ render results.

Let’s say the design agency client now wants to change something. “Let’s tweak the colors.” So the top-down process starts again. The art director talks to the designer who talks to the person making the sketches, who implements the changes. Then we have a new design.

That’s what a “re-render” is. It’s when you set the state again, React calls your components to figure out what should be on the screen, and then updates the screen. A “re-render” means “rendering again”, nothing more than that.

Finally, a “wasted render” means that a part of the work was unnecessary. For example, if our client says “play with the fonts a bit” and the whole agency starts another round of iterations. But actually only the art director and the font designer needed to be involved. There was no need to involve the person working on the color palette.

In React, this can happen when you update the state of a component that contains many other components. They might not be affected by update, but React still needs to ask each one of them whether they want to display something different. So it’s a “waste” if they don’t end up changing in response.

There are a few common ways to optimize “wasted” renders:

1. You could move state deeper in the tree if it doesn’t affect some components. Then React won’t ask them.
2. You can pass some components “from above” as children to the component whose state is updated. Then React knows those components from “above” don’t care about this state update, and don’t need to change.
3. You could mark some components as “memoized” which means they’ll “remember” their last props and render result. Then, before re-rendering, React will check whether their props have changed. If not, it will skip them while rendering.

PS. I know design agencies don’t necessarily work top-down like this. It’s just a metaphor.

[Ekwuno]

This is a brilliant resource. Thank you so much

[xiaoshude]

I have translated this awesome issue into Chinese, if anyone interested: https://zhuanlan.zhihu.com/p/518841695

[Qodestackr]

✨ useImperativeHandle

---

How do you explain useImperativeHandle?

[MatanBobi]

Same as in OOP, useImperativeHandle helps us in giving the user of a component an API to call functions within that component.
It's an imperative approach to creating a parent->child communication.
If we'll take the most simple example, we have a Form component that renders a few Input components.
The problem starts when the Form component will want to focus on a specific Input (based on some logic, for example: focus on the first Input which isn't populated when the Form renders).
The Input component will need to define an imperative handle (an imperative API) to allow the parent component (Form) to call a focus function on that specific Input. All of this will work based on React's ref mechanism.
I'm not attaching code examples because I think they will only complicate the explanation and might not be "future-proof".

Hope that's clear :)