ITT: people shitting on this guy's explanation b/c of a couple mistakes - "MVC React" and "Gandolf" (yikes). The rest of the explanations are actually accurate, super concise, and gave me direction to go look up some extra material which really aided my understanding of how React works under the hood! For the people annoyed about the nervous delivery, just watch on 2x, it's still quite legible.
This was a great explainantion. No one's mentioned that it's just doing a really optimized JSON diff. And that context makes sense with the lifecycle tools. And that last debugging package is great to know. Thank you!
One small remark, O(n) is not an optimization. It is an heuristic based on provided assumption that returns you some sub-optimal solution. Optimization is something different. Optimization is a "hint" to known algorithm to make it faster. For instance, if one would choose using O(n^3) algorithm which really finds the minimal set of changes then optimization could be a hint to this algorithm. However, it will give you the optimal solution. Another example could be Minimax. The result of Minimax does not change if you give it the "hint" of alpha-beta pruning. [Optimization in compiler theory is something different [optimization means here "better solution"], but intuitively it is the same. Compilation result, i.e. machine (or code) should be the same either compiler worked with optimization hints or not (at least in theory). Two produced machines are equivalent regardless of their sizes or execution speed. Compiler returns the optimal solution. That is the equivalent machine to source]. Terms are important because of their meaning. Juggling terms makes you speaking the bird language. Sometime people cease to understand you. Спасибо и удачи. Лайк.
@@sasidharreddy7840 The short answer is "no". TL; DR; Leave React aside. I will try to explain on fingers... The first thing we have is a "problem". The outcome of it is a "solution". In algo you may have "optimal" and "suboptimal" solutions. "Optimal" in other words means "exact". "Suboptimal" in other words means "good enough for a given problem". The way to the solution is "algorithm". Say, you want to sort some array of strings (names of customers, for example). There will be _only one_ optimal solution for a given input (alphabetically sorted names). You can’t go below n * log(n) [i.e., omega of] in sorting if it is based on comparisons (there is a proof). Nevertheless, you might have an optimization while comparing strings. If within a string you have precalculated value of its hash, in the comparison you might not to go char by char but first to conclude whether they are equivalent or not and only then drop to comparison whether one is greater or less than another. You will save a time if you have a lot of equal strings. The algorithm remains exactly the same! Just some additional info to help it. Now, what if I am saying that most people don’t care about exact sorting in names, and it is enough to have only two (or three) letters of names sorted and about others nobody cares. This is a heuristic. So, can we do better from the time perspective? Oh, yeah! The game has been changed. Now what we can do is to use Bucket sorting. For each two (or three) letter permutations we will have a bucket (say, "aa" -> 0, "ab" -> 1, ..., "zz" -> 26^2 - 1). So, now, it is O(n). In the first step we insert a name to the appropriate bucket which is O(n), in the second step, we will go over the buckets and first and put into the list which is O(n) since the number of buckets do not depend on the input and at most there will be N entries. This is suboptimal but it is good enough for the problem (and much faster in many cases). React trees comparison is different, but it is the same ;-)
I've been looking for talk like this for a while, thanks for sharing this very intuitive explanation !! Hope to find more ( I'm gonna explore your talks :) )
React isn’t an MVC framework. React is a library for building composable user interfaces. It encourages the creation of reusable UI components which present data that changes over time.
If you zoom into the details of React, it can be broken down into MVC tiers and that makes sense. I think your idea of MVC might be the traditional 3-tier app of V being client, C being middletier, and model being the database.
he so nervous, it makes me nervous, but the explanation of what React does with the DOM and Virtual DOM is pretty well done. The diffing is explained in a pretty straightforward fashion.
sanjiv chavan Because every change to the DOM will trigger a reflow as he mentioned which is really slow. You want to make all your changes at once and also you want to minimize the number of changes that you make. He also mentioned that even reeading from the actual DOM might trigger a reflow, so you might trigger the reflow during the diffing phase.
A virtual DOM is created "completely from scratch" every time 2:40? I thought that a "new" tree is created only when the root elements are not of the same type (eg. span and div)
That is probably the most stupid explanation of MVC I have ever heard. What makes me sad is that is “academy” which supposed to teach new devs who doesn’t yet have a bs filter.
I believe that he was talking about how the library is structured itselft. "react is whats called a model-view-controller, it's the architecture of the library. What that really means that it splits up the controll of whole process into three components." That are his words and after that he is talking about model as core of react where is the virtual DOM built. Maybe I misunderstood it, can you explain me why is this the most stupid explanation? I don't know, but if you would look on react as single application you see that MVC desing pattern can be applied or seen in this structure. I'm relatively new in this, so your answer could help me a lot.
