In this blog I’ll show you how to guard routes in Angular 2 Router
(currently at 3.0.0-beta.2).
Let’s consider some scenarios that require a certain validation to be
performed to decide if the user (or a program) is allowed to navigate to or
leave the route:
Allowed to open the route only if the user is authenticated and authorized to
do so. Implement a multi-part form that consists of several components, and
the user is allowed to navigate to the next form section only if the data
entered in the current one is valid. Allow to navigate to a route only after
a certain data structures have been populated. Remind the user about the
unsaved changes if he or she tries to navigate from the route.
The router has the hooks that give you more control over the navigation
to/from a route, and you can use these hooks to implement the any of above
scenarios to guard the routes.
This article was excerpted from the book “Angular Development With
TypeScript” (see http://bit.ly/1QYeqL0).
The Angular 2 framework is a re-write of popular framework AngularJS. In
short, the newer version has the following advantages over AngularJS.
The code is simpler to write and read It performs better than AngularJS
It’s easier to learn The application architecture is simplified as it’s
This article contains a high-level overview of Angular highlighting
improvements comparing to AngularJS. For a more detailed architecture
overview of Angular visit product do... (more)
In Angular 2 a parent component can pass the data to its child via binding to
the child’s input parameter marked with the annotation @Input(). I’ll
blog about it later, but you can see how it can be done in my blog on
implementing the Mediator design pattern.
In this blog I’ll show you another scenario when the parent component
simply needs to use the API exposed by the child. You’ll see how a parent
component can use the child’s API from both the template and the TypeScript
Let’s create a simple application where a child component has the method
greet() that will be invo... (more)
In any component-based framework you’ll need to implement component
communications. The main principle is that components should be loosely
coupled hence reusable hence testable. The mediator design pattern allows you
to arrange component communications via “the man in the middle” so a
component A never communicates with the component B directly. If a component
needs data, someone will provide the data via bindings to the component’s
input properties. Who’s this someone?Ain’t no business of the component.
If a component needs to provide some data to the external world, it’ll emit... (more)
[This prescient article first appeared on SYS-CON.com nearly 12 months ago.]
We are entering an era of Rich Internet Applications (RIA), and many
enterprise development managers are facing the dilemma - which way to go -
remain with tried and true Java or .Net technologies or less known yet
AJAX, Flex, OpenLaszlo or a number of other vendors. This article is an
attempt to give a brief overview of what's out there on the RIA market.
Historically there have been major shifts in the software industry. We moved
from mainframes with dumb terminals to client/server. Users gained in