Register
Submit a solution
Status: ‌Cancelled zero submissions

Challenge Overview

CHALLENGE OBJECTIVES

  • Build a ReactJS based desktop prototype for the dRISK web app.

  • Around 15 unique screens are in scope.

 

TECHNOLOGY STACK

 

MICRO FRONTEND FRAMEWORK REQUIREMENTS

This prototype must be developed following the Micro Frontend Framework. Micro Frontend best practices and guidelines must be strictly followed, which include but are not limited to the following:

  • We expect no code change in each application page to integrate these Micro Frontends in multiple containers (landing page)

  • Packaging of each Micro Frontend has to be independent. Please keep the project structure and build process in independent repository

  • Every application page navigation should check whether the user is set as Authenticated. If not authenticated, redirect to the error page (since we don’t have a login page now). Authentication is a cross-cutting concern that is owned by the landing page (container) that hosts these Micro Frontends. We expect router to inject into each micro frontend on initialization

  • Micro Frontend Inter dependencies - we recommend having them communicate or depend on each other as minimum possible. We understand from our use case following data needs to be passed b/w micro frontends which is cross cutting concerns, please make use of best practice (example: custom events) to decouple the applications:

    • Authentication token, Language selection and User Preferences object across frontends. 

  • Reusable Components as Library - make sure the shared UI component has only UI logic, and no business or domain logic. Example: we expect Task List components described below does not include domain specific attribute logic inside the component

  • Multi-lingual support at all levels of components. Multi-lingual should be extensible to any new language

  • Need to follow javascript integration approach

  • Navigation integrate together using JavaScript

 

MICRO FRONTEND PACKAGES

The following micro frontends should be built:

  • Package 1: Common & Dashboard

    • This is detailed in the screen requirements section

  • Package 2: Task List

    • This is detailed in the screen requirements section

 

API INTEGRATION & STATE MANAGEMENT

  • You need to implement all the necessary (mock) UI services and http service adaptors  to fetch data from JSON files. You must not hardcode any test data into the code. Please use the provided sample JSONs to mock backend calls with the http service adaptors.

  • You need to implement full state management following React’s best practices.

  • The expectation is that all pages should fully function and will be ready to plug with actual backend integration and deploy to next environments once we swap the mock services with real ones.

 

SCREEN REQUIREMENTS

All screens from design are in scope but some of the elements are removed or updated a bit, check the details below.

 

Package 1: Common

  • On app initialization, build dummy authentication for the user which will be replaced by an actual one during integration. Please create a standard Identity structure which will be used across the application to check if the user is authenticated

  • Service should be provided to Load / Save user preferences with the mock JSONs we provided

  • Header: this should be a component

    • Hamburger menu button

    • App logo

    • App name

    • Help button

    • Language selection dropdown: need to load / save language from user preferences

    • Notification bell icon

    • User avatar icon

  • Navigation Menu

    • When the hamburger menu button is clicked the app will open the list of tabs on the left hand side containing the tabs such as Dashboard, Search, etc…

    • Clicking on a tab will take the user to corresponding page

    • Clicking the hamburger menu again can hide the list of tabs

  • Footer: this should be a component

    • Just the copyright info

 

Package 1: Dashboard

This is the landing page for the application once the user logs in. This page should give a basic system information:

  • Each card / tile in design should be shown as a static image in the prototype for now, and each of them should have an overlay text saying “Coming soon”

  • It should be possible to rearrange the position of the 4 bigger “charts” via drag and drop. The state and position of these charts is retrieved from user preferences on page load

  • Each chart now has a 3 dot icon on the top right corner, please change it to a minus icon:

    • If user clicks the minus sign, the chart shrinks to a single line box with the title and a plus sign, and this one moves to the bottom of the page

    • The remaining charts are rearranged to fill in any gaps

    • Clicking on the plus sign of a minimized chart adds it back to the chart, but it will be appended to the end

    • The state and position of each chart must be saved into user preferences, refer to the widgets section in the provided json

  • Error handling:

    • User is not authenticated

    • User preferences could not be fetched

    • User preferences could not be saved

 

Package 1: User Details

Logged in users should be able to see his / her own details. When the user hovers over the avatar, a small popup should show the user’s name and OU code, along with text below that says “Click the user icon to show details”.

 

And when user clicks the avatar (user icon), the user details modal is shown which shows some header info and then 3 tabs of data:

  • dRISK Rights and Scopes

    • Use the data from the sections field, if the object is an empty array then show “No active dRISK Rights/scopes assigned currently.”

    • Please note, the number of rows for Roles and Rights per user can be >50. Hence the view should be able to handle this properly (with a scrollbar for example)

  • You are deputy of

    • Use the data from the sections field, if the object is an empty array then show  “You are not assigned as deputy currently.”

    • The number of rows can be > 15, so make sure the view can work with that

    • The name column uses the combination of first name, last name, orgUnitCode and userPid, the other column just use the corresponding fields from json

    • The table should support sorting (asc and desc)

  • Your deputies

    • Use the data from the sections field, if the object is an empty array then show  “You have not assigned any deputies currently.”

    • The number of rows can be > 15, so make sure the view can work with that

    • The name column uses the combination of first name, last name, orgUnitCode and userPid, the other column just use the corresponding fields from json

    • The table should support sorting (asc and desc)

  • Ignore the Download PDF button in design.

 

Package 2: Task List

  • Common features or properties crossing across UI components:

    • User Preference Object 

    • Language Selection -  should be dynamically changing text into selected language (without page refresh)

  • There are two types of task objects being used here:

    • Task Small Object (TSO)

      • The Task Object has been simplified to carry fewer details of the Task. This is essential when a page has to fetch 500+ task items from the server. The object has been aimed to shorten the size of an object, as a result the size of Task List is maintained minimum possible to fetch & display on screen

      • You’ll find such task objects in taskList.json, which will be loaded on Task List mocked service calls. Here’s the explanation of some of the fields which are not so obvious:

        • type: title of the task

        • status: to be used to show red/yellow bar on task, in terms of priority:

          • RED: High

          • ORANGE: Medium

          • GREEN: Low

          • GRAY: None

        • shortfallAmount.amount: amount as displayed in task

        • isExisting: to be used to show New or Old

    • Task Full Object (TFO)

      • This task object will have full & complete task attribute details of the Task. This object is fetched on demand when the user clicks/selects an individual Task item from the Task List.

      • Refer Task Full Object Mock JSON to mock the loading of object on click/selection of Task Item in Task List

  • Task list page:

    • Only My Task List tab is in scope

    • Data is loaded from the api (which returns a json in the format of taskList.json)

    • Each task in the list is currently showing the create date, we need to replace that to show the businessUnit field instead, the title will say Business Unit

    • Task List pages are expected to load and work with 500+ items, you could use caching where necessary to improve the performance. If there is more innovative way of addressing the performance issues or loading time of 500+ items, please feel free to implement

    • There will be 10 task items per page with lazy loading towards end of page scrolling. The simulated api call will get the top n number of rows and upon scroll the prototype should show a loading indicator at the bottom and load more, here is something similar to what we want to implement: https://cdn-media-1.freecodecamp.org/images/DSefnSg0oR-EoUpD0QlKsTPVc6yfX1mztNKR 

    • Search should be done via an API call which we’ll simulate by showing a loading indicator, and then load the data. You must have a mock service for this and you need to call it from the UI code.

    • In the filters section, make all the dropdown fields text input instead, and RE Amount should be a ranged value with low and high numbers.

    • Filtering will also trigger an API call, we need to simulate this by showing a loading indicator, then refresh the list of tasks. The same goes for Sorting. You must have a mock service for this and you need to call it from the UI code.

      • On Apply Filters, we should also save the filters to preferences (api call)

      • Whenever user navigates to Task List page, filters from preferences are applied automatically

      • When Clear Filters is clicked, remove filters from both the page and preferences (api call)

    • Users can select a few tasks first, then click Transfer, then the Deputy list will show up for users to select the other users to forward the tasks to (see 03.3_Tranfer Select Deputy.jpg). The list of deputies comes from userDetails.json.

    • State Management of Tasks (small and full objects) should be properly handled

    • Ignore the Download as PDF button

    • Error handling

      • User is not authenticated

      • Failed UI validations

      • Task Small Object (TSO) List could not be fetched

      • Task Small Object (TSO) List could not be fetched on page end scroll

      • Task Small Object (TSO) List is exhausted on page end scroll

      • Task Full Object (TFO) List could not be fetched

  • Task Detail - Overview

    • Clicking a task in the list will bring up the details view on the right side, with Overview tab being the default. You should be using the taskFull.json for this page.

    • You should mock the load of the full task object by showing a loading indicator and then the data.

    • Error handling

      • User is not authenticated

      • Task Full Object (TSO) could not be fetched

    • Here’s the data to use from json

      • Title: id and type

      • Subtitle: unit

      • “Risk Overview - Transaction” is static text

      • riskCode and riskEventDesc are used right below the static text, riskEventAmount.amount and riskEventAmount.currency is used on the right side

      • TRC: transactionRiskCode

      • One Day Trend: trend

      • UOL/Collateral: uol

      • Utilization: utilizationAmount.amount and utilizationAmount.currency

      • 1st RE Amount: firstRiskEventAmount.amount and firstRiskEventAmount.currency

      • Redemption Date: redemptionDate

      • Approve CL: approveClAmount.amount and approveClAmount.currency

      • In RiskSaver Since: inRiskSaverSince

      • Monitoring Amount: monitoringAmount.amount and monitoringAmount.currency

      • RM Details: reOriginal.rmUser

      • Risk Event Owner (RM): reOwner.rmUser

      • CSP Details: reOriginal.cspUser

      • Risk Event Owner (CSP): reOwner.cspUser

    • When More Details is clicked, the side view expands to full view, this is demonstrated with the Process tab (described below) but it applies to all the tabs.

  • Task Detail - Customer

    • Clicking the Customer tab will change the middle section to show customer info

    • The data is read from the customerDetails field and the data mapping is straightforward.

  • Task Detail - Comments

    • Clicking the Comments tab will show the comments, data is loaded from comments.json

    • Note there could be multiple attachments per comment

    • Ignore the 3 dot icon on each comment (don’t show it in your implementation)

    • Allow selecting files when posting a comment, but hide the emojis for now

    • Please implement state management of comments

    • Newly submitted comments should be shown in the list, it will show current user’s name and the text (Me)

      • Mock the service call to submit newly input comment object

      • Check newComment.json for a sample json

    • It is possible comments text are very long. The layout should be able to accommodate the long texts in rendering.

    • Error handling

      • User is not authenticated

      • Comments could not be fetched

      • Comments Failed UI validations

      • Comments could not be submitted

  • Task Details - Process

    • Clicking the Processing tab will switch to the page, data is from the same taskFull.json:

      • Risk Event Processing

        • Approved By: competencePerson

        • Risk Priority: riskPriority

        • URD: userReviewDate.date

        • PRD: personalReviewDate.date

        • SRD: systemReviewDate.date

        • Risk Event Classification: riskEventClassificationSavedValue

      • CSP Comment: cspComment object

    • Please implement state management of data on this page, and simulate the submit via a mock service call

    • Clicking Collapse will go back to the smaller view

    • The Cancel button doesn’t really make sense on this page, just ignore it for now.

    • Error handling

      • User is not authenticated

      • Data Failed UI validations

      • Data could not be submitted

  • Task Detail - Other Tabs

    • They are all disabled for now.

 

Notifications

  • Clicking the notification bell icon will show the list of notifications, data is from noitifications.json

  • Error handling

    • User is not authenticated

    • Comments could not be fetched

 

GENERAL REQUIREMENTS

  • Must use ReactJS and follow the provided design.

  • Separate Load & Save as components as we have complex scenarios to handle in loading as well as in saving.

  • Common scenarios where data is shared between components - Authentication, Theme, User preferences including Language preference, other reference data like drop down values etc. Please enable me to share this in context across all components.

  • Application Styling should be Theme/Skin based, clearly separating styles into CSS files.

  • The main content should have fluid width to fill all the available space, the minimum supported resolution is 1280*720.

  • The prototype must handle exceptions and communicate to users whether or not exceptions can be handled. User should never be clueless if some exception has raised

  • Although User input screens are minimum in the challenge scope, we expect you cover basic validation like empty input/selection, number validation etc.

  • Searching / filtering should work whenever applicable.

  • Pagination should be implemented as explained (scroll to load more).

  • Filtering/search/pagination happens on the server side so you need to pass the query parameters and the server is expected to return the pagination info (pageSize, total etc). Make sure you pass such parameters to your mock services.

  • Implement popup for confirmation and warning messages. Do NOT use browser alerts, but use custom styles popups as shown in the design

  • Show loading spinners when populating data from API / local JSON to UI

  • No linting errors

  • No errors with prod builds

  • You are expected to create a detailed README file including information on how to setup, run and verify your application.

 

CODE REQUIREMENTS

  • ES6 syntax is preferred, as Babel has been set up to handle transpiling the syntax to the current JavaScript standard.

  • Use .tsx extension for React components; using PascalCase for filenames. E.g., ComponentName/index.tsx. Make sure your linter is configured to work with tsx as well.

  • Do not create a single .css/.scss file for the whole app. Each component should have its own stylesheet file.

  • Ensure that there are no lint errors.

  • You’re free to choose between CSS & SCSS but you need to use flex instead of float.

  • Follow a clean folder structure.

  • Create reusable components.

 

JAVASCRIPT REQUIREMENTS

  • All JavaScript must not have a copyright by a third party. You are encouraged to use your own scripts, or scripts that are free, publicly available and do not have copyright statements or author recognition requirements anywhere in the code.

  • Use ES6 linter for code quality

 

LICENSES & ATTRIBUTION

  • Third-party assets used to build your item must be properly licensed and free for commercial use. MIT and Apache v2 licenses are ok, for any others please check with us to get approval first.

  • Sufficient information regarding third-party assets must be present in your documentation. This includes the author, license info and a direct link to the asset online.

 

BROWSER REQUIREMENTS

  • Windows: IE 11+, Chrome latest, Firefox latest, Edge Latest (Chromium based one)

  • Mac: Safari Latest, Chrome Latest, Firefox Latest, Edge Latest (Chromium based one)



Final Submission Guidelines

  • Full code that covers all the requirements.

  • A detailed README file including information on how to setup and run your application.

ELIGIBLE EVENTS:

2020 Topcoder(R) Open

Review style

Final Review

Community Review Board

Approval

User Sign-Off

ID: 30122027