Luyện nói tiếng Anh bằng Shadowing qua video: React Interview Questions Senior Level (React Fiber, Reconciliation, Virtual DOM)

Chọn chế độ luyện tập

Mỗi chế độ mở một phòng luyện tập toàn màn hình.

253 câu
Nếu các câu quá ngắn hoặc quá dài, hãy bấm Edit để chỉnh sửa.
1
So today we will answer some of the hardest senior
2
React interview questions our M &T's got in real front -end interviews.
3
We are going to deep dive into concepts such as concurrent
4
React, React Fiber, the reconciliation process, and the virtual DOM.
5
Bogdan is going to answer the interview questions, but also give you the mental models and the reasons why behind his explanations.
6
Bogdan, are you ready?
7
Yes, let's go.
8
And let's go with the first question.
9
What is React Fiber and how is it different from the virtual DOM?
10
Perfect.
11
So I'm going to go ahead and share my screen for this one.
12
What is React Fiber and how is it different from the virtual DOM?
13
Well, to put this simply, back in the days we had our React elements
14
that would create a virtual DOM node and then that will be translated into an actual DOM node with reconciliation.
15
But the problem with this is that it's a very synchronous process.
16
That means imagine we have a huge tree of elements.
17
We need to render all of those.
18
I compute the state
19
and with JSX compute the virtual DOM node all done synchrously in one shot and then render the DOM.
20
And what React introduced in version 16 with React asynchronous is the fiber node, which is an intermediate structure that gets created.
21
And basically all the work of rendering component is done by fiber, by this fiber node.
22
So just like you had a tree of virtual DOM nodes, now you have a fiber tree.
23
Whenever we need to re -render, we work on this tree, we compute the new state, we run certain lifecycle methods.
24
And once we are done, we can then compute the virtual DOM from the fiber tree.
25
And the big advantage of having this structure
26
and the why behind it is that differently from the virtual node and traditional rendering, the fiber reconciliation can be paused.
27
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,
28
do something else, and then come back to this.
29
And that was not possible before fiber.
30
So that would be the big difference where the virtual DOM, it's only used now to actually compute the differences to the DOM.
31
And the fiber, it's a new intermediate structure that allows us to pause
32
and prioritize the render process to make it asynchronous or what they call concurrent React.
33
Cool, Bogdan.
34
This leads me to our second question today, which is, can you explain the reconciliation process in React?
35
And also, if you can tell me what does the introduction of React Fiber means for the reconciliation process as well?
36
So in the reconciliation, in traditional reconciliation, we had our component.
37
It will trigger a state change, and that will trigger a re -render of the component re.
38
And re -rendering means we would go from the root node, the root component, all the way to the children,
39
all the way to what we call the leaf nodes, the very bottom components, and run the render function recursively.
40
And we would put that in the call stack.
41
So all these things will be into the call stack, all the way to the bottom.
42
Then we would execute them.
43
And finally, from that, we would extract the new virtual DOM.
44
That's what they call the stack reconciler.
45
And this one, it's kind of synchronous in the sense of, imagine we have a huge component tree,
46
we would need to put recursively all those render functions in here, finish them, and then finally render.
47
When we have a huge component tree, you might have what we call a blocking UI.
48
Imagine we're fetching some data and rendering things on the screen.
49
If you are completing a form at the same time as a user,
50
you would perceive that form as non -responsive because the call stack is busy by rendering these components that are being fetched.
51
And so we can't really re -render, for example, the UI.
52
The browser cannot repaint, so maybe you're typing in an input field, but you don't see anything happening.
53
So that was kind of the old reconciliation process.
54
And after that, we had our VDome.
55
We would make our diffing algorithm and finally commit to the DOM, the changes needed.
56
That was how
57
React used to work.
58
With Fiber, things are a bit more complex.
59
So what React does is from the component tree, it will build what we call a fiber tree.
60
And a fiber, it's nothing but, let me zoom in, I think I have a fiber around here.
61
It's a JavaScript object.
62
And inside there's many properties, but probably the most important are the state and the new props, like the props the component has,
63
the memorized props, everything you need about the component, the function that runs it, the siblings and the child are all here.
64
And so React will create a fiber tree with this internally.
65
And it will run the render function for that fiber tree.
66
And from it, it will deduct the virtual DOM.
67
And then the process is just like before.
68
The virtual DOM gets compared with our diffing algorithm and we commit changes to the DOM.
69
So far, nothing changed, but we have this intermediate step.
70
Nice.
71
Now, what I still don't understand by the minute, right now we have the fiber tree, right?
72
As a, in between the virtual DOM and the state changes the plate.
73
And I'm wondering...
74
Why the fiber tree?
75
Why do I need fiber in the first place?
76
Because it adds extra complexity.
77
And I'm wondering, what does fiber allows me to do that the virtual DOM couldn't?
78
You mentioned this asynchronous rendering.
79
Could you expand a bit on that?
80
Because it feels to me like it's adding a lot of complexity.
81
React was already complex.
82
The diffing algorithm was already complex.
83
And now we have a stage in between that's kind of definitely adding another layer of abstraction, of complexity.
84
Is it worth it?
85
Do we really need why? and why do we really need this step, this fiber tree?
86
Yeah, very good question.
87
So what the fiber tree allows us to do is that it works together with a priority queue and a scheduler.
88
And rather than having this process synchronous, like we really, as I explained before about the stack reconcilator,
89
we would go like have to run the whole render in one shot.
90
We can actually pause.
91
We can actually stop at a certain node, pause and do something else and then come back to this render.
92
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,
93
an update gets attached to this fiber tree.
94
So let's imagine there's a state change here for this form component.
95
There is an update queue for this form component and that change that will be queued there.
96
And what React will do after that is to copy the current fiber tree in the background and do work on it.
97
That means just go through each node and see
98
if there's any updates and compute the new memoized state and run the render method.
99
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.

Tải Ứng Dụng

Mọi thứ bạn cần để nói trôi chảy

Chấm điểm AIChấm từng câu nói
Luyện IPAThành thạo mọi âm
Từ vựngMở rộng vốn từ
Game Từ vựngHọc qua chơi

Cùng kênh

FOR YOU

Video gợi ý

Từ vựng và ghi chú luyện nói cho bài học này

Bài luyện nói này dựa trên video “React Interview Questions Senior Level”. Những từ được nhắc lại nhiều nhất trong bài: react, fiber, tree, Dom, render. Video này có 253 câu và 3294 từ để luyện shadowing. Phần lời nói dài 17:15. Người nói nói nhanh, khoảng 191 từ mỗi phút, nên sẽ có nhiều chỗ nối âm và nuốt âm. Chỉ 80% số từ nằm trong 3.000 từ tiếng Anh thông dụng nhất, nên từ vựng khá khó.

Từ vựng quan trọng trong video

15 từ đáng học trong video, kèm phiên âm và nghĩa:

TừPhiên âmNghĩa
priority danh từ/pɹaɪˈɒɹɪti/sự ưu tiên
component danh từ/kəmˈpoʊ.nənt/bộ phận
developer danh từ/dɪˈvɛləpɚ/nhà phát triển
node danh từ/noʊd/gióng
element danh từ/ˈɛləmənt/yếu tố
stack danh từ/stæk/chồng
reconciliation danh từ/ˌɹɛkənˌsɪliˈeɪʃ(ə)n/hoà giải
queue danh từ/kju/xếp nối đuôi
compare động từ/kəmˈpɛɚ/so sánh, so
stable danh từ/ˈsteɪ.bəl/chuồng, chuồng ngựa
algorithm danh từ/ˈælɡəɹɪðm̩/thuật toán
fetch động từ/fɛt͡ʃ/tìm
thread danh từ/ˈθɹɛd/chỉ
trigger danh từ/ˈtɹɪɡɚ/cò
leaf danh từ/lif/lá

Những câu đáng luyện lại

Các câu ngắn, trọn ý trong video mà bạn có thể dùng lại khi giao tiếp hằng ngày:

  • 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?

Ngữ pháp trong video

Những cấu trúc người nói dùng nhiều nhất, kèm đúng cụm từ trong video:

Cấu trúcTrong video
Câu điều kiện if + mệnh đề, will/would + động từ — điều kiện và kết quảif they're not unique, react won't be
“Used to” used to + động từ — thói quen hoặc tình trạng trong quá khứ nay không cònused to work · used to be
Câu bị động be + quá khứ phân từ — nhấn vào việc xảy ra, không phải người làmwill be translated · is done · can be paused
Mệnh đề quan hệ who / which + mệnh đề — thêm thông tin về người hoặc vậtnode, which is · today, which is · function, which is

Phát âm cần chú ý

Người nói dùng 41 dạng rút gọn, ví dụ you're, I'm, don't. Hãy nói theo dạng ngắn đúng như bạn nghe.

  • Âm “th”: algorithm /ˈælɡəɹɪðm̩/, thread /ˈθɹɛd/, strengthen /ˈstɹɛŋ(k)θən/
  • Âm “sh” và “zh”: reconciliation /ˌɹɛkənˌsɪliˈeɪʃ(ə)n/, explanation /ˌɛkspləˈneɪʃən/, motivation /ˈmoʊ.tə.veɪ.ʃən/, efficient /ɪˈfɪʃənt/, animation /ˌæn.ɪˈmeɪ.ʃən/
  • Từ dài — đặt trọng âm cho đúng: 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/

Những âm người Việt thường gặp khó:

  • Cụm phụ âm cuối — đọc đủ từng âm, đừng nuốt âm cuối: react /ɹiːˈækt/, component /kəmˈpoʊ.nənt/, element /ˈɛləmənt/, assessment /əˈsɛsmənt/, efficient /ɪˈfɪʃənt/
  • Âm /tʃ/, /dʒ/ và /ʒ/ — tiếng Việt không có, đừng đọc thành “ch” hay “gi”: virtual /ˈvɜɹt͡ʃuəl/, fetch /fɛt͡ʃ/, scratch /skɹæt͡ʃ/, adjust /əˈd͡ʒʌst/, attach /əˈtæt͡ʃ/
  • Âm /æ/ — mở miệng rộng hơn âm “e”: react /ɹiːˈækt/, stack /stæk/, algorithm /ˈælɡəɹɪðm̩/, gap /ɡæp/, whereas /(h)wɛɹˈæz/

Cách luyện với video này

  1. Nghe hết video một lần, chưa cần nói, và ghi lại những từ bạn chưa biết.
  2. Bắt đầu ở tốc độ 0,75×, nói đuổi từng câu, rồi quay lại tốc độ bình thường khi đã quen.
  3. Ghi âm giọng mình rồi so với bản gốc, chú ý các từ như priority, component, developer.

Phương Pháp Shadowing Là Gì?

Shadowing là kỹ thuật học ngôn ngữ có cơ sở khoa học, ban đầu được phát triển cho chương trình đào tạo phiên dịch viên chuyên nghiệp và được phổ biến rộng rãi bởi nhà đa ngôn ngữ học Dr. Alexander Arguelles. Nguyên lý cốt lõi đơn giản nhưng cực kỳ hiệu quả: bạn nghe tiếng Anh của người bản xứ và lặp lại to ngay lập tức — như một "cái bóng" (shadow) đuổi theo người nói với độ trễ chỉ 1–2 giây. Khác với luyện ngữ pháp hay học từ vựng bị động, Shadowing buộc não bộ và cơ miệng phải đồng thời xử lý và tái tạo ngôn ngữ thực tế. Các nghiên cứu khoa học xác nhận phương pháp này cải thiện đáng kể phát âm, ngữ điệu, nhịp điệu, nối âm, kỹ năng nghe và độ lưu loát khi nói — đặc biệt hiệu quả cho người luyện IELTS Speaking và muốn giao tiếp tiếng Anh tự nhiên như người bản ngữ.

Phương pháp shadowing: đọc hướng dẫn từng bước đầy đủ →