an devon4ng application

Table of Contents

• devon4ng Application
  • MyThaiStar Basics
  • MyThaiStar devon4ng Front-end Overview
    • The devon4ng Project
    • Angular Folder Structure
    • Components
    • Services
    • Modules
  • Running MyThaiStar Client

devon4ng Application

MyThaiStar Basics

As an example of how a devon4ng application is built, we are going to show the MyThaiStar application front-end project, that can be found in GitHub.

The MyThaiStar application is a solution for managing the online booking and orders of a restaurant. It is presented as a showcase app but designed with real requirements in mind. Moreover, it attempts to demonstrate common features provided by many modern web apps (routing with and without guards, use of flex-box, theming, re-usable components, mock back end, …​).

The main features of the app are:

• Anonymous users can:

  • Book a table.

  • Create an event and invite some friends via email.

  • See the menu of dishes and make their own orders.

• Logged-in users in the role Waiter can also:

  • Access a restricted area to see and filter the list and details of all reservations and orders made by users.

MyThaiStar devon4ng Front-end Overview

In the previous section we have shown the aspect of the MyThaiStar server project and the services it provides.

In this section we are going to focus on the implementation of the front-end components, services and directives. We will show how MyThaiStar is created and how you can kickstart your own devon4ng client project with the devonfw framework.

The MyThaiStar project is hosted on GitHub and includes different technologies such as Java, .NET and Node for back-end solutions Angular and Xamarin as default clients.

The devon4ng Project

Using the devon4ng approach for the client project we will have the structure of a main Angular project as follows:

In the e2e folder will be all end-to-end tests.

In the node modules folder, all installed dependencies will be stored.

The src folder contains all the application code.

Finally, the rest of the files are configuration files for different technologies involved in the project.

Angular Folder Structure

Following the Angular style guide rules, the application has been structured this way:

• app

  • components

    • sub-components

    • shared

      • services

    • component files

  • main app component

• assets folder

• environments folder

• rest of angular files

As can be seen in this image:

Components

As we already saw in the previous chapter, the Angular architecture is based on four types of elements: components, services, modules and directives.

In this section we are going to focus on the components. We can distinguish them, because they all are named with the extension .component.ts.

Components represent a single element of the application, but can — at the same time — contain multiple components themselves. This is the case for components that are main views:

• app (the main component)

• home

• menu

• book-table

• cockpit-area

• some components for dialogs

These views have their own Teradata Covalent layouts to manage their contents, other components or tags that are displayed.

import {...} from '...'

@Component({
  selector: 'public-menu',
  templateUrl: './menu.component.html',
  styleUrls: ['./menu.component.scss'],
})
export class MenuComponent implements OnInit {
    methods implementation...
}

There are also components, which are part of a template and can be reused multiple times and/or in multiple places. This is the case for components like:

• sidenav

• header

• menu-card

menu-card is an element, that accepts menu information as input data displays this information as a card. This component will be reused for every single dish on the menu, so the best way to handle it, is to isolate its logic and template in a component, so the menu view just has to know about the existence of the component and the data it needs to work.

<public-menu-card *ngFor="let menu of menus" [menu]="menu"></public-menu-card>

To interact and navigate between the main views, Angular provides a Router that provides the functionality to move between URLs in the same app. Additionally it provides an HTML tag <router-outlet></router-outlet> that shows, which component has been navigated to. This router tag is placed in the main app component, at the same level as the sidenav and the header. This means, that these two components are on top of whatever the router shows. That is why we can always see the header, no matter what component we are displaying via the router.

Angular Material also provides a Tab component, which changes its content depending on which tab has been clicked on. An example for the usage of this component can be seen in the book-table view:

This component view shows a card, that contains a form for reservation or the creation of an event.

Services

Ideally, all logic should be taken out of a component. Only calls to services and minimal script interactions should be contained in a component. The services should then contain all the logic, for example, code that calls the server and so on.

MyThaiStar components consume those services, for example a price-calculator service, which is called when a costumer makes an order:

There are two special services in MyThaiStar, which serve a different purpose, than just being consumed by a component. They are:

• Authentication

• AuthGuard

• HttpClient

To secure the access to the waiter cockpit — which is a forbidden area for anyone who is not a waiter — MyThaiStar employs a service of authentication as well as a Router Guard.

Guards are services, that implement the CanActivate function, which returns a Boolean, indicating if a navigation attempt is valid or forbidden. If it is forbidden, the router stops navigation — if it is valid, the router navigates to the desired location. The authentication service serves as storage and validator for certain kinds of data, including usernames, roles, permissions and JWT tokens.

HttpClient — among other things — implements the management of HTTP headers. The workflow is exactly the same as with standard HTTP requests/responses, but here a token is added to a header, when specific, secured services are called. HttpClient has also been extended to handle errors, in case a token has expired or is corrupted.

With all of this correctly setup, we can log into to the waiter cockpit by entering the correct credentials. This way the logged-in state is set to true. The server will return a header with the correct token. As a result, the application will navigate to the waiter cockpit correctly.

Modules

Through modules, you can encapsulate whole functionalities or parts of the application. All Angular apps have at least one module: app.module. Angular encourages the use of more modules to organize all components and services. In MyThaiStar, every component and service is inside a module, so the app.module is only composed of other, smaller modules.

Running MyThaiStar Client

To run MyThaiStar, you have to have Node installed globally and Angular CLI. Once you have installed these dependencies, you can go to the project folder and run: yarn install. Once finished, you are ready to run the client via: ng serve.

If everything goes well, the console will output something like this:

Navigate to http://localhost:4200 to see the MyThaiStar app client running.

Now that we know, what can be done with devon4ng, we are going to show you step-by-step how you can make your own app from scratch. We will explain how to create components and services, how to set up routing and how each other element of the application works.

---

Next Chapter: devon4ng Components