igxTreeGrid Specification

1. Overview

The igxTreeGrid control is intended to visualize hierarchical data with consistent data schema in the tabular fashion of the igxGrid. Tree Grid's default styling follows Google's material design guidelines and is consistent with the igxGrid.

Objectives

Provide Ignite UI for Angular igx-treegrid component that supports the existing igx-gird features:

Sorting
Filtering
Editing
Paging
Virtualization - Row and column
Multi-column headers
Templates
Row and Cell Selection (select all included)
Column hiding
Column pinning
Column moving
Data-binding
Export to excel

Additionally the hierarchical nature of the data affords modifications to the following Grid features:

Column Summaries - for the Tree Grid summaries are also defined for the current context / level

2. User Stories

Developer

Story 1: As a developer, I want to be able to hide particular columns under certain conditions and show them again when these conditions change and it makes sense to have them visible again.

Story 2: As a developer, I want to be able to freeze some columns by default so the user is unable to move and reorder them around the grid.

Story 3: As a developer, I want to be able to specify if updating the content of the treegrid is allowed or not – is it editable or read-only.

Story 4: As a developer, I want to be able to show a particular node in the hierarchy upon initial rendering of the grid. I need to be able to set the number of levels which are initially expanded below the root level in order for that node’s parent to be expanded and thus the node be visible on initialization.

Story 5: As a developer, I want to be able to decide whether the expand state is persisted or not so when the grid is redrawn for any reason it either keeps this expanded state or resets it (sets it to the initial state).

Story 6: As a developer, I want to specify which columns are allowed to be placed to the left of the grid and serve as the one to represent visually the tree hierarchy. For some columns it makes a lot of sense to do so while for others it does not make any (e.g. imagine a company organization: names, positions and departments make sense to act as tree columns while salary, starting date and type of contract do not).

Story 7: As a developer, I want to be able to offer aggregated information for a given level in the hierarchy of the grid. This can be achieved through a special row that can be either on top of the group of entries as a header or just below it as a footer.

End user

Story 1: As an end user, I need a visual indication in the form of an icon, showing that a given node (root or non-leaf) has children. The icon can be enhanced to further show the specific number of non-leaf or leaf level children that the node has.

Story 2: As an end user, I expect that non-leaf and leaf level nodes are indented in a way that indicates how they relate to their parent.

Story 3: As an end user, I want to be able to filter the entries for a certain column so that only records matching the criterion that I have set are displayed. Filtering is applied to all hierarchy levels meaning that all nodes matching the criterion are shown and additionally their location in the hierarchy is reflected.

Story 4: As an end user, I want to be given the option to sort the records in the tree grid in ascending/descending order by any column, representing property of the entry. Sorting would work between siblings in the data hierarchy and will affect all levels and records recursively.

Story 5: As an end user, when I refresh the grid (or trigger another action that re-renders it) the old state of the layout (expanded/collapsed levels) should be retained and reflected after the grid is redrawn on the screen.

Story 6: As an end user, I want to be able to adjust the size of the columns so that they fit the content in a way that is suitable and useful for me.

Story 7: As an end user, I want to be able to pin a certain column to the left of the tree grid and this way it will always stay visible upon horizontally scrolling the grid.

Story 8: As an end user, I want to hide particular columns when my current needs dictate this. Of course, later on I need to be able to make these columns visible again.

Story 9: As an end user, I want to have the ability to reorder the columns in a way would help me deal with my current task without this causing any change to the hierarchy.

Story 10: As an end user, I expect that tree grids with a lot of records are split into pages with a certain number of items per page and indentation is properly carried over from the current page to the next one.

> ??? Story 11: As an end user, I expect that records can be moved in the hierarchy, which would affect the internal structure of the data shown in the tree grid.

Story 12: As an end user, I want to navigate the hierarchy with the keyboard using:

Up Arrow – go the row above
Down Arrow – go the row below
Right Arrow – expand the node if it has children
Left Arrow – collapse the node
and more... TODO

Story 13: As an end user, I want to have a visualization of the hierarchical belonging of my currently selected item in a toolbar and be able to easily perceive how it is related to the root level of the hierarchy (e.g. an indication similar to the path to a file on the file system).

Story 14: As an end user, I want to have a special row that serves to aggregate information for a set of entries in the grid. This special row can be either on top of the group of entries as a header or just below it as a footer. Such header/footer is usually employed to summarize the data for a certain level of the hierarchy.