Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: PivotGrid #3214

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from
Draft

WIP: PivotGrid #3214

wants to merge 1 commit into from

Conversation

David-Moreira
Copy link
Contributor

No description provided.

<PivotGridValue Caption="Quantity"></PivotGridValue>
<PivotGridValue Caption="Amount"></PivotGridValue>
</PivotGridValues>
<PivotGridRows>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

@David-Moreira David-Moreira Dec 6, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Collaborator

stsrki commented Dec 6, 2021

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
Copy link
Contributor Author

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
Copy link
Collaborator

stsrki commented Dec 6, 2021

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
Copy link
Contributor Author

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
Copy link
Collaborator

stsrki commented Dec 8, 2023

I guess we should start from scratch with PivotGrid?

@David-Moreira
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants