CSR Policy app - [Angular] Integration

Challenge Objectives

• Integrate application frontend and backend

 

Project Background

In this project we’re building a web application to manage insurance policy details. Project frontend will be built using Angular (previous challenge) using a set of UI components (NBDX) provided by the client and a working frontend prototype. Backend is build with NodeJS app. This challenge will integrate frontend and backend and in future challenges we will create tests for the frontend code base.

Note that code quality is very important in this project and will be reviewed thoroughly.

 

Technology Stack

• Angular 5

• NBDX components

• NodeJS

 

Code access

 

Project repository access info is provided in the forums.

To use NBDX components see the getting started guide

UI prototype is deployed at https://pure-plateau-33172.herokuapp.com

Backend API specification (swagger) is available in the project repository.

 

Individual requirements

 

1. Landing page (view policy)

Whilst on the dashboard, the CSR can see a summary of Motor Insurance policy that the customer on phone is related to. From the dashboard CSR has option to start a new Motor Quote as shown below:

Our backend does not have any policies by default, so update it to load one policy (from a json file) on start and use that policy ID to show all the data in the landing page (hardcode the policy ID in frontend).

Relevant api calls are

GET/policy/{policyId}

GET/customer/{id}

In this screen we need to replace the custom table component that renders “Activity” table with the NDBX table component. This component doesn’t support images in cells, so we don’t have to render icons in the first column.

 

Then from there on, the requirement is that CSR clicks “START NEW QUOTE” and proceeds to get a Motor Insurance Quote from within the CSR app.

 

2. New quote screens

Once the CSR clicks on “START NEW QUOTE” they will be taken through a series of screens as listed below (these are wireframe screens, not UI prototype):

• Quote Acceptance / Screener questions (https://designchief.github.io/ai-internal-app/quote)

• Personal Details (https://designchief.github.io/ai-internal-app/quote/quote-customer)

• Car / Vehicle Details (https://designchief.github.io/ai-internal-app/quote/quote-vehicle)

• Driver details (https://designchief.github.io/ai-internal-app/quote/quote-driver)

• Discounts (https://designchief.github.io/ai-internal-app/quote/quote-cover)

 

Relevant API calls are

POST/policy

POST/policy/{policyId}/customer

POST/policy/{policyId}/vehicle

POST/policy/{policyId}/driver

POST/policy/{policyId}/cover

POST/policy/{policyId}/additionalDriver

POST/policy/{policyId}/activity

POST/policy/{policyId}/pay

POST/policy/{policyId}/cancel

All lookup endpoints

There are a few changes to the UI required in these screens:

1. Each step should have a separate URL route (same names as wireframes listed above)

2. In the driver details step, user should be able to add multiple claims and multiple drivers. Questions “Would you like to add a named driver to your policy?” and “Have you made any claims in the last 5 years?” should be used to add another driver/claim

3. Progress bar component doesn’t allow moving between steps, so we want to add a back button to the left of the ‘Next’ button in all steps except for ‘Acceptance’. Clicking the back button should lead to the previous step with all the data prefilled - load it from the api.

 

General requirements

 

1. All api actions should show a spinner (NDBX component)

2. All api errors should be displayed in a modal window (NDBX component)

3. Cross Browser compatibility – angular app should work with IE 11 and latest version of Google Chrome.

4.       Unit tests for the components aren’t required in this challenge but will be built in the next challenge.

5.       Follow best practices re the Angular Project Structure.

6.       Use Services - Strive for complete segregation between the View implementation and service call. In the UI component, keep code only related to view, and delegate to a service to make the backend calls and for any functional logic.

7. Validations, as in basic form level / client side validations (including common regular expressions for input fields like emails, date of birth can’t be in future) will need to be highlighted like so below, using NDBX standard style and behaviour.

 

What To Submit

 

Submit the following:

• Full source code for the updated app (frontend and backend)

• README.md file explaining application configuration and deployment

• Validation.md - containing any details required for validation of requirements (if any), like sample data, demo video link (optional), etc. You can document any additional coding style followed by your submission that we should consider using in future challenges (ex if it makes component testing easier, api integration is easier, etc)

Final Submission Guidelines

Submit the following:

• Full source code for the updated app (frontend and backend)

• README.md file explaining application configuration and deployment

• Validation.md - containing any details required for validation of requirements (if any), like sample data, demo video link (optional), etc. You can document any additional coding style followed by your submission that we should consider using in future challenges (ex if it makes component testing easier, api integration is easier, etc)