WIP: PivotGrid

[David-Moreira]

No description provided.

[stsrki]

What is the use-case for rows? Why do we need to define them?

[stsrki]

I understand now what you wanted to do. It has an API similar to the SF.

[David-Moreira]

All the same uses cases as this API
enum Area {
Row, // it will be shown in a row header and grouped by this => PivotGridRow
Column, // it will be shown as a regular column, just like DataGrid => PivotGridColumn
Data, // it will be used for the summary => PivotGridValue
}

[stsrki]

Pivot columns should be defined the same as for the DataGrid. By using the Field parameter. To define grouping and summary we need to introduce the Area, and SummaryType parameters.

enum Area {
  Row, // it will be shown in a row header and grouped by this
  Column,  // it will be shown as a regular column, just like DataGrid
  Data, // it will be used for the summary
}

when Area.Data is defined we need to have SummaryType

enum SummaryType {
  Sum,
  Count,
  // etc.
}

[David-Moreira]

I personally prefer to explicitly define components
over
enum Area {
Row, // it will be shown in a row header and grouped by this
Column, // it will be shown as a regular column, just like DataGrid
Data, // it will be used for the summary
}
Easier to segregate responsabilities... instead of having a big component that does everything. But if you'd rather have that area api all the same to me.

Didn't I Already introduce the Field Parameter?

SummaryType.. Can be named GroupType or AggregateType? Summary seems weird? Is that Pivot terminology?

I haven't worked on this for some time, I just redid the stuff now on master to keep up with the branch easily.
BUt yea, still very early dev, keep throwing some tips/suggestions if you have any. :D

[stsrki]

I realized later that you used components for the same thing that I wanted to have with parameters. It is OK to proceed that way. My only concern is that it will have an API that is different from our DataGrid.

[David-Moreira]

Hmm what about this API, would this be closer while still maintaing the component approach?

<PivotGrid TItem="Employee" Data="inMemoryData">
    <PivotGridDefinition>
        <PivotGridColumn Caption="Year"></PivotGridColumn>
        <PivotGridColumn Caption="Quarter"></PivotGridColumn>
        <PivotGridRow></PivotGridRow>
        <PivotGridRow></PivotGridRow>
        <PivotGridValue Caption="Quantity"></PivotGridValue>
        <PivotGridValue Caption="Amount"></PivotGridValue>
  </PivotGridDefinition>
</PivotGrid>

Or do you feel Blazorise users would be more inclined to use
<PivotGridColumn Caption="Year" Area="RowOrColumnOrData"></PivotGridColumn>
The disadvantage again, is if we want to have specific parameters for row or column or data, they all have to go on the same component.

[stsrki]

I guess we should start from scratch with PivotGrid?

[David-Moreira]

I guess we should start from scratch with PivotGrid?

Yea just because of the conflicts.
But I think we can still base ourselves in whatever's in here. It's important if you can answer the previous question so we can define the surface API when starting again..

From reading the comments it seems we couldn't decide on a surface api yet, you had different thoughts then me.