SLD Editor Challenge #3

Challenge Objectives
RCS is an Asset Reliability Centered Business Performance Tool, specifically designed for Power Grids and Substations asset reliability management. For this project, we are going to run a series of prototype challenges to build a web based UI for the tool.
 
Challenge Objectives
There’s an important module called SLD (Single Line Diagram) editor in the tool, which is an editor used to create diagrams.
 
In the previous challenges, we have implemented the basic functions of the SLD editor using GoJS and a demo web app in Angular.
 
For the purpose of this challenge, we need to take another step forward to make it more production ready. Please keep reading to find out more details.
 
Technology Stack

• GoJS
• AngularJS 6
• HTML5
• Javascript
• CSS

 
Challenge Requirements
Max Connections
Please carefully check section 4.1 of the spec and update the implementation to make sure each widget will only have the mentioned max number of connections.

Unique Key
Each added widget will need to have a unique key to be saved in the sldReference in the json . This field is readonly and cannot not be modified. Note you may use the auto generated label as the unique key if label is garanteed to be unique, but keep in mind that label can be modified but the key (sldReference) can NOT.
 
Connector Stability
Right now in the tool when we drag widgets around in editor they change their connector (top to bottom, left to right, or vice versa). This shouldn’t be happening since connector points are supposed to be stable and no matter how we drag the widgets the connector points should not automatically switch to other ones in the same widget. Even though this sometimes results in overlaps of lines / widgets but that’s fine.
 
For example, this is wrong since the connector point moved: http://take.ms/rq8fC
 
JSON Representation of SLD
The major focus of this challenge is to create and maintain the json representation of the SLD.
 
First, each type of widget should have a template of json fields that will indicate the fields the widget can have, please check GetAssetProprtyById.json for an example. For now, assume all widgets will have the same fields, but you have keep a separate template file for each type of widget instead of sharing a common one since we’ll shortly replace some of them with templates containing different fields. Whenever a widget is added, it will have a copy of the fields from its template and its values for the fields (most of these values will be editable soon so it’s important that different widgets of the same type have their own copies of data).
 
Whenever a new SLD is created, a json file that follows the structure of GetSustationById.json should be created, for empty diagrams this json will not have meaningful values for the fields, but as more widgets are added to the diagram, this json must be updated real time. There are some key fields in this JSON that must be manipulated by this tool:

1. "seralizedSld": under this key you should save all information (widgets, their positions, connections, etc.) of the SLD so that you can reconstruct the exact diagram from this field later.
2. “busbars”: for any busbar widgets added to the SLD, they should be added to the “busbars” field, the fields for a busbar widget will be copied from the template for that type of widget.
3. “psLs”: for any power supply (power supply and motor) and load widgets added to the SLD, they should be added to the “psLs” field, the fields for a power supply or load widget will be copied from the template for that type of widget.
4. “allComponents”: any other added widgets fall under this field in the SLD, again the fields will be copied from the template for that type of widget.
   1. Please note that ideal cable is a special component not present in the widgets panel, it actually refers to the line that connects two widgets. So for example: say there are 4 components and 6 lines connecting them, we’d have 6 ideal cable components in the json. We should also have a template of fields for ideal cable, and such fields should be copied to the json whenever a new connection is made.
5. For each of the widget we must make sure the “sldReference” field refers to the unique name of that widget.
6. For each of the widget that can have no more than 2 connections, we need to update the “connectedComponentsFirst” and “connectedComponentsSecond” fields to refer to the connected widgets.
7. For each of the widget that can have more than 2 connections, we need to update the “connectedComponentsList” field to refer to all the connected widgets.
8. “outageAreasList”: this field contains all outage areas in the SLD.
9. Please note this json structure must be kept in sync with the SLD at all times, meaning it’s an exact representation of the diagram.

 
Menus
We need to update the menus to meet our requirements. Please note that any menu / sub-menu not mentioned below should be removed.
 

1. Equipment registry: no changes needed.
2. Configuration:
   1. Import SLD: this will import the exported json file and re-create the exact diagram from which the json was exported.
   2. Export SLD: this will export the in-memory json structure to a json file that the user can save to the local file system.
   3. Import equipment data: no changes needed.
   4. Export equipment data: no changes needed.
   5. Export SLD as image: no changes needed.
   6. Print Diagram: no changes needed.
3. Edit:
   1. Select all: no changes
   2. Rotate: no changes
   3. Toggle: switches to the next state
   4. Delete: no changes
   5. Cut: no changes
   6. Copy: no changes
   7. Paste: no changes
   8. Undo: no changes
   9. Redo: no changes
   10. Reset label positions: no changes
   11. Alignment: no changes
4. View:
   1. Show in full screen: turn the browser into full screen mode
   2. Show grid: no changes
   3. Show labels: no changes
   4. View information explorer: no changes
   5. Color connected component: on click all connected component will be highlighted
   6. Shade by outage area: right now outage areas are created as colored rectangles, that’s not right, we need to update the implementation such that outage areas are invisible by default, and by checking this menu all outage areas will show up. And instead of whole blue box we should just show it with a blue border only.
   7. Shade by impact area: no changes for now
   8. Shade by risk area: no changes for now
5. Zoom: no changes
6. Analysis - keep all sub-menus disabled except for the below mentioned ones:
   1. Assign reliability data: this menu will trigger the app to read some values from a local json files and update these fields into the selected widget’s data, the update will happen in background but once done a toast saying "reliability data updated" should be shown. The reliability data json will have 3 fields which will be updated into widget data: condition, importance and risk.
   2. Simulate clear fault: this menu will work like the same context menu but we need some updates to it. Right now it’s only changing the color of the selected widget, we need to update it so that it changes the color of  all connected components as well. Besides, such color changes should be updated into the json structure in real time. Similarly when user clicks somewhere else the colors will be reverted, and in such case the json structure needs to be updated in real time as well.
   3. Simulate isolate fault: same as above
   4. Simulate isolate for maintenance: same as above
7. Help:
   1. Key shortcuts: show a popup that lists all keyboard shortcuts for all operations
   2. Help: no changes

 
Context Menus

1. Reliability figures: right now this menu shows a popup with static info. In this challenge please update this menu to pull the following fields from the json data associated with the widget instead:
   1. condition
   2. importance
   3. risk
2. Simulate clear fault: same changes as the one mentioned in the Menu section
3. Simulate isolate fault: same changes as the one mentioned in the Menu section
4. Simulate isolate for maintenance: same changes as the one mentioned in the Menu section
5. Edit Metadata: right now 3 of the widgets support metadata editing, we need to make sure that:
   1. on the edit metadata popup, change the Serial Number field to SLD Reference, and make it readonly (read from the json)
   2. when the edit metadata popup shows up, it shows values for the fields from the data of that equipment
   3. when user changes and saves any of the field values, they should be updated into the json so the exported json will always have the most up to date values.

 
General Requirements
The following requirements should already be covered in the previous challenge, just make sure you don’t break any of them:

• Make this editor reusable as an Angular 6 component, and demonstrate this using an Angular 6 based web app. We plan to integrate this editor into another bigger Angular 6 web app later so making it reusable / easy to integrate is important.
• You don’t have to worry too much about the overall look & feel of the editor / web app, just make sure the above mentioned features are working properly on a simple UI.
• You are expected to create a detailed README file including information on how to setup, run and verify your application.

 
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 be in lowercase and use a "-" or camel naming to separate multiple-word classes (i.e.. "main-content", or "mainContent)
• 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.

 
Code Requirements

• 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.
• 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.
• All CSS naming should not have any conflicts.
• You’re free to choose between CSS & SCSS but you need to use flex instead of float.
• Follow a clean folder structure. We should try to keep gojs core library untouched and only create extensions to support what we need.
• Use CSS3 Media Queries to load different styles for each page and don't build different page for different device/layout.
• Use CSS to space out objects, not clear/transparent images (GIFs or PNGs) and use proper structural CSS to lay out your page.
• Make sure npm run build works without any errors.

 
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

• Developers need to follow GoJS licensing terms.
• 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
Mac: Safari Latest, Chrome Latest, Firefox Latest
Tablets: Safari / Chrome on iPad, Chrome on Android Tablets
 
Documentation
Register to download the following documents we provided in the forum

• Base code
• Functional Spec for SLD
• Sample JSON files

 

Final Submission Guidelines

• Full code that covers all the requirements.
• A detailed README file including information on how to setup and run your application.