YAML Config Editor UI Prototype Challenge

“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.

In this project, we are building a yaml editor, which is hosted by a NodeJS server running in a docker container. 

In this challenge, we are resposible for creating an Angular 6+ single page application for the following pages: 

1. Login page - for user to enter username, password and repository URL. Error should be displayed if it receives any error from API. 
2. Dashboard page (after login) - list all the files in the repository.  And for each file, user is able to delete it or edit it. And there should be like for user to add a new file as well.  A confirmation dialog should be displayed if user deletes a file. 
3. YAML File Edit Page (shown after user edits or creates a file)

• there will be two sections: default and environments
• user can add, remove or edit a property in the default section, and the property value can be a string, boolean, number or nested sub-properties. So on the UI, the user should be allowed to select the type of the property value. And for the nested sub-properties, it should allow user to manage them just like the top-level properties above. 
• in the environments section, user can add or remove an environment. Note that user can only select environment from a dropdown list.  
• For each specific environment, user is able to select a property from a dropdown (collected from the default section) to override the value. 
• For each property or sub-property in all sections, user should also able to add a comment. 
• The page should have a Save button to save the changes. And a confirmation dialog should be displayed if user leaves the page without clicking the Save button. 

The swagger file of the REST APIs will be provided, and you should use json-server to create mockups. 
The file received from and sent to the REST API will use the format below (the comments are stored in a special $comment property, and if a simple property has comment, its value will be stored in a special $value property): 

{
    "default": {
        "$comment": "all known properties are defined in the default block. \n The most common values are assigned in the default block",
        "myProp": {
            "$comment": "my property",
            "$value": "value 1"
        },
        "appVer": "0.1.5",
        "token": {
            "expiration": 10000,
            "expired": false
        },
        "host": {
            "$comment": "The url domain for the deployed environment",
            "$value": "www.mobilex.com"
        },
        "dataService": {
            "$comment": "url to access JSON Web API",
            "$value": "pd01.mobilex.com/data"
        }
    }, 

    "environments": {
        "$comment": "specific environments can override the default values 1 property at a time",
        "local": {
            "host": "localhost"
        },
        "dev": {
            "$comment": "environment for developer testing of fully compiled and integrated application",
            "host": "dev.mobilex.com"
        },
        "qat": {
            "$comment": "qat team validates all compiled artifacts in separate test ",
            "host": "qat.mobilex.com",
            "dataService": "pd03.mobilex.com/data"
        },
        "staging": {
            "host": "qat.mobilex.com"
        },
        "prod": {

        }

    }
}

Note that when the YAML editor page loads the config file, the page should be populated properly, and when user saves on this page, a JSON file with similar format should be created (with all those comments as well) and send to the API. 
The backend is responsible for the conversion between the YAML and JSON formats. 

Prototype Requirements

- Please create a mockup backend using json-server, the Swagger file will be provided to you.
- Must use Angular 6+ and Material Design components
- The pages should clearly indicate invalid input data to users, for example: on login screen if users hit login without entering username, the textbox should be highlighted in red with an error message too
- Must follow Angular best coding practices
- Create README.md file that explains your UI prototype structure
- Your submission must follow the Responsive UI best practice

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

Final Submission Guidelines

Deliverable
- Source Code
- Deployment Guide and Verification Guide