Page 16 - MSDN Magazine, June 2018

The Working Programmer TED NEWARD How To Be MEAN: Reactive Programming
Welcome back again, MEANers.
In the previous two articles (msdn.com/magazine/mt829391 and
msdn.com/magazine/mt814413), I talked a great deal about what Angular refers to as “template-driven forms,” which are forms described by Angular templates and extended by the use of code to control val- idation and other logic. That’s all well and good, but a new concept about how to view the “flow” of information—and the resultant control exhibited in code—within a Web application is starting to seize developers’ imaginations.
I speak, of course, of “reactive” programming, and one of the great shifts between AngularJS (that is, Angular 1.0) and Angular (Angular 2.0 and beyond) is that Angular now has explicit sup- port for a reactive style of programming, at least at the Angular level. All of which is to say, Angular supports using reactive styles of programming within Angular without having to commit to a completely reactive style of architecture outside of Angular.
Before I dive in, though, it helps to make sure everybody’s on board with what “reactive” means here.
Reactive Reactions
Fundamentally, reactive styles of programming are easy to under- stand, so long as you’re willing to completely invert your perspective on the traditional way of doing UI programming. (Yes, that’s a joke. But only a small one.)
In the traditional MVC-based approach for building UIs, the UI elements (buttons, text fields and the like) are created, and then ... you wait. The system processes messages from the hardware, and when some combination of messages indicates that the user did something—clicked a button, typed into a text box or what- ever—the code bound to the controls fires. That code typically modifies the model lying behind the UI, and the application goes back into waiting.
This “event-driven” style of programming is intrinsically asyn- chronous, in that the code that the programmer writes is always driven by what the user does. In some ways, it would be better to call it “indeterministic” programming, because you can’t ever know what the user will do next. Angular sought to make this easier by creating two-way binding between the UI and data model, but it can still be tricky to keep the order of things straight.
The reactive style, however, takes a more one-way approach. Controls are constructed in code (rather than in the template), and you programmatically subscribe to events emitted by those con- trols to respond to the user doing things. It’s not quite React-style
reactive programming, but it’s pretty close, and it still permits the same kind of “immutable data model” style of programming that has enamored a percentage of the industry.
Reactive Construction
To begin, let’s look at constructing the SpeakerUI component in a reactive manner, rather than in a template-driven manner. (Here, I’m going to go with the more traditional Angular convention and call it SpeakerDetail, but the name is largely irrelevant to the dis- cussion.) First, in order to help simplify what I’m working with, I’ll use the abbreviated form of Speaker and SpeakerService, as shown in Figure 1.
Notice that the SpeakerService is using the Promise.resolve method to return a Promise that is instantly resolved. This is an
Figure 1 Speaker and SpeakerService
import { Injectable } from '@angular/core';
export class Speaker { id = 0
firstName = "" lastName = "" age = 0
}
@Injectable()
export class SpeakerService {
private speakers : Speaker[] = [ {
id: 1,
firstName: 'Brian', lastName: 'Randell', age: 47,
}, {
id: 2,
firstName: 'Ted', lastName: 'Neward', age: 46,
}, {
id: 3,
firstName: 'Rachel', lastName: 'Appel', age: 39,
} ]
getSpeakers() : Promise<Array<Speaker>> {
return Promise.resolve(this.speakers); }
getSpeaker(id: number) : Promise<Speaker> { return Promise.resolve(this.speakers[id - 1 ]);
} }
12 msdn magazine