Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
HParam UI: update ColumnHeader type (#6346)
## Motivation for features / changes The goals is to allow for dynamic HParam columns in the data table. This means that we cannot have an enum like ColumnHeaderType be the unique identifier for the column headers because we cannot encapsulate all possible hparams into an enum. ## Technical description of changes This change adds a name and displayName field to the ColumnHeader interface. The goal here is to make name be the unique identifier for columns. However, this PR does not use these fields at all. It simply adds them. THERE IS NO FUNCTIONAL CHANGE in this PR. Upcoming changes will switch the code over to start using the name as the unique identifier and display the displayName. (For POC to see how this change fits in googlers see cl/526767686) ## Screenshots of UI changes (or N/A) N/A ## Detailed steps to verify changes work correctly (as executed by you) POC works ## Alternate designs / implementations considered (or N/A) There were many alternatives considered. In fact I do not believe this is going to be the final structure. One option is to remove the type and add a category field export interface ColumnHeader { name: string; displayName: string; Category: ColumnCategory(STATIC, HPARAM, METRIC) enabled: boolean; } However, deciding how to calculate the value based on hardcoded name strings does not seem ideal. Another option is to have a hierarchy. I expect it to look like this: Interface ColumnHeaderBase { name: string; displayName: string; type: ColumnHeaderType; enabled: boolean; } export interface StaticColumnHeader extends ColumnHeaderBase{ category: “STATIC” } export interface HParamColumnHeader extends ColumnHeaderBase{ category: “HParam” source: enum(data, config,....); differs:boolean; } ColumnHeader = StaticColumnHeader | HParamColumnHeader This may be the final form that we go with however, we are not sure the source and differs attributes need to go here or somewhere else yet. All code which works with the type defined in this PR will work with this proposal as well. Lastly, there is the option which is the same as the hierarchy option above but with StaticColumnHeader being the only interface with a "type" attribute. This is a valid possibility but, I have decided that it just adds unnecessary complexity by requiring a type check in many more places.
- Loading branch information