DataGrid: Mixes CurrentPage and PageChanged into single two-way bindable param

[tesar-tech]

Description

• Mixes CurrentPage and PageChanged into single two-way bindable param
• Fixes pagesize "bug" in datagrid test page;
• Removes unnecessary DataGridPageChangedEventArgs.cs
• updates release notes

Closes #3610

[stsrki]

What about renaming the CurrentPage in

• PaginationContext
• CurrentPage

Does that also makes sense?

[tesar-tech]

What about renaming the CurrentPage in

• PaginationContext
• CurrentPage

Does that also makes sense?

In PaginationContext and DataGridState there the current page is really a state, information. But in Datagrid it's more like a thing you can operate with (through binding). You "go to page 20" not "go to current page 20". In pagination it's more like "changing the current page".... Just slight nuance, no strong opinion.

Also renaming to Page in PaginationContext would require to rename all the event handlers, etc.

[stsrki]

What about renaming the CurrentPage in

• PaginationContext
• CurrentPage

Does that also makes sense?

In PaginationContext and DataGridState there the current page is really a state, information. But in Datagrid it's more like a thing you can operate with (through binding). You "go to page 20" not "go to current page 20". In pagination it's more like "changing the current page".... Just slight nuance, no strong opinion.

Also renaming to Page in PaginationContext would require to rename all the event handlers, etc.

From a user perspective, I think it makes sense to name them all the same. That way, we will be consistent.

@David-Moreira, what do you think?

[David-Moreira]

I prefer the same naming always to avoid miss interpretations from different developers.

I also have no strong feelings about CurrentPage vs Page, I guess both are understandable, but generally you don't name parameters with "Current" prefix, like CurrentData, CurrentPageSize, CurrentFilter, etc, etc.. You just assume they are what it's set to or will be due to being set declaratively. Current is redundant in my opinion.

I'd not use current even to represent "current state". I believe that's already implied when accessing an api that represents state.

I think it only makes sense if you have two conflicts parameters to make it explicitly which one is which, i.e oldItem vs currentItem. And I'd probably still personally use OldItem and Item instead of the currentItem example.