Thank you, Chris, for the great post. It feels like I’m getting closer and closer to understanding how Ember’s reactive system works under the hood.
There’s one (possibly more) thing I don’t understand about the recomputing part and I wondered if you could shed a light on it.
You write this about tracking frame clock values:
When a given tracking frame “closes”, as at the close of a component invocation, it computes its own clock value. A tracking frame’s clock value is the maximum clock value of any of the properties marked as used in that frame.
Let’s say, there are just two tracking frames, Frame 1 and Frame 2, their clock values being set at 10 for both. A tracked property updates in the property tree of Frame 2, bumping both the clock value of Frame 2 and the global clock value to 11.
Now, at the next rendering, the Glimmer VM compares each frame’s clock value with the global one to see which needs to be re-rendered. Does it only re-render the one where the two values are equal?