an devon4ng application - Jorge-Dacal/devonfw-tutorial-sources GitHub Wiki

Table of Contents

An devon4ng Application

My Thai Star basics

As an example of how an devon4ng application is built we are going to show the My Thai Star application frontend project, that can be found in github.

My Thai Star application is a solution for managing the online booking and orders of a restaurant, it is addressed as a showcase app but designed with real requirements and, moreover, trying to serve as an example of common use cases in web apps (Routing with and without guards, use of flex-box, theming, re-usable components, mock back end…​).

mts

The main features of the app are:

  • Anonymous users can:

    • Book a table.

    • Create an event and invite some friends to it via email.

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

  • Logged users also can:

    • If the user has the role waiter, he will be able to access to a restricted area to see and filter the list and details of all the reservations and orders made by the users.

My Thai Star devon4ng Frontend overview

What we have shown in the previous section is the aspect of a My Thai Star client app that consumes the services created with the devon4ng server solution.

From now on we are going to focus on the implementation of the components, services and directives to show how is it formed and how you can create your own devon4ng client project with devonfw framework.

My Thai Star project is hosted on github and includes different technologies such as Java, .Net and Node for backend solutions and Angular and Xamarin as default clients.

The devon4ng project

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

project main files

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 config files for the different technologies involved in the project.

Angular folder structure

Following Angular style guide rules, the structure of the application has been built 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:

app structure

Components

As we already saw in the previous chapter, 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 are a single element of the application, but it can have, at the same time, more components in them, this is the case for the components that are main views: app(main component of the app), home, menu, book-table, cockpit-area or the components for the dialogs. These views have their own layout from Covalent Teradata to organize its contents as well as other components or tags to be displayed.

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

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

Even though, there are also components that are an element of a template that has a complete meaning by themselves and can be reused multiple times and/or in multiple places, this is the case of components like, sidenav, header or menu-card, which is an element that accepts an input data with the menu information and displays it as a card, this component will be repeated for every single dish on the menu, so the better way to handle this is to isolate its logic and template in a component so the menu view just have 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>
menu cards

To interact and navigate between the main views, Angular provides a Router that provides with functionalities to move between URL’s in the same app, in addition, it provides an HTML tag <router-outlet></router-outlet> that will show the component that 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 through the router.

Also, Angular Material provides a tab component, which can show content depending on which tab you clicked, but they are in the same component, an example of usage of this kind of components can be seen in the book-table view:

book table

This component view shows a card that can show an instant reservation or the creation of an event.

Services

Ideally, all the logic should be taken out of the component, and let there only the calls to the services and minimal script interaction. Services is where all the logic should be, including calling the server.

MyThaiStar components consume this services, as could be the price-calculator when a costumer makes an order:

price calculator

There are two exceptional cases in MyThaiStar of services that serve with a different proposal than serve to a specific component: Authentication and AuthGuard and HttpClient.

To secure the access to waiter cockpit, which is a forbidden area to anyone who is not a waiter, MyThaiStar counts with a service of authentication and a Router Guard.

authentication

Guards are services that implements CanActivate function which returns a Boolean indicating if the navigation is valid or forbidden. If is forbidden, the router stands still where it is, and if it is valid, it navigates correctly. The authentication service serves as a storage and a validator of certain data regarding username, role, permissions and JWT token.

HttpClient is an envelope of Http that implement the management of headers. The workflow is exact the same as the standard Http but as the project needed to incorporate a token to every call to a specific secured services, then, this token needed to be added and removed depending on call to the server, also, it has been extended to handle the error in case the token has expired or corrupted.

authorization header

When all of this correctly setup, we can do a log-in to the waiter cockpit, and if entered the correct credentials, the logged state will set to true, the login to the server will be correct returning the token and the header with this token will be setted giving as a result the correct navigation to the waiter cockpit:

waiter cockpit

Modules

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

Running MyThaiStar client

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

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

webpack

Now yo can go to your browser to: localhost:4200 and there will be MyThaiStar client running.

Now we know what can be done with devon4ng, we are going to see step by step how to make from scratch your own app, explaining every process to create components, services, routing and each element of the application.


Next chapter: Angular Components

⚠️ **GitHub.com Fallback** ⚠️