YAML Config Editor - UI Prototype Update Challenge

Challenge Objectives

• Update the UI Prototype to be more user friendly
• Integrate the UI Prototype with the real backend REST API
• Add e2e and unit tests to the UI Prototype (optional, and will reward you $400 if you implement this and win)

Project Background

“Configuration as code” is a technique to store environmental variables, feature flags, and other configuration items in an SCM the same way the code is stored.   When the code is deployed,  the CI process generates the specific configuration for the proper environment from the config SCM.  Then the CD process deploys it to the appropriate hosts alongside the new code.   The significant advantage of this approach is that configuration changes are tracked over time which is critical to support.   

Our client desires to build a configuration tool that allows developers and DevOps a standard and hierarchical approach and intuitive  form like User Interface for managing and maintaining complex configuration environments.   This tool would be called by the DevOps pipeline to generate JSON configurations for deployment to environments.   Spring Cloud Config project will serve as inspiration for this project.  

In this project, we are building a yaml editor, which is hosted by a NodeJS server running in a docker container. When user requests the UI with an HTTP GET request from the browser the NodeJS server (HapiJS) delivers the index.html and all static assets for the Angular application.  Once the application is running in the browser, the user wants to use it to edit some config files for user's deployed application. For this the user will need to give a git repo url and login credentials. The app would then send a message back to the NodeJS server to perform a shallow clone (we do not need history here) from the git origin (much the same that Jenkins does when it builds your source code).
Once the repo is cloned the nodejs server can deliver a file list to the browser (only YAML files are delivered, the other files are ignored). The app can either select  a file to edit, create a new one, or remove a file. The server either reads (or creates a new file) and sends the content to the browser. And we only need to work with files in the root directory of git repo, no need to support folder for now.  The app should not work on the master branch of the git repo, it should work on a default 'admin' branch. 

The app then parses the content and allows the user to edit/create properties within the default block, or select properties in the default block to copy to an environment for edit/override, or select an environment from a list of defined environments to add to this config file.
 

Technology Stack

• TypeScript
• Git
• Node 10+
• Angular 6+

Code access

The prototype submissions from previous challenge will be posted in the forum. 
The backend REST API submission will also be posted in the forum. 
 

Individual requirements

We previously run this challenge: http://www.topcoder.com/challenge-details/30070647/?type=develop&noncache=true to create the UI prototype. 
But the UI in the 1st place submission is not very user friendly, and although the UI in the 2nd place submission looks better, it has many bugs. 

In this challenge, you can either start from scratch or start from either submission from previous challenge. 

1. We have the following requirements for the UI: 

• Angular Material should be used for the base UI framework, this will provide a consistent look/feel with client's other apps and will allow client to apply themes.  Also, animations for transitions should be supported. 
• NgRx for internal app state (file list, file contents …) should be used. 
• Don't use abbreviations on property or method names within the code. (e.g. env should be environment). 
• login screen - the UI from 2nd place submission looks fine for us
  
  Note that the username input should be changed to an auto-complete input box, and it should call the /userTypeAhead?prefix=xxx to fetch the auto-complete data. 
• List Screen - the UI from 2nd place submission looks fine for us:
  
• New or Edit Page - we like the tree-view from 2nd place submission (which is a Angular Material Tree Component, and you should keep using this component in your submission). 
  
  But we want to make some changes to this UI:
  • The tree view should now has "default" and "environments" top tree nodes, and these two nodes are shown by default. 
  • All tree nodes will have an option dropdown menu (like the current "..." button on the right side of the tree node). 
  • When user left click a tree node, if it's a leaf node, display its name, valueType, value and comment on the right side of the page, and otherwise, display its sub-tree (including current node) in a readonly YAML view on the right side of the page. 
  • For the "default" tree node, user can add nested properties. It will have dropdown menu to "Add Property" and "Edit" (no Delete). 
    • When "Add Property" menu item is clicked, a panel will be shown on the right side of the page to add a child property. (The panel content will be similar as current add-property modal dialog). User is able to enter "name", "value type" (which can be object, number, boolean, or string), "value" (no need to be displayed if the value-type is object, and comment. 
      
    • When "Edit" menu item is clicked, a panel will be shown on the right side of the page to allow user to edit the comment for the "default" tree node.
    • Note that the panel should have a title for each action above. 
  • For the "environments" tree node, user can add specific environment by selecting from a dropdown list. It will have dropdown menu to "Add Environment" and Edit (no delete). 
    • When "Add Environment" menu item is clicked, a panel will be shown on the right side of the page to select a new environment to add as the child node. There should be a comment input as well. 
    • When "Edit" menu item is clicked, a panel will be shown on the right side of the page to allow user to edit the comment for the "environments" tree node.
  • For the specific environment tree node (under "environments"), user can add nested properties just like the "default" node. It will have dropdown menu to "Add Property", "Edit", "View Compiled YAML" and "Delete"
    • When "Add Property" menu item is clicked, a panel is shown to add a child property. (The panel content will be similar as current add-property modal dialog for specific environment - user can only select properties added in the same level downward from the "default" tree node).
    • When "Edit" menu item is clicked, a panel will be shown on the right side of the page to allow user to edit the comment. 
    • When "View Compiled YAML" menu item is clicked, it will fetch the properties from "default" node and then override them with its own properties, and then show the results as a readonly YAML view on the right side of the page.
    • When "Delete" menu item is clicked, a confirmation prompt should be displayed, and if user selects OK, the node will be deleted.
  • For the other tree nodes, there will be dropdown menu to "Add Property" (for nodes of object type only), "Edit" and "Delete". 
    • "Add Property" menu item - if it's in "default" tree, the panel will be the same as the "Add Property" panel for "default" tree node; and if it's in specific environment tree, the panel will be the same as the "Add Property" panel for specific environment tree node. 
    • "Edit" menu item - the panel is similar as the "Add Property" panel, except it will edit the current node. Note that if user changes the name or valueType of node in the "default" tree, you should simply remove the corresponding nodes in the specific-environment tree.  
    • When "Delete" men item is clicked, a confirmation prompt should be displayed, and if user selects OK, the node will be deleted.

2. Instead of calling the mockup REST API, the UI Prototype should call the actual backend REST API instead. 
Note that input validation and back-end error should be handled properly on the UI as well.

3. Add e2e and unit tests to the UI prototype submission. This requirement is optional, and we will reward you $400 if you implement this and win. 
The unit tests should be implemented with Karma + jasmine (standard Angular tests)
The e2e tests should be implemented with cucumber+ protractor. 

Note that both e2e and unit tests should have at least 80% coverage. 

HTML Requirements

- HTML should be valid HTML5 compliant.
- Provide comments on the page elements to give clear explanation of the code usage. The goal is to help future developers understand the code.
- Please use clean INDENTATION for all HTML code so future developers can follow the code.
- All HTML code naming should not have any conflicts or errors.
- Element and Attribute names should follow snake-case and use a "-"  to separate multiple-word classes (i.e.. "main-content")
- Use semantically correct tags- use H tags for headers, etc. Use strong and em tags instead of bold and italic tags.
- No inline CSS styles- all styles must be placed in an external stylesheet.
- Validate your code- reviewers may accept minor validation errors, but please comment your reason for any validation errors. Use the validators listed in the scorecard.

CSS Requirements

- Use CSS3 Media Queries to load different styles for each page and don't build different page for different device/layout.
- Provide comments on the CSS code. We need CSS comments to give a clear explanation of the code usage. The goal is to help future developers understand the code.
- Please use clean INDENTATION for all CSS so developers can follow the code.
- All CSS naming should not have any conflicts.
- As possible use CSS3 style when create all styling.
- Use CSS to space out objects, not clear/transparent images (GIFs or PNGs) and use proper structural CSS to lay out your page.
- Only use table tags for tables of data/information and not for page layout.
- Use SCSS / SASS for styling 

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 typescript and linter for code quality

Licenses & Attribution

- Third-party assets used to build your item must be properly licensed or free for commercial use. MIT, some modified BSD, Apache 2 licenses are ok, but if a library is not commercial friendly you need to get our 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.

Screen Specifications

- Must support desktop. 
- Must support retina display.
- Layout width should be fluid.

Browser Requirements

- Desktop: IE11+, Latest Firefox, Latest Safari & Chrome Browsers (Mac & Windows).

Deployment guide and validation document

Please provide detailed deployment and verification guide. 
 

What To Submit

• Updated UI Prototype Code
• Detailed Deployment Guide and Verfiication Guide

Final Submission Guidelines

Submission Deliverable

• Updated UI Prototype Code
• Detailed Deployment Guide and Verfiication Guide