addGroupBy

[bryanmylee]

Certain interactions are still missing.

Remaining tasks:

• Control the ids to groupBy with view model extensions.
• Recursive grouping of subRows.
• Test interactions with other plugins.

Closes #13.

[coveralls]

Pull Request Test Coverage Report for Build 2365065789

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 31 unchanged lines in 4 files lost coverage.
• Overall coverage decreased (-0.3%) to 73.936%

---

Files with Coverage Reduction	New Missed Lines	%
src/lib/headerCells.ts	1	92.86%
src/lib/headerRows.ts	6	91.15%
src/lib/bodyCells.ts	8	77.78%
src/lib/bodyRows.ts	16	78.16%

Totals
Change from base Build 2340787892:	-0.3%
Covered Lines:	353
Relevant Lines:	478

---

💛 - Coveralls

[bryanmylee]

There are some issues with the sequential plugin transforming model when using filters and groupBy.

Filters need to be processed before addGroupBy to ensure that aggregate values on group rows are updated.

However, this causes a state drift when relying on the matches prop set of the addTableFilter plugin for BodyCells.

Matches are determined by tracking the cell rowColIds that match the filter. However, these ids will drift when addGroupBy transforms the rows and changes the ids.

One solution is to expose an external facing id prop with semantic meaning (i.e. sub-row structure with >) while keeping track of an internal unique uuid. However, we risk adding extra complexity to the cloning mechanisms when deciding whether the uuid should be copied or re-generated. i.e. when does a copy create a "new" unique object?

Another solution would be to allow plugins to define extra name-spaced static properties on components which should be preserved when being transformed by other plugins.

This would allow a plugin to define a tracking ID on a component if needed, and other plugins should make a best-effort attempt to preserve the meaning semantically and indiscriminately.