Our discussion of SPA concepts thus far has been narrowly focused. Let’s pull back now and review the SPA landscape from a holistic viewpoint. This review will also bring to light some new details that you’ll need to grasp when you start this project.
5.2.1 Views
When you design an SPA’s views, you’re creating the individual pieces of the overall SPA puzzle. Each piece provides a particular experience for the user, whether it’s merely displaying data or providing controls for user input. Generally speaking, you design views on two levels. At a basic level, you design the view itself. At a broader level, you’re more concerned with how the view fits into the overall architecture.
From within the view, your design efforts are concentrated on tasks such as display- ing data and possibly adding interactivity via JavaScript. As you’ve learned, it’s the MV*
framework that helps keep the various parts of your application’s code separate but working together as a team. HTML elements and bindings combine to form the basis of the view’s design. You can further contribute to the design of the view by applying styles to it via CSS (see figure 5.2).
Data
MV* framework Model
Wellness Clinic Medical Center Metro Family Clinic CMR Health Center Mecklenburg Pediatrics R.P. Taylor Hospital
<ul>
<li ng-repeat="customer in list">
<a href="{{customer.link}}">
{{customer.name}}
</a>
</li>
</ul>
Wellness Clinic Medical Center Metro Family Clinic CMR Health Center Mecklenburg Pediatrics R.P. Taylor Hospital
Wellness Clinic Medical Center Metro Family Clinic CMR Health Center Mecklenburg Pediatrics R.P. Taylor Hospital
Bind Render CSS
Template Rendered view
Figure 5.2 The template’s HTML forms an initial structure, but CSS refines its look and feel.
109 Reviewing layout design concepts
When it comes to the bigger picture (the layout), you have to think about how each view will be positioned with respect to the other views in a feature. To position a ren- dered view in a particular area of the screen, you turn to a construct called a region.
5.2.2 Regions
I briefly discussed the concept of a region in chapter 1. Although certain view engines have their own notions of this term, in this chapter I use region to mean an area of the screen that’s been designated to contain one or more views. A region can be defined using semantic elements if you’re using HTML5 (see figure 5.3) or an element such as a DIV if you’re not. These types of elements are ideal, because they can remain invisi- ble to the user but can be used to define physical space within the UI.
To define a region’s dimensions, as well as its aesthetic relationship with other regions, you can use Cascading Style Sheets (CSS). In figure 5.4, you can see an exam- ple of applying styles to regions to achieve a certain layout.
This example positions two regions side by side by assigning a simple float prop- erty to the regions. For a simple 2×2 layout, you can float one region to the left and the other to the right. After placing the regions, you can make decisions about the views they’ll contain.
You can also assign other CSS properties to your region to further enhance the effect on your layout’s design, such as width, height, padding, borders, margins, and
View 6 View 5
Regions act as containers for views View
Title
Region A
<nav>
</nav>
Region B
<section>
</section>
View 1 View 4
View 3 View 2
Dynamically swapped views within a single region Figure 5.3 Regions give you a physical area in the UI where your views can be displayed. Within a region, views can be fixed or dynamically swapped.
background-color, to name a few. Any property applicable to the type of element you choose is fair game.
The process of deciding on the size and shape of regions and the arrangement of views within those regions to arrive at a particular layout is called view composition.
5.2.3 View composition
As part of the design process, you arrange, or compose, views in a certain way to form the UI’s layout. In this regard, you can think of view composition as both art and sci- ence. On one hand, you have the technology that helps create the views and display them in the UI when a particular route is carried out. On the other hand, there’s the creative aspect in which you make a subjective decision about where regions will be placed and how a view, or a set of views, will be arranged within them.
Although this process is called view composition, regions play an equally important role in the creation of a layout, as you’ve seen. Regions house the views that are ren- dered by the MV* framework. Given this, you can say that for all practical purposes, regions are the bounding boxes that frame views within your layout. That’s why view composition encompasses both views and regions, hand in hand.
To illustrate how regions can affect view composition, take a look at figure 5.5.
Here you see the same views that you saw earlier in figure 5.3. By reconfiguring your regions, you can display exactly the same information with an entirely different layout.
In turn, this has a direct impact on your SPA’s look and feel.
How your regions and views are arranged is completely subjective, tailored to the goals of your project and your design preferences.
Title
Region A
<nav id="side">
</nav>
Region B
<section id="content">
</section>
Float left
nav#side {
background-color: #ADADAD;
float: left;
width: 28%;
margin: 1%;
}
#content { margin: 1%;
padding: 2%;
height: 100%;
overflow-y: auto;
text-align: top;
background-color: #FFFFFF;
border-radius: 5px;
color: black;
}
Figure 5.4 CSS is used to define the physical attributes of the regions in your layout, as well as to define their relationship with other regions in the UI.
111 Reviewing layout design concepts
5.2.4 Nested views
An important point to bear in mind is that the use of regions doesn’t have to be con- fined to the SPA’s shell. Regions can also be employed within a view to nest other views (see figure 5.6).
Nesting views can dramatically increase the complexity of your design, but that’s sometimes necessary given the nature of the feature you’re building. You can also con- figure the application’s routes so that your design is properly reflected in the UI when the application’s state changes.
Title
Region A
<nav>
</nav>
Region B
<section>
</section>
View 1
Now only these views are dynamically swapped.
Region D
<section>
</section>
Region C
<section>
</section>
View 2
View 6 View 5 View 4
View 3
Figure 5.5 How regions and views are configured impacts view composition and ultimately the layout.
Regions within views create nested views.
</section>
Region C
<section>
View 3
View 4
<section>
Region D
</section>
<section>
Region E
</section>
View 5
Figure 5.6 Regions can also be used in views, if you need to nest a view (or views) inside another view.
5.2.5 Routes
As you saw in chapter 4, the way you configure routes affects the application’s state.
This includes the state of the UI. This is why route configuration can also be an impor- tant aspect of your layout’s design.
While you were learning about routing and how routers work, you worked with only simple examples, as in figure 5.7. In this type of route, each resulting view occu- pies the entire destination region. Designing a route like this is pretty cut and dry.
But as you just learned, the regions you’re targeting can be placed in any number of places on the screen. This can lead to some interesting designs. You could, for example, have multiple regions positioned next to each other and display multiple views for a given route (see figure 5.8).
When you design routes that result in complex region/view configurations, things can become difficult to manage. For complicated layouts, if you’re not using a one- stop-shopping framework with robust routing and view management built in, you might want to consider adding a library to your arsenal that manages the application’s state specifically for the MV* framework you’re using. The next section covers some of the pros and cons of bringing a view management library onboard and points out some of the options available.
Region A View 1
#/route
Figure 5.7 Example of a simple route
Region A Region B
View 1 View 2
#/route
Region D View 3
Figure 5.8 Example of a route with multiple views
113 Considering alternatives for advanced composition and layout