So what we did already is create here this GetRenderableDidum function that comes from the index and within here, we are calling it. And what we get here will basically be, the idea is components are not really something that we know how to render within the DOM. So they're not very important for DOM handlers, but for our react function, right in the long run, they are quite important because we need to know how to render them. So we decided that within this file, we would only have things that we know how to handle within the DOM. And on the other side, we can handle things that are more react specific like components. And let's go to our other index, to our index, sorry, not other index, that's the only index. And so we have our GetRendableVDom function, which is here, and we are talking about VDom here, and I will introduce that in a second. But first, I think we can look at how our render works. So renderer works pretty much similar to the other side, right? We have a similar function here that handles primitives and other components differently. And for primitives, it doesn't do much. It pretty much, okay, I will walk you through what all of this does in a minute, but it pretty much just returns the primitives because we don't have to do anything on them. And for our component elements, it is extracting the children and props, and in case we do have children, there is the extra step here of checking whether the children are an array or not, and if they're not an array, for convenience, transforming them into an array, and then mapping through them and also rendering, and then returning the children as the result of rendering them within this file. And then here would be where we will have to handle the components, so in case our type is a function, that means we are trying to render a functional component. So we are putting the type into this functional component, and here now, we'll have to actually render this, and we talked quite a bit about the vdum. So let's talk about the vdum. So the vdum ideas is to have a representation of the current tree that we have in React in a way that we can store it in memory, and we can have easy access to different components within it. And the reason, or some of the reasons why we would want that, one of them is later on when we try to introduce the hooks, then we'll have to know which component a hook belongs to. So we'll have to have some kind of representation of vertical, and over time, as we re-render, we will need to know, you know, like the previous state of this component was this. So when we re-render, we have to have the state again. And once we also get into diffing and targeted updates, at that point you will have the similar importance where we can compare the current one to the previous one so that we can actually understand what has changed over time. So let's think a bit about what that can look like. If we imagine an HTML page, something like this, where we have a main div contains as a first child, another div then this div contains as a child, a span, and this says, hello world! And the core div, the main div, root div also contains another child, which says another span. And we try to think about how we can identify all of those and the way React actually does it is based on where they are within the tree, right? So it's all based on their position in the tree. So one way we can represent this structure in a tree-like structure could be something like this. We have our top div, it has two children, and the first child is also a div which also has a child, which is span, which also has a child, which is a text, and the root div has a second child, which is span, which has a child, which is a text. Now, if we think of it like this, we could use their index within each of their children array to understand where they fall and use that to identify them. So if I take the same version but annotated, this top div is the root, right? So it doesn't really need like this ID and it is like basically root, and then within it, there are two children, and the first one could get the ID zero. So that's the children at index zero, and this one could get the ID one. That's the children at ID one, and then we do the same thing as we go down, but we just append to the already existing pointer as we go. So this is the first child of this div, and as it's also a child of this div, it will start with zero to identify this div, then a comma, and then within this div, it's the first child, and this one is the first child of this one. So it inherits basically the whole structure that went before it and then adds a comma zero, and on the other side, this is the second child. So that's index one and its child would be one comma zero because that's the index zero within this one. All right. That's not it. Yeah, okay. And the next thing we need to think of, right, which we already started talking about is some of the things are not actually rendering in the final browser DOM, but they're only important for our vDOM, and most of what this is are components. So if we imagine now this JSX, it has a div, a h1, then a section, and then a component here. But this wouldn't be valid in HTML, right? It only works in JSX slash React. But still, let's continue with this example. And let's imagine that our counter looks something like this. So it's a component that has a state, starts at zero, which is a count, and then it renders a div, a span that says the count is the count that is here, and a button that just increments the count if you click it, that has plus as a text. So that knowing this, we can guess that for the first render, this will be the structure that we have at the end in HTML within the browser. And in this case, right, the counter is not here anymore, but instead has been replaced by our div, which is rendered by our counter. So when we talk about the renderable VDOM, we are imagining this, right? Like without components.