Challenge Overview

Challenge Objectives

  • Build application frontend using angular and the provided Wireframe prototype

 

Project Background

In this project we’re building a web application to manage insurance policy details. Project frontend will be built using Angular (this challenge) using a set of UI components (NBDX) provided by the client and a working frontend prototype. Future challenges will build backend API, integrate frontend and backend and create tests for the frontend code base.

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

 

Technology Stack

 

Code access

 

We’re starting from an empty project - you can use “ng generate” to create the codebase. To use NBDX components see the getting started guide

 

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:

Start with dashboard design so that each component within the dashboard e.g. header, dashboard policy, customer, customer-activity each hooks up to different services. 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.

Only Start New Quote button is active - “View or edit quote”, “Pay now”, “Full Profile” buttons will be disabled. Header data can be static.

 

2. New quote screens

Once the CSR clicks on “START NEW QUOTE” they will be taken through a series of screens as listed below:

In the forums you’ll find an excel document with list of fields for each of the sections listed above. Details include NBDX component to be used, allowed values and validation requirements. Dropdown options will be served by the API as JSON and will be consumed by the Angular app (API calls can be mocked for now as we don’t have the actual API yet).

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.

 

General requirements

 

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

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

3.       Create a reusable component comprised of the following fields:

Title, Date of Birth, First Name, Last Name, mobile, email

Re-use this component when this set of fields are repeated.

4.       Follow best practices re the Angular Project Structure.

5.       When using NDBX components, create a module that imports & exports all the commonly used modules & providers and then import this modules in other modules.

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.       When designing forms attempt should be made to use Reactive Forms as the structure of our form will be very clean, without rooting around the template file. It is easy to write custom validators with Reactive forms. Testability, when using template-driven forms, we must create a component in order to test our forms and use one of the async testing helpers that Angular provides. When using reactive forms, this is not required, simplifying the testing process.

 

What To Submit

 

Submit the following:

  • Full source code for the built app

  • 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

  • Full source code for the built app

  • 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)

ELIGIBLE EVENTS:

Topcoder Open 2019

REVIEW STYLE:

Final Review:

Community Review Board

Approval:

User Sign-Off

SHARE:

ID: 30077687