Understanding MVVM: Concepts, Evolution, and Frontend Data‑Flow Solutions

The author, a frontend engineer at Alibaba Data Platform, introduces MVVM (Model‑View‑ViewModel) as a two‑way data‑flow mechanism where the ViewModel bridges the View and Model, contrasting it with one‑way data flow that requires manual binding.

Many frontend frameworks embed MVVM functionality (e.g., Knockout, Angular, Vue, San), while libraries such as MobX, Immer, and Dob decouple the data layer from the framework, forming a higher‑level MVVM architecture: View ← Framework, Model ← (mobx, dob), ViewModel ← (mobx‑react, dob‑react).

Early MVVM implementations relied on dirty‑checking, which was inefficient; modern frameworks use getter/setter interception to detect changes within a single event loop, greatly improving performance.

The article also compares mutable and immutable data‑change styles, showing how different connect syntaxes handle each case, and discusses how mutable drives automatic view updates while immutable requires new object creation to propagate changes.

Tracing the origins of MVVM, the author explains TFRP concepts such as autorun and reaction , where autorun combines dependency collection and listening, and reaction implements it by dispatching from a subscription, forming a closed loop of tracking and updates.

Implementation details include a track that records getter events in a two‑dimensional map, enabling callbacks to be triggered when dependencies change, and wrapping view rendering in an autorun environment to ensure a single binding per render.

Common MVVM drawbacks and their solutions are discussed: inability to observe new properties (solved by using proxy instead of Object.defineProperty ), async limitations (global variable work‑arounds), nested autorun ordering (queueing to the end), lack of data snapshots (addressed by Immer’s proxy‑based immutable updates), and side‑effect isolation (mitigated by separating async actions or using zero‑side‑effect immutable patterns).

Four typical MVVM store organization patterns are presented: object‑based stores (MobX), class‑based with injection (Dob), structured stores (mobx‑state‑tree), and convention‑based integrated stores (DVA‑like), each illustrated with diagrams.

The relationship between MVVM and reactive programming is highlighted, showing that both expose observables but differ in where the observable boundary lies; the article suggests combining MVVM with RxJS to isolate side effects while retaining precise view updates.

In conclusion, the author emphasizes selecting a data‑flow solution based on business scenarios, noting that no single approach is a silver bullet and that combining multiple patterns can yield the most effective architecture.