React Interview Questions Senior Level (React Fiber, Reconciliation, Virtual DOM)

so today we will answer some of the hardest senior react interview questions our m is cut in real frontend interviews we are going to Deep dive into Concepts such as concurrent react react fiber the reconciliation process and the virtual Dome Bon is going to answer the interview questions but also give you the mental models and the reasons why behind his explanations Bon are you ready yes let's go and let's go with the first question what is react fiber and how is it different from the virtual Dom perfect so I'm going to go ahead and share

my screen for this one uh what is react fiber and how is it different from the vual Dom well to put this simply back in the days we had our react elements that would create a virtual Dome node and then that will be translated into an actual Dome node with reconciliation but the problem with this is that it's a very synchronous process that means imagine we have a huge of elements we need to render all those like comput the state and with jsx compute the vual D node all done singly in one shot and then

render the D and what react introduced in uh version 16 with react synchronous is the fiber node which is an intermediate structure that gets created and basically all the work of rendering component is done by fiber by this fiber node so just like you had a threee of visual Dom nodes now you have a fiber tree whenever we need to reender we work on this tree we compute the new state we run certain life cycle methods and once we are done we can then compute the V D from the fiber tree and the big advantage

of having this structure and the why behind it is that differently from the virtual node and traditional rendering the fiber reconciliation can be paused so we can actually pause you know when we go into the fiber and we have a higher priority update we could actually pause this do something else and then come back to this and that was not possible before for fiber so that would be the big difference where the visual Dome is only used now to actually compute the differences to the Dome and the fiber it's a new intermediate structure that allows

us to pause and prioritize the render process to make it asynchronous or what they call concurent react cool Bon um this leads me to our second question today which is can you explain the reconciliation process in react and also if you can tell me what does the introduction of react fiber mean means for the reconciliation process as well so in the reconciliation in traditional reconciliation we had our component it will trigger a state change and that will trigger a reender of the component three and rendering means we would go from the root node the root

component all the way to the children all the way to what we call the leaf noes the very bottom components and run the render function recursively and we would put that in the call stack so all these things will be into the call stack all the way to the bottom then we will would execute them and finally from that we would extract the new virtual Dom that's what they call the stack Recon shizer and this one it's kind of synchronous in the sense of imagine we have a huge component Tre we would need to put

recursively all those render functions in here finish them and then finally render when we have a huge component threee you might have what we call a blocking UI imagine we're fetching some data and rendering things on the screen if you are completing a form at the same time as a user you would perceive that form as non-responsive Ive because the cold stack is busy by rendering this components that are being fetched and so we can't really reender for example the UI the browser cannot repaint so maybe you're typing in an input field but you don't

see anything happening so that was kind of the old reconation process and after that we had our vome we would make our diffing algorithm and finally commit to the Dome the changes needed that was uh how react used to work with fiber things are a bit more complex so what react does is from the component tree it will build what we call fiber tree and a fiber is nothing but let me zoom in I think I have a fiber around here it's a JavaScript object and inside there's many properties but probably the most important are

the state and the new props right the props the component has the memorized props everything you need about the component the function that runs it the siblings and the child are all here and so react will create a fiber tree with this internally right and it will run the render function for all the for that fiber tree and from it it will deduct the virual D and then the process is just like before the virual do gets compared with our ding algorithm and we commit changes to the do so far nothing changed but we have

this intermediate step nice now what I still don't understand B is right now we have the fiber tree right as a in in between the ritual Dome and the state changes and I'm wondering why why the fiber why do I need fiber in the first place right because it adds extra complexity and I'm wondering what does fiber allows me to do that the vual Dom couldn't you you mentioned this a synchronous rendering right could you expand a bit on that because it feels to me like it's it's adding a lot of complexity react was already

complex the diffing algorithm was already complex and now we have a stage in between that's kind of definitely adding another layer of abstraction of complexity um is it white it do we really need why and why do we really need this step this 5 by3 yeah very very good question so what the f by3 allows us to do is that it works together with a priority queue and a scheduler and rather than having this process synchronous like we really like as I explained before about the the stack reconciliatory we would go like have to run

the whole render in one shot we can actually pause we can actually stop at a certain node pause and do something else and then come back to this render the way that's done and I'm going to try to explain it really quickly is that whenever a an update um let's say imagine a set State happens an update gets attached to this 5 by3 so let's imagine there's a state change here for this form component there is an update queue for this form component and that change that will be cued there and what react will do

after that is to copy the current fiber tree in the background and do work on it that means just go through each node and see if there's any update and compute the new memo State and run the render method but it does all this in the background and so that means while react does all this right imagine we have a huge component um it can actually it does it asynchronously it doesn't take all the main thread to do this basically what react does is it goes to our main thread to the web browser and calls

this function which is uh I do not have it here but it's called request eedle call back which basically it tells the browser hey um do you have some free time are you eidle and the browser says yes I am eidle and I will let you do some work for around 50 milliseconds that's the default in the browser and then react goes and starts doing this work right tick tick TI it doesn't need to finish yeah it will just do some work when react finished the the frame budget we call it that way like the

browser says okay you've done enough but now I need to free the main thread to repaint or reender the UI then rect will pause everything and this was impossible before you really needed to finish the render before doing anything else one follow-up question that comes to my mind is how can we manage all this in memory I mean how can we prevent memory leaks the whole fiber Tre will basically stay somewhere in memory and we're kind of adding changes to those and how can we make sure nothing nothing goes wrong so what Rea does really

well is to reuse a lot of the fiberry so you see when we create this new working prog that we are rendering um a lot of these nodes are copied especially if react see that they didn't change so if imagine one of those fiber uses the use memo hook or the react. memo and the props didn't change react will not reender it will just maintain a reference to the previous one so it's very optimized and it tries to reuse as much as possible of the previous fiber Tre mhm understood understood so it's it's kind of

prepared for that to be as if ient as possible and and not not use too many resources you mentioned a high priority update how how does that work what what do you mean by that what I mean is that imagine we are fetching some data and rendering a huge list of elements that would be a low priority update because it's it's nothing that we need to instantaneously show to the user whereas whenever the user is typing something on an input field and we want to show a focus or an outline on that input field or

even an error message we want to react to user input input then yes that will be a much higher priority update so react will pause this low priority render it will create a new working progress three for the high priority um update finish that one commit like compute the virtual Dome and commit the changes to the Dom and then go back to the low priority update that's why it's called concurrent react or synchronous react because you can actually use a priority queue to under the hood prioritize those updates so for the end user even if

we're doing a lot of background work the UI feels a lot more fluid here's basically the list of internal priorities that the react developers added to the framework the top priority would be a discret event like if they click or they type on an import the second one would be if they scroll and we need to show something on screen because the user scrolled a normal priority would be something like data Fetch and a very low priority would be a route change for example and all this is internal to the react codebase we don't need

to worry about it but it's important for us to know that this is how react handles now um reenders in updates that's quite a bit of complexity out would say for the average react developer and I have a follow-up question prepared uh but first let's answer the third question that I had uh prepared here which is what can you tell me about the diffing algorithm and the virtual D so as I mentioned this render process it's it can be paused and as synchronous but whenever we finish this we have a synchronous phase which is the

commit phase which is I know what Chang I need to do and now I'm going to commit them to push them to the actual Dom so what we do is once we have each fiber tree um finished and we have the memory State we can compute the Von the new virtual Dome this didn't change much with previous react we will compare the vome the new one with the current fatal Dome and try to figure out the differences now traditionally comparing to trees like that would take I think the big o for this would be n

to the thir so n n by n by n n being the number of elements so imagine we have a thousand elements it will take a billion operations to actually compare those threes wow so yeah so react has two her istics uh which is it basically assumes that if the type of an element change so if this form is not a form anymore then it will discard all the children and try to recompute that so because that's a lot cheaper like rendering that from scratch is a lot cheaper than comparing everything so that's the first

one which is you know if different type then redo and the second one is assume key are stable uh I'll get in a second into keys they they're stable and unique so whenever we have a list of elements we react will ask for that key prop and it will use that to actually really fast compare those elements if our keys has are not stable that means they change values all the time we're pushing a lot of new work um and if they're not unique react won't be really able to use them because it really tries

to identify a leaf tree with a key so imagine here we' have um 15 inputs it would use that key to differentiate which ones do I need to reender which ones I don't have this is why for example you should never use array indexes as keys in a component because they're not stable right exactly because if you delete an element in in position five of the array all the others will shift and all of a sudden maybe react doesn't reender element number six even if the actual content or the underlying state has changed so these

are the tra of her istic and you need to know this as a developer in order to really avoid having weird issues so of course I have a followup question prepared for that but I just wanted to take a break and for everyone watching last you're probably watching this video because you interviewing right now and I guess you are a JavaScript engineer whether it's know front end with react or frontend general full stack even backend develop right now then we have a present for you so we prepared a free technal assessment for you to understand

what your technal gaps are and to also adjust your interviewing process and try to fix those gaps for you to perform in your next teal interview it's available for free in the comments the link is going to be there and you can go to the C website and take it um and I wish you the best of luck we that being said my my you know my big question right now B is after seeing all this stuff I mean react was already you know the learning curve was quite Steep and the framework itself is BEC

becoming pretty complex I mean you you spent a few hours to have this kind of thinkal depth this knowledge is also not readily available online so you have to kind of dig deeper into the the source code the documentation so my the million dollar question is much how deep should a the average you know re developer go how much should a mid level developer know how much should I react engineer know I guess to answer that it very much depends of what kind of developer you are if you are a senior full stack developer a

bit more spread out you cannot really spend so much time in react and so I would just learn maybe the motivation of the reac team behind it and a top level API but if you are a senior react developer what we have seen in the market is that it did became a bit more overcrowed than it used to be and so this level of technical depth I'll talk daunting it will get help you stand out in in the uh in an already overcrowed market and the good news I have for everybody else is that the

data structures that are being used like qes and priority hips and trees they will develop your thinking model and your language and so you don't really lose by going this deep if you're a senior react developer I think you will have to go pretty deep into it because this is your thing you are a senior react developer if you're a senior frent developer also but if you're a senior for stack I would just look at the top level ideas behind it and try to understand the motivation of the reacting behind it you will not have

to interact with the fiber directly at any point as a developer so there's no need to go too deep into it and if you're a react developer trying to deepen your knowledge in about react internal staring to learn more about fiber 3 where would you start I would start with the browser apis there are two main functions that they built concurent react around which is request e callback which is hey the browser is free and says you can give me some work to do I will do it in the background and that's when react starts

rendering and I think the other one was request animation frame which is the browser saying I'm going to repaint and rerender the UI is there anything really quickly that you want me to do before and that's when react commits changes to the Dom high priority changes so you see them in the next refresh in the next repaint if you learn those first of all you can use them in other Frameworks and then you'll realize that everything they built into fiber was to be able to use these apis in a concurrent mode and that's why they

added a priority cue to it and and the whole fiber thing so I would start there which is why folks and for the people watching us you will see this across the whole sentive Channel and across everything we do but fundamentals are the way to go right because as you can see whatever Frameworks are trying to build upon it's always upon basic browser functionality and JavaScript fundamentals right uh we talked about basic data structures without we about the call stack and as you can see when Bon was actually explaining and going through the fiber explanations

he did a a complexity analysis he was always referring to data structures that are agnostic and to JavaScript characteristics that are built into the language so if you're really funny enough if you really want to master the advanced features of a framework like react you actually need to master and strengthen your fundamentals first if you're interested into strengthening your fundamentals then you're in the right place make sure you subscribe to the channel let us know in the comments if there's any other advanc re question senior level question that you want b i to cover or

if there's anything in this video that you want us to go deeper in into and we expect a lot more videos like this coming your way ban thank you so much and we will see you folks in the next one