All language subtitles for 005 Introducing React Portals_en

Fragments allow us to write cleaner code,

to end up with less unnecessary HTML elements

on the final page.

And that's great.

React portals are another useful feature,

which do something similar,

which also help us write cleaner code.

Consider this made up example here.

We got two elements, two components side by side,

MyModal and MyInputForm, wrapped by a Fragment.

But the Fragment won't matter here.

We already learned about that.

And the actual content, that ends up

in the real DOM, might look something like this.

We might have a section and h2 tag,

coming from some other components,

because the code on the left,

is just one of many components

in our application, let's say.

And then we have that brown content,

which is actually the modal,

which is being rendered to the DOM

in the end by React.

And the orange part is our form.

Now what's wrong with that?

Technically nothing, technically this is fine,

but there is something in this code,

which is not ideal.

And that would be that modal.

This modal code, which is being rendered here

in the DOM, will technically work.

As long as you apply the correct styling,

it will look like a modal.

As you also saw in that demo project we worked on.

But semantically and from a,

have a clean HTML structure perspective,

this is not ideal.

Why?

Because you have to keep in mind,

that a modal basically is an overlay

on your page.

It is an overlay to the entire page.

So logically, it's above everything else.

And if it's then nested in some other HTML code,

it might technically work because of styling,

but it's not good code.

It's not a good structure.

And it can even lead to real problems again,

with styling, or with accessibility,

if you have such nested overlay content,

because if, for example, a screen reader

has to interpret your HTML code,

which is being rendered,

it might not see this as a general overlay,

because you are CSS styling won't matter too much there.

And from a semantical perspective,

from the structure it has,

it's deeply structured in our HTML code.

So it's not obvious that this modal

should be an overlay to all the other content.

And that's not just a case for modals,

you would have similar problems for side drawers,

for dialogues, so typically for all kinds

of overlays or any related components.

It's a little bit as if you would create a button,

by simply styling a div like a button

and adding an event listener.

It will work technically, but it's not a good practice.

It's bad for accessibility.

It's bad if a fellow developer has to

work with that, it's simply not a good idea.

In web development in general,

with HTML and CSS and Java script,

because it's so forgiving, you can make a lot

of things work, but that doesn't mean

that just because it works,

it's also a good implementation.

It's also a good idea to use it like this.

And that's where we can use another React concept,

to get rid of this problem with this modal,

with this overlay content,

which shouldn't be deeply nested.

We can use a portal to keep

the structure we have on the left,

so to keep writing our components the way

we want to write them, so that we have

no friction when we wanna pass data around

and so on.

But to still render this differently

in the real DOM and to, for example,

render the modal HTML content somewhere else,

than it would normally go to.

So that on the left, the J as X code rewrite

hasn't changed, but the rendered HTML code

is a bit different from our J as X code.

So the modal there is not next to the forum.

And you can achieve this with React portals

So let's see how portals work.