Not sure what you’re looking for. But regarding what’s happening with React/Meteor at a conceptual level:
View: The Meteor server is injecting some code into the client, including the entire react and react-dom libraries. Certain files are executed immediately. These two libraries are imported in these files and some of their functions are called which trigger the construction of an in-cache data-tree. This data-tree represents the DOM and is called the Virtual DOM. Some other functions in these libraries are responsible for mounting the actual DOM with elements derived from this data-tree. This comprises the view layer. You can think of the view layer as being separate from the model/data layer. The point of the Virtual DOM is to introduce causality within your view layer, so that you don’t have to spend hours wiring in cause-and-effect manually. The virtual DOM makes it easier to keep your view self-synchronized.
Model: While all of this is happening, Meteor has also injected some of its own native libraries into the client. Some functions from these libraries are imported and called which trigger the construction of yet another in-cache data-tree. This data-tree represents the client’s memory of server-sent data, and is called Minimongo. This comprises the model/data layer. You can think of the mode/data layer as being separate from the view layer. The point of Minimongo is to introduce causality between the server and the client, so that you don’t have to spend hours wiring in cause-and-effect manually. Minimongo makes it easier to keep your client and server synchronized with eachother. Of course, I’m ignoring DDP and the server-cache, but we’re focusing only on the client right now. Meteor does a lot of stuff on the server to ensure this.
Meteor and React are very similar technologies, applied to different parts of the stack. The way that information is passed down the virtual DOM tree is similar (in a way) to how information is passed down from server to client in Meteor. The key principle here is what is called “reactivity”. Reactivity is responsible for synchronization between parts.
If B reacts to A, and A depends on C, then B implicitly depends on C, that is B depends on C without requiring an explicit statement that B depends on C. This means you write less code. You don’t need to manually update everything down a chain of cause and effect, because the system is reactive.
Now, how do these two layers interact with each other?
Meteor provides additional functions which couple some of the Virtual DOM’s functions (the view layer) with some of Meteor’s Reactive Computations, which are, in turn, coupled with Minimongo (the data layer). This means that changes in Meteor’s data-tree (Minimongo) will trigger functions to re-run which, in turn, will trigger lifecycle functions in React’s data-tree (Virtual DOM) to re-run. When these lifecycle methods re-run, sometimes they alter the DOM as a side-effect.
You should be able to draw some nice flow diagrams to accompany these descriptions.