Configuring ViewModel Hierarchy

If you haven’t yet read and understood article ViewModel Internals do it now, or the following may not make any sense to you. It is an advanced material.
See also the related example and download the complete source code.

Do we need it?

Perhaps not. For small applications that have a couple of views, one container with one “main” view model that is holding data, a few stores and a couple of formulas for needs of each and every view we do not need any hierarchy of view models.


But imagine an application with one or two hundreds of views. Do we still want to keep all data and stores in the main view model and let its code grow to thousands, many thousands of lines? Initializing stores, formulas and data also when the view using them is not currently visible or instantiated?

The easy solution then, right? Let’s put all “view-only” stores, data and formulas in their own view models that have lifetime identical to the lifetime of their views.


Well, are almost there. Not quite, but almost. The problem we have now is how to bind data between view models. For example, selecting a row in a grid should populate a form with detail data. But both grid and form have their own view models. We would like to publish the grid selection up to the main view model to which we could bind the form fields, yet we would like to keep the grid store configuration in the “local” grid’s view model.

When we need it, how to implement it?

To demonstrate, let take the following simple example.
Selecting a row of the grid causes that the underlying record from the grid store populates the detail form on the right.

Right after running sencha generate view ... we have this structure:

Initial Views and View Models

Initial Views and View Models

There are no relations between views and their view models other than that views use their view models. It is just a starting point for us to start configuring data binding and publishing.

The first thing to configure in the grid view model is the store. And, because we want the grid to publish its selection, we set a “reference” in the grid view. If a reference for the grid is configured, the selected record is automatically published.

Initial Views and View Models

Configured store and reference

Whereto is it published? To the grid’s view model. The missing ingredient is how to get the selected record up to the main view model so that we could bind the form fields.

Initial Views and View Models

Publishing a value upwards

For that we need to do two things:

  1. In the main view model, configure the object that will hold the currently selected customer:
  2. In the grid view model, define the formula that does the trick:

The rest is peanuts, we just bind the form fields to “{current.customer.[field name]}” and we are done. Of course, we can utilize the form view model to calculate some derived data for us, such as valid and dirty states.

Initial Views and View Models

Binding form fields and status

I believe that this technique helps you to code better, robust and modularized application without a spaghetti code.

See also the related example and download the complete source code.
Share on FacebookTweet about this on TwitterShare on LinkedInShare on Google+Pin on PinterestEmail this to someone
Follow me:


I'm a well seasoned developer, consultant and educator of web applications based mainly on Sencha libraries, PHP, MySQL and Node.js. Besides (Apple) computers, I love photography and mountain biking.
Follow me:

Latest posts by Saki (see all)


  1. Bill Seddon says

    Thanks for the explanation. It seem this pattern is susceptible to automation so hopefully future releases will make this simpler or, at least, obvious.


  2. Mitesh Dave says

    Hi Saki,
    I have a question why Selected record is automatically published to View model? How just by specifying reference selected record are published to view model.

    Please let me know the mechanism behind this


We will be happy to hear back from you

Please Login to post a comment