 Today we are going to look at ReactPoters, a quick show of hands so that I can go to the audience. How many of you already know about Poters? Yeah, Poters? Okay. And how many of you have like tried out hands on there? Like either in Russian or not? Okay, great. So, this is good. Right now, nobody knows. I kind of believe it. So, cool. So, ReactPoters is actually a new feature that has come up in React 16. Even before it came up in React 16, there was a lot of work going on in the community for that. There was a lot of need for it. And what we do today is that we have some code. We'll run the code. We'll see what the need is and how ReactPoters kind of ourselves is. And more importantly than that, there were certain concerns when ReactPoters came, whether it is a good practice to use Poters or not. There was a lot of debate around that. And finally, it emerged out that using Poters actually makes you a good developer. So, let's see how that is. Okay, now I don't know how to move this slide. So, if I go to slideshow, right? So, what is ReactPoters? I'm not really going to slideshow because I have to switch between code and here. So, let's see here. Okay. One example first. And then let's see what exactly is the problem that you are trying to solve. And then we'll get into the definition of Poters. So, I have created some sample applications, very simple React applications. Created using the CLI. And this output is available in GitHub. I'll share the link with you. And you can take a look at it later. The first one and then run it. So, one day my manager came to be and he said, you know, I want you to create a login page for our application. And I thought that's like, you know, a Chutka command. So, I'll just create one login form and I'll show it to you. And he said I want email address, password and things like that. So, I said, yeah, this is what, you know, we have been doing for last 10 years. So, it's not a very big deal. So, let's see if the login page comes up. Oh, yeah. It just comes up. Well, you cannot see the gray part, right? But just as you can, it's a good gray thing. Just for now, is there a change that, let's say, in dark? This is fine, right? Yeah. So, this was how our login box looked like. And I was like very happy. And my app result time was coming up. I was like, you know, I got really impressed. And I said that, you know, you just enter your email address like this and say login, it will just do the thing. And he said, what about login? I said, that is not my content. That is, the backend team will take care of it. I'm going to tell you. I said it is there for you to see. So, let's take a quick look at this code. Just to set the context, right? We have a simple React app. It's an index.html which only has a root here. You can ever see the code here, right? This one just says root. You have the index.js, which is the root of our application. When we say, sorry, just one second. Is the font fine? Yeah. The font says. You can see at the back, right? Yes. Okay. So, we say that, okay, just rendered this application here and a rendered root. The not my application looked like. It requested, it is just one more component as login over here. It looks like this. It's just an email button or that password thing and all. And there is no functionality. It's the simple React application that we have. And I was very happy I read from back. And then, when I written back the next morning, he said, you know what, most of the good sites, they don't show login box like this. They have a login button in the header and when you click on that, you have to show the login box from there. You just don't show your login panel just like that in the home page. So, I said, okay, this will also be fine. So, I just reflected my code and I said, okay, now my app.js, it will look like this. So, it will have a header and a main. In main, I just say, this is awesome home page. And in my header, I put up a login functionality. So, what I do here is, here now, I'm just showing it in app. This is my render method, login button. On click of that, there is going to be some handler which is going to set a state to show the login box or to hide it. And this particular login, it has a show property wherein I'm passing my state and this state is actually manipulated using these methods of show login or cancel login governed by the button. And then there are some stylings over here. I'll just again change that back to dark gray, I think. So, I was very happy with this and then I said, okay, now let's run this one. This is the winter is coming theme of VS code. Okay, so now, okay, this is not showing you. Okay, so this is how my website looks like. This white area below is the main page that we can forget. The green area, I purposefully put it as green so that we can differentiate that. That is my header. Normally, headers are not that big, but just one hour per person. It shows up in the projector. So, now I said, okay, I'll click on the login button and my login dialog should just show up here. I just click on that. So, but now I see, okay, it did show up, but what about the rest of the part? It's just the half of it and the remaining is cut out from there. And that really happened because if I look at my header, if I inspect this scan, I see that there is overflow hidden property over here. And this is a very common problem that a lot of us face, like either in the header or in the site bar, you always want that, okay, this is the area of the parent. None of the child should actually come out from there. Like, you know, this is the restricted area to show any particular deal. And this is the kind of a problem that affects, but let's see how we were actually trying to fix this one early on. The moment I see this, how will you fix it? Yeah, so the thing is, you apply any kind of CSS to this guy, it will not really come out because the parent says over and equal to hidden, right? So you apply any position, it will not really work. So another way is you don't keep it as a child of the header. You say that, okay, now my login box, it will be totally out of my header. And then because it is at the root level of the DOM, it can just show over any of the DOM element. So how we will do that is, we have to not come to the quotas, we are just trying to find a solution for my freedom. So I am going to go back to the third solution. Now, okay, before we look at the code, let's look at what the code is in the solution. So now if I look at my app, the login component over here. So earlier the login component, which was sitting inside header, which was logically correct for me, right? Because I wanted my entire login functionality to be inside my header. But now it says that, okay, now I will have to really sit outside. Before we get into this, let's take a quick look at why the earlier one was a good logical solution for us. Can you see this here? This green box is our header, right? There is a login button and there is a login box over here. How we were showing the login dialog was using a state called as show login, right? Over here. And that is why it was a logical solution for us to put this component inside the header component because now this button and this component, they can kind of share some information using a parent state. Either this is pre-historical in pre-reader's area. So imagine that parent is kind of controlling the state between them. Nowadays we have better state management solutions to this one. Now, let's see if I have to move this out of here. What I'm trying to do now is something like this. I say that, okay, my login button remains into my header area, okay? Like here. This is my main page area. I just put it small. You can see the background, but this much is my login component. Now, if my login button has to tell this guy that, you know, you show what you write, how will it do it? The moment I click on this login button, there will be a show state in my header. This will be set to true. The moment this header gets to know that, okay, this guy is set to true, he will set another status true to his parent, which is my app. Now, the moment this app gets to know that, okay, this is happening. This guy is listening for change events to this state. He will keep figuring out that, okay, so login is true, so I should show. Similarly, the moment I click on the cancel button over here, it will be set to false. This will be set to false, and like everybody will know that the login button is not being shown. The login dialog. And this is the solution that we have currently. If I click on half of it, is there anything? This always happens. Whenever you try to do something good. Okay, let's see. I think I'm still in the second solution area. Okay, so by the time this is running, just run over to the code. This is my header. This is my main. And I said that, okay, my login also is now sitting outside. So the same data flow that I showed you. Header has a login button, which is now coming out here. And now there is this show login box over here at the app level, which has this method for that show login. So now basically your data is moving from one component to its parent to its parent, and then coming to its side to its side. So simply to simply, communication is not really possible. It has to go up the hierarchy and then down the hierarchy. But this is a working solution. So I'm still like, my manager won't really get to know what all this means. He wanted a box, and he's getting a box here now. So now if I look at the inspector, he'll measure this guy. And so this is my login box. So now I click on this login button. And it shows up my login box very well. So now I can move around this entirely anywhere into the page. Because it is sitting at a root level. It doesn't really matter where it is. So now we have a working solution. And this is how we have been working actually. But is this really clean for us? The problem that we'll have is other than my application logic, like my application complexity keeps growing, these kinds of situations are going to be difficult for me for the maintenance of the product. I cannot have one component talking to another one through its parent, through its parent, and then side to side there. So the solution that React Portal says is when this guy wants to show something like this login box, somewhere else in the div, like in this case we wanted to show it in the root, not under the header. Logically, this guy should still be a child of header because that is how we wanted it to be. We wanted login box to be a child of header so that all the data between the button and this box remains under the header. But physically, like presentation wise, I want this one to be displayed somewhere else. And this is the concept of Portal where if they say that you want to show a component, you tell us, you want to show the component and we will show it over there. Imagine it like those movies where recently there was this Superman, Thor movie was there, right? So they open a portal and they can go from anywhere to anywhere. It's like that. Also logic is over there, but it can just appear anywhere, like that. So let's look at the code for how Portal really solves our problem and we extend some time into this code to understand what Portal is doing. The problem is clear, right? Everybody is like, what is the problem they are trying to solve? Website wise, let me look at this website. Now this is the new Portal's code. I will look at the code, how it is doing. Now when I click on login, this is few showing up here. And everything is fine. It's the exact same representation as it was before. Now, but let's look at it from the code side. So now when I look at my app, now you see there is a header, there is a main, but there is no more a login component over here. But what we have done here is we have opened a portal. Right, not a portal, sorry. We have just kept a deep over here, which we are saying that this is the kind of a placeholder where we would want to show my login dialog. So we have just kept a deep, like a placeholder deep, like a container deep over here. And now let's go back to our header component and here you will see that it is back to where it was before. So you have a login button and now your login component is actually inside my header again. So logically again these guys are sitting together. They can again change data within themselves. They don't really have to involve the app to decide whether to show the login dialog or not. And one more component that we have added here is the model. Let's see what exactly is the model. In this way we are actually using our portal's code. So model says, if we don't have to show, then don't show anything. But if we have to show, then this is my render method. There is a deep, like this. And whatever is the child of that model, whatever are the children's properties, just show it like that. So he is not really adding anything extra. He is just saying I am a transparent container. This is my children. I am just going to show it like that. And if you see, this is not just a written statement. This is saying, return reactdom.createPortal. Just like you have createElement in reactdom, you have createPortal here. So when you say createPortal, you can specify what do you want to show, what is the react element that you want to show and where do you want to show. This is the important part. So here we are saying that I want to show this. I want to show this model component. But I don't want to show it there where it has been defined. I want to show it in the div element with the id as modal. And if you see this one again, our index element has a div as modal. So we are saying that, whenever somebody wants to render the modal component, irrespective of wherever it has been called from, it should always look for this particular id and show it over here. So logically, it will still be under that. But representation wise, it will be under here. When I say logically there and physically here, let's see what does it mean really. Let's run this code. I think it's running. Now let's inspect this there. This is my element part. This one has the react, this one has the header. Now this is where my modal is. And this one has the login box inside that. That means my modal is actually sitting as a sibling of my header and this one. So although I had defined it to be inside header, like if I look at my header.js, I had defined my modal to be inside my header, but now it has been rendered outside of the header into a div where I wanted it to be. And this gives me a lot of flexibility of adding whatever styling I wanted to be, right? Like I can give whatever position absolute, like other things to this guy. But now look at one more thing. If you have the react tool in Chrome, here you will see... This is a modal. Why is it a modal? The event switch is a direct switch. Change it directly to 0. Did I add anything to this one? We already added. I didn't add anything. Give a C. Okay, so now we are running this code. No, you are still in 3. No, now we are getting code. No. So now let's see if I run this guy. This is the code type we are running. So now if I say refresh this guy, and let's look at what react shows things. Here it is not C. CD, CD, CD. I got basic problems with the problem. If you are covering the advanced topic here. Okay, so this one, right? Okay, so now let's see if this one shows up. Here if you see, now my app has only header and main. My header has modal. And as of now it is empty. If I click on the login box, modal gets a login inside that. So this is the duty of a portal. That it shows up somewhere else, but logically react element-wise it is still under here. So now if I look at this element again, the login box is actually outside. Okay, so now let's see how this one shows up like. It really looks like this. So now we are kind of back to what we were before. There is a login button. There is a login box. Which we are saying that, okay, show it in a modal box. And that modal is something that we want to show it in a portal. So they are all interacting using this state of the parent itself. And they don't really have to go out of the headers from here. So now let's take up a little bit of a complex scenario. Let's take up a scenario like this. Now why we are taking this right now is to see how we can pass on data between various components in portals. So I have the login button, which is setting the show login state here. Depending on that, my login box will show that we currently have. What we are doing is now to add some extra complexity. They are saying, okay, whatever email address I add here, and if I say login, this guy is going to set another property, another property called an email inside my parent here. And this should show up in my button over here, this value. So that we know that, okay, I am able to kind of see this value over here. Now if I click on this button, I should be able to open another dialogue over here inside this same model, which will kind of show me the user profile. In this case, consider only the email address of the profile and the close button. So let's see how this code looks like. I was just testing whether you are paying attention or not. You will get one cupcake. This app, same as before. Nothing has changed. There is still a single GIF to hold the model. Head up, now it looks like this. So I am going nearer and nearer to a better app result. At least 20% increment is same. So my header shows there is a model component. Earlier it had only a login, but now it also has a profile. And we will not pay into the details of it. We are like regular data jumping in components, between one component and another. So email, based upon whatever has been passed. So email is passed as a property by the parent and it will show it up over there. So let's see how this one runs. And login. And if I click on login, so now let's say if I say a and b dot c, it shows the email address over here now. It was not there before. This button is showing me the user profile in a separate dialogue. Separate model. Now even without leaving my parent area, within the same react limit, I can kind of pass data around over here. So you see the GIF with model and lighting. You see the actual rendering has happened over here. But again if I go to header, so header, model, login. Let's take it to another extreme. So we know all the data has been passed within a react application. It was all different components, but it was all within the same application. Now let's try to solve something which was kind of not possible before. We will try to show something out of the react application. So now I should add a default command in my terminal. If I don't say cd, you should just check it out. Here now if I go to the sixth one, this is the last sixth one in our case. After I will go to all the fundamentals. Take a GAN model. Here now if you look at the source, this is a very simple one. Now our index HTML itself will be changing. Earlier our index had one react create element which was showing just the app. Now if you see, this is how my new index.estimal looks like. So this one has basically two groups. One is this div which says plain HTML and there is another group of div which says profile. So what basically we are trying to do is only this profile will be managed by react. This will be kind of outside the jurisdiction of react and it's like a plain HTML in our page. Can this kind of a case be handled? So basically what I'm trying to do is I am sitting under the react application from inside this profile. Can I show something in the div login over here which says outside react. So let's look at my index.js. So if you see index.js now very specifically says that show profile in the div with the ideas profile. So the plain HTML is actually out of react 7 rule and it is only the lower one which is there. And how does my profile look like? Profile says there will be a label, whatever, with that email ID that I have passed. Then there will be a button which says login. Under that I am saying create portal. This portal will be executed when I click on that button because I am using the same state between them as the show login. Then show login is true. At that time this login will show up. But where will this login show? It will not show under profile. It will try to show under a new portal which we are trying to display in the login ID which is actually out of my react control. So now if I run this guy, it's too much of... So this is how my application looks like. This is the profile guy and this yellow region that you see this is outside of react application. This is that plain HTML div. Now if I click on here I see that the login button shows up over here, the login arrow. So this is another beauty of portals that if you click on here, you can actually show your portal anywhere else. And I will actually share a link with you. Somebody has taken a step even beyond this. They are saying that if I click on button over here you can actually open a new browser tab and show your login div over there itself. So you don't even have to be in the same login like same browser tab. And this is kind of something that gives you enormous power as to where do you want to show your divs and still you are still taking care of your application complexity because logically they are still under the hierarchy of the react element that you wanted it to be. So now let's see where do we use portals? A quick tip on time. So first of all we saw the case where it is actually useful whenever there is override equal to hidden or wherever you are using zindex or position equal to absolute fixed amount these are the places where your CSS is not really helping you out and you really want to show your component somewhere else in the div hierarchy. That is where it is very much useful. There are basically two cases. One is always on top, like a light box. Oh this is also not right. Gray in colour. So you will have seen the light boxes in your websites. Like suddenly I am looking at a blog and suddenly it just blocks everything and says that we want to subscribe to email. And then you have to look for the close button. So that is a light box. It just shows everything and shows everything on top of it. Unless you say yes you cannot do anything. And then the second one is you are showing it as part of a parent but your parent is not here really trying, allowing you to come out of it. And you are basically bigger than your parent. So you want to show it up over there. So now let's run first. Zindex complexity and then using portals. Because we saw that from portals from one place I can show the UI somewhere else and from there I can show it somewhere else. So a lot of people started looking at this as very similar to the go-to statement in C. If you know like in C there was a provision that I am in inside my function suddenly I say go to level 1 and level 1 is somewhere inside another function. And I can continue from there and I can jump back here and there. This one came up because in assembly this is how assembly codes are written. But in a higher level languages we need a better control of the code flow because majority of our time is actually spent debugging our code. Like the code maintainability is an issue for us. So a good design says that you should have a good structured code and go-to statements are considered evil. They are like more of a subsidiary. So another thing is when you go from portal to portal to portal. I open one portal from there you say open another portal and another portal. Like how do we take care of this? But then if you look at it closely it actually is like this. Initially when there is no portal use your react element and your DOM they go kind of hand-in-hand. So you have component 1, 2, 3, 4 and they represent leave 1, leave 2, leave 3, leave 4. And then and this was how it looked like. Now you can see so forget it. It's like this where we wanted to show the portal. Again you cannot see the code but this is how it looked like. So your JSX still remain very structured but the actual representation of DOM was this component was now actually rendered not under orange but outside of orange. So I could have just decided to show it anywhere else. Similarly in a case like this I actually showed it out of the React app itself. So consider this blue box as a React app. Your JSX is still very structured but your actual representation here is going to show out of the React app. And this is the way you do whatever strategy you want here whatever way you want to represent your UI your actual conceptualized React element like you know the way you are designing your system if that is clean enough then your code is actually maintainable. But I'll give you one hint that when you are testing using enzyme there are two methods mount and shallow. Mount basically a DOM, shallow is a component. And as you see that the portal they deal more with the React element side the component side and not really with the DOM so try to use shallow and you should be able to test it the same way as you do your other components. State management remains pretty much the same as you would do anything else because although you are showing it somewhere else they are still pretty much the child of your React elements and you can test them the way you want. A few of the questions like you know while you are designing your portals don't think about the UI how it looks like but think about conceptually how components react with each other how components you know behave like the way you think about classes how classes behave or how the relationship between two classes are that is how we should try to design our React components if you do that it doesn't really matter whether you are showing a child inside a parent or outside of a parent. And this was the first step I was talking about you can take a look at that thing write it down quickly. Okay, so that's it. This is the URF, you'll get it, built-in React portals that is where the sample ports are if you just want to try your hands off. And it's a very simple concept but a very good and a very innovative thing because it kind of forces us to think in terms of good designs irrespective of the representation of our React component. Yeah, I can just in time.