跟讀練習: React Interview Questions Senior Level (React Fiber, Reconciliation, Virtual DOM) - 通過影片學習英語口語

選擇練習模式

每種模式都會開啟全屏練習室。

253 句

如果句子過短或過長，請點選 Edit 進行調整。

So today we will answer some of the hardest senior

React interview questions our M &T's got in real front -end interviews.

We are going to deep dive into concepts such as concurrent

React, React Fiber, the reconciliation process, and the virtual DOM.

Bogdan is going to answer the interview questions, but also give you the mental models and the reasons why behind his explanations.

Bogdan, 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.

What is React Fiber and how is it different from the virtual DOM?

Well, to put this simply, back in the days we had our React elements

that would create a virtual DOM node and then that will be translated into an actual DOM node with reconciliation.

But the problem with this is that it's a very synchronous process.

That means imagine we have a huge tree of elements.

We need to render all of those.

I compute the state

and with JSX compute the virtual DOM node all done synchrously in one shot and then render the DOM.

And what React introduced in version 16 with React asynchronous 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 tree of virtual DOM nodes, now you have a fiber tree.

Whenever we need to re -render, we work on this tree, we compute the new state, we run certain lifecycle methods.

And once we are done, we can then compute the virtual DOM 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 fiber.

So that would be the big difference where the virtual DOM, it's only used now to actually compute the differences to the DOM.

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 concurrent React.

Cool, Bogdan.

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 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 re -render of the component re.

And re -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 nodes, 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 would execute them.

And finally, from that, we would extract the new virtual DOM.

That's what they call the stack reconciler.

And this one, it's kind of synchronous in the sense of, imagine we have a huge component tree,

we would need to put recursively all those render functions in here, finish them, and then finally render.

When we have a huge component tree, 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 because the call stack is busy by rendering these components that are being fetched.

And so we can't really re -render, 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 reconciliation process.

And after that, we had our VDome.

We would make our diffing algorithm and finally commit to the DOM, the changes needed.

That was 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 a fiber tree.

And a fiber, it's 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, like 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.

And it will run the render function for that fiber tree.

And from it, it will deduct the virtual DOM.

And then the process is just like before.

The virtual DOM gets compared with our diffing algorithm and we commit changes to the DOM.

So far, nothing changed, but we have this intermediate step.

Nice.

Now, what I still don't understand by the minute, right now we have the fiber tree, right?

As a, in between the virtual DOM and the state changes the plate.

And I'm wondering...

Why the fiber tree?

Why do I need fiber in the first place?

Because it adds extra complexity.

And I'm wondering, what does fiber allows me to do that the virtual DOM couldn't?

You mentioned this asynchronous rendering.

Could you expand a bit on that?

Because it feels to me like 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.

Is it worth it?

Do we really need why? and why do we really need this step, this fiber tree?

Yeah, very good question.

So what the fiber tree 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, as I explained before about the stack reconcilator,

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 an update, let's say, imagine a set state happens,

an update gets attached to this fiber tree.

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 queued 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 updates and compute the new memoized state and run the render method.

But it does all this in the background.

100

And so that means while React does all this, right?

101

Imagine we have a huge component tree.

102

It can actually, it does it asynchronously.

103

It doesn't take all the main thread to do this.

104

Basically, what React does, it goes to our main thread, to the web browser, and calls this function, which is, I do not have it here,

105

but it's called the request idle callback, which basically, it tells the browser, hey, do you have some free time?

106

Are you idle?

107

And the browser says, yes, I am idle, and I will let you do some work for around 50 milliseconds.

108

That's the default in the browser.

109

And then React goes and starts doing this work, right?

110

Ticker, ticker, ticker it doesn't need to finish.

111

It will just do some work.

112

When React finished the frame budget, we call it that way, like the browser says, okay,

113

you've done enough, but now I need to free the main thread to repaint or re -render the UI, then React will pause everything.

114

And this was impossible before.

115

You really needed to finish the render before doing anything else.

116

One follow -up question that comes to my mind is, how can we manage all this in memory?

117

I mean, how can we prevent memory leaks? the whole fiber tree will basically stay somewhere in memory

118

and we're kind of adding changes to those

119

and how can we make sure nothing nothing goes wrong

120

so what react does really well is to reuse a lot of the fiber tree

121

so you see when we create this new work in progress

122

that we're rendering a lot of these nodes are copied especially

123

if react see that they didn't change so

124

if imagine one of those fiber uses the use memo hook or the react .memo and the props didn't change, React will not re -render.

125

It will just maintain a reference to the previous one.

126

So it's very optimized and it tries to use as much as possible of the previous fiber tree.

127

Understood.

128

So it's kind of prepared for that to be as efficient as possible and not use too many resources.

129

You mentioned a high priority update.

130

How does that work?

131

What do you mean by that?

132

What I mean is that imagine we are fetching some data

133

and rendering a huge list of elements that would be a low priority update

134

because it's nothing that we need to instantaneously show to the user.

135

Whereas whenever the user is typing something on an input field

136

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,

137

then yes, that would be a much higher priority update.

138

So React will pause this low priority render, it will create a new work in progress tree for the high priority update,

139

finish that one, commit, like compute the virtual DOM and commit the changes to the DOM and then go back to the low priority update.

140

That's why it's called concurrent react or synchronous react

141

because you can actually use a priority queue to under the hood prioritize those updates.

142

So for the end user, even if we're doing a lot of background work, the UI feels a lot more fluid.

143

Here's basically the list of internal priorities that the React developers added to the framework.

144

The top priority would be a discrete event, like if they click or they type on an input.

145

The second one would be they scroll, and we need to show something on screen because the user scrolled.

146

A normal priority would be something like data fetch, and a very low priority would be a route change, for example.

147

And all this is internal to the React code base.

148

We don't need to worry about it.

149

But it's important for us to know that this is how

150

React handles now.

151

Again, re -renders in updates.

152

And so that's quite a bit of complexity, I would say, for the average React developer.

153

And I have a follow -up question prepared.

154

But first, let's answer the third question that I have prepared here,

155

which is, what can you tell me about the diffing algorithm and the virtual DOM?

156

So as I mentioned, this render process, it can be paused and asynchronous.

157

But whenever we finish this, we have a synchronous phase, which is the commit phase, which is I know what changes I need to do.

158

And now I'm going to commit them to push them to the actual DOM.

159

So what we do is once we have each fiber tree finished and we have the memory state,

160

we can compute the VDOM, the new virtual DOM.

161

This didn't change much with previous React we will compare the VDome,

162

the new one, with the current feature DOM and try to figure out the differences.

163

Now, traditionally, comparing two trees like that would take, I think the big O for this would be N to the third.

164

So N by N by N, N being the number of elements.

165

So imagine we have a thousand elements.

166

It would take a billion operations to actually compare those trees.

167

Wow. So, yeah.

168

So React has two heuristics, which is it basically assumes that if the type of an element change,

169

so if this form is not a form anymore, then it will discard all the children and try to recompute that.

170

So because that's a lot cheaper, like re -rending that from scratch, it's a lot cheaper than comparing everything.

171

So that's the first one, which is, you know, if different type, then redo.

172

And the second one is assume keys are stable.

173

I'll get in a second into keys.

174

They're stable and unique.

175

So whenever we have a list of elements, we react will ask for that key prop.

176

And it will use that to actually really fast compare those elements.

177

If our keys are not stable, that means they change values all the time.

178

We're pushing a lot of new work.

179

And if they're not unique, react won't be really able to use them

180

because it really tries to identify a leaf tree with the key

181

so imagine here we'd have um 15 inputs it would use

182

that key to differentiate which ones do i need to render

183

which ones i don't have this is why for example

184

you should never use array indexes as keys in a real component because they're not stable right exactly because if you

185

You would delete an element in position five of the array.

186

All the others will shift.

187

And all of a sudden, maybe React doesn't render element number six, even if the actual content or the underlying state has changed.

188

So this is a trail of heuristic.

189

And you need to know this as a developer in order to really avoid having weird issues.

190

So, of course, I have a follow -up question prepared for that.

191

But I just wanted to take a break.

192

And for everyone watching last year, probably watching this video because you are either interviewing right now, and I guess you are a JavaScript engineer,

193

whether it's front -end with React or front -end general, full -stack, even back -end developers interviewing right now, then we have a present for you.

194

So we prepared a free technical assessment for you to understand what your technical gaps are

195

and to also adjust your interviewing process

196

and try to fix those gaps for you to be formed in your next technical interview.

197

It's available for free in the comments.

198

The link is going to be there.

199

And you can go to the CNETF website and take it and I wish you the best of luck.

200

With that being said, my big question right now, after seeing all this stuff, I mean, React was already,

201

you know, the learning curve was quite steep and the framework itself is becoming pretty complex.

202

I mean, you spent a few hours to have this kind of thing on that.

203

This knowledge is also not readily available online.

204

So you have to kind of dig deeper into the source code, the documentation.

205

So the million -dollar question is, how much, how deep should the average

206

React developer go?

207

How much should a mid -level developer know?

208

How much should a React engineer know?

209

I guess to answer that, it very much depends of what kind of developer you are.

210

If you're a senior full -stack developer, a bit more spread out, you cannot really spend so much time in React.

211

And so I would just learn maybe the motivation of the React team behind it and a top -level API.

212

But if you are a senior

213

React developer, what we have seen in the market is that it did became a bit more overcrowded than it used to be.

214

And so this level of technical depth, although daunting, it will really help you stand out in an already overcrowded market.

215

And the good news I have for everybody else is that the data structures that are being used, like queues and priority heaps and trees,

216

they will develop your thinking model and your language.

217

And so you don't really lose by going this deep.

218

If you're a senior

219

React developer, I think you will have to go pretty deep into it because this is your thing.

220

You are a senior React developer.

221

If you're a senior front -end developer also, but if you're a senior full stack, I would just look at the top -level ideas behind it

222

and try to understand the motivation of the React team behind

223

it you will not have to interact with the Fiber directly at any point as a developer.

224

So there's no need to go too deep into it.

225

And if you're a React developer trying to deepen your knowledge about React internal, trying to learn more about Fiber 3, where would you start?

226

I would start with the browser APIs.

227

There are two main functions that they built concurrent

228

React around, which is request idle callback, which is, hey, the browser is free and says, you can give me some work to do.

229

I will do it in the background.

230

And that's when React starts rendering.

231

And I think the other one was a request animation frame, which is the browser saying, I'm going to repaint and re -render the UI.

232

Is there anything really quickly that you want me to do before?

233

And that's when React commits changes to the DOM, high priority changes.

234

So you see them in the next refresh, in the next repaint.

235

If you learn those, first of all, you can use them in other frameworks.

236

And then you'll realize that everything they built into Fiber was to be able to use these APIs in a concurrent mode.

237

And that's why they did a priority queue to it and the whole fiber thing.

238

So I would start there.

239

Which is why, folks, and for the people watching us, you will see this across the whole Synodave channel and across everything we do,

240

but fundamentals are the way to go, right?

241

Because as you can see, whatever frameworks are trying to build upon, it's always upon basic browser functionality and JavaScript fundamentals, right?

242

We talked about basic data structures.

243

We'll talk about the call stack.

244

And as you can see, when Barton was actually explaining and going to the Fibre explanations, he did a complexity analysis.

245

He was always referring to data structures that are agnostic and to JavaScript characteristics that are built into the language.

246

So if you really, funny enough, if you really want to master the advanced features of a framework like

247

React, you actually need to master and strengthen your fundamentals first.

248

If you're interested into strengthening your fundamentals, then you're in the right place.

249

Make sure you subscribe to the channel.

250

Let us know in the comments if there's any other advanced react question, senior level question that you want Bogdan or I to cover,

251

or if there's anything in this video that you want us to go deeper into.

252

And we expect a lot more videos like this coming your way.

253

Bogdan, thank you so much, and we will see you folks in the next one.

下載應用

流利口語所需的一切

AI 發音評分逐句打分

音標練習掌握每個音

詞彙學習建立你的詞庫

詞彙遊戲邊玩邊學

掃碼

Download on theApp Store Get it onGoogle Play

同頻道

FOR YOU

本課的詞彙與口語要點

這節口語課以影片“React Interview Questions Senior Level”為素材。影片中反覆出現的詞有：react, fiber, tree, Dom, render。這段影片共有 253 個句子、3294 個單詞可供跟讀。講話部分時長為 17:15。說話人語速較快，每分鐘約 191 個詞，會出現較多連讀和弱讀。只有 80% 的單詞屬於英語最常用的 3,000 詞，詞彙難度較高。

影片中的重點詞彙

影片中 15 個值得學習的單詞，附發音和釋義：

單詞	發音	釋義
priority 名詞	/pɹaɪˈɒɹɪti/	優先權 /優先權, 更重要的事
component 名詞	/kəmˈpoʊ.nənt/	元件, 部件
node 名詞	/noʊd/	結節 /結節
element 名詞	/ˈɛləmənt/	要素
stack 名詞	/stæk/	堆
pause 名詞	/pɔːz/	停頓 /停頓, 暫停 /暫停
reconciliation 名詞	/ˌɹɛkənˌsɪliˈeɪʃ(ə)n/	和解
input 名詞	/ˈɪnpʊt/	輸入 /輸入
queue 名詞	/kju/	佇列 /佇列
compare 動詞	/kəmˈpɛɚ/	比, 比較 /比較
framework 名詞	/ˈfɹeɪm.wɜːk/	骨架, 框架
complexity 名詞	/kəmˈplɛk.sɪ.ti/	複雜性 /複雜性
stable 名詞	/ˈsteɪ.bəl/	馬廄, 馬棚 /馬棚
fundamental 形容詞	/ˌfʌn.dəˈmɛn.təl/	基本
algorithm 名詞	/ˈælɡəɹɪðm̩/	演算法, 演算法

影片中出現的短語動詞

單詞	發音	釋義
follow up 動詞		跟進 /跟進
figure out 動詞		弄清楚
go ahead 動詞	/ˌɡoʊ əˈhɛd/	請便 /請便
go through 動詞		通過 /通過

值得反覆跟讀的句子

影片中簡短而完整的句子，可以直接用在日常對話裡：

Why do I need fiber in the first place?
Could you expand a bit on that?
Do we really need why?
I mean, how can we prevent memory leaks?
What do you mean by that?

影片中的語法

說話人最常用的結構，並附上影片中的原話：

結構	影片中的用法
條件句 if + 從句，will/would + 動詞 — 條件及其結果	if they're not unique, react won't be
“used to” used to + 動詞 — 過去的習慣或狀態，現在已不再如此	used to work · used to be
被動語態 be + 過去分詞 — 強調發生了什麼，而不是誰做的	will be translated · is done · can be paused
定語從句 who / which + 從句 — 補充說明人或事物	node, which is · today, which is · function, which is

需要注意的發音

說話人用了 41 次縮略和弱讀形式，例如 you're, I'm, don't。請按聽到的簡短形式來說。

“th” 音: algorithm /ˈælɡəɹɪðm̩/, thread /ˈθɹɛd/, strengthen /ˈstɹɛŋ(k)θən/
“sh” 和 “zh” 音: reconciliation /ˌɹɛkənˌsɪliˈeɪʃ(ə)n/, explanation /ˌɛkspləˈneɪʃən/, motivation /ˈmoʊ.tə.veɪ.ʃən/, efficient /ɪˈfɪʃənt/, animation /ˌæn.ɪˈmeɪ.ʃən/
長單詞——注意重音位置: priority /pɹaɪˈɒɹɪti/, developer /dɪˈvɛləpɚ/, reconciliation /ˌɹɛkənˌsɪliˈeɪʃ(ə)n/, complexity /kəmˈplɛk.sɪ.ti/, fundamental /ˌfʌn.dəˈmɛn.təl/

中文母語者容易讀錯的音：

/v/ — 不要讀成 /w/，上齒輕觸下唇: virtual /ˈvɜɹt͡ʃuəl/, developer /dɪˈvɛləpɚ/, motivation /ˈmoʊ.tə.veɪ.ʃən/, curve /kɚv/, dive /daɪv/
詞尾子音 — 要讀清楚，後面不要加母音: react /ɹiːˈækt/, component /kəmˈpoʊ.nənt/, node /noʊd/, element /ˈɛləmənt/, stack /stæk/
/r/ 和 /l/ 的區別: virtual /ˈvɜɹt͡ʃuəl/, reconciliation /ˌɹɛkənˌsɪliˈeɪʃ(ə)n/, algorithm /ˈælɡəɹɪðm̩/, scroll /skɹoʊl/, trail /tɹeɪl/

如何用這段影片練習

先完整聽一遍影片，不要開口，記下不認識的單詞。
先用 0.75 倍速逐句跟讀，熟練之後再回到正常速度。
錄下自己的聲音並與原聲對比，特別注意 priority, component, node 這類單詞。

什麼是跟讀法？

跟讀法 (Shadowing) 是一種有科學依據的語言學習技巧，最初開發用於專業口譯員的培訓，並由多語言者Alexander Arguelles博士普及。這個方法簡單而強大：您在聽英語母語原聲的同時立即大聲重複——就像是一個延遲1-2秒緊跟說話者的影子。與被動聽力或語法練習不同，跟讀法強迫您的大腦和口腔肌肉同時處理並模模擬實的講話模式。研究表明它能顯著提高發音準確性，語調，節奏，連讀，聽力理解和口語流利度——使其成為雅思口語備考和真實英語交流最有效的方法之一。

影子跟讀法: 閱讀完整分步指南 →

跟讀練習: React Interview Questions Senior Level (React Fiber, Reconciliation, Virtual DOM) - 通過影片學習英語口語

選擇練習模式

下載應用

同頻道

Backend Interview Questions (Junior & Mid)

how AI broke the SWE Career Ladder

FullStack Interview Questions (Junior & Mid)

Senior Frontend Developer Interview Questions

推薦影片

React Conf 2025 React Native Keynote

BGP Overview

Use these CSS features instead of JavaScript

Armchair Architects: Resiliency in the Cloud – Core Patterns

Video

Can This Vibe Coder Beat a Senior Developer?

Trust the Process: How to Design Teams That Actually Work

How I deploy serverless containers for free

The future unfolds! How to optimize Android apps for adaptive layouts

10 Essential React Native Tips Every Developer Must Know

Is React Native Dead? Shopify Is Leaving