General discussion about events

[vitolpoc]

Version 0.0.10

Playing with "working with data" documentation's section and trying to implement sorting + pagination in our context, here are some thoughts about the events triggered by the data source or the table itself.

For now, to make the sorting + pagination work, the available events are:

• onSortInfoChange (on DataSource)
• onDataParamsChange (on DataSource)
• onScrollToBottom (on Table)

Sorting

Working with remote data while using pagination means we want to control the sorting (i.e. use the controlled mode of sorting). Also in our context, sort can be configured elsewhere. The sortInfo and onSortInfoChange allows us to do that, which is fine.

Pagination

In order to implement the pagination, the only way is to configure the onDataParamsChange property which is in fact an event triggered for a number of reasons (sort, page, other data params events).
The event itself contains the whole state of the request but does not contain the reason for which it has been triggered.
Because we already handle sort events in the onSortInfoChange, it is hard to filter only the relevant "getPage(page)" events. From the onSortInfoChange we cannot prevent the trigger of the according onDataParamsChange event.
This problem cannot be fixed by using the onScrollToBottom event as it is triggered only by the viewport scrollbar events which are not taking into account page size and total row count coming from the server.

Suggestions

Here are some suggestions that could be helpful from a user perspective:

1. create a new event dedicated to the datasource pagination, let's say onRowsRequested with the cursor and the page size (if configured). This would allow to work on the specific events (sort, page, ...) or only with the onDataParamsChange when the user wants to treat everything at a time. As a more general comment, every reasons that would trigger the onDataParamsChange should also have its own event.
2. In the onDataParamsChange, provide a way to know which is the source event of the call. This would allow to act depending on the actual change.
3. In every events, provide a property or a service API that gives the current context, configuration and / or state of the datasource (+table when relevant). This would allow in the handlers to access the columns configuration, visibility, groups, pivots, state, etc.

[roblotter]

Definitely, we need an onXXXChange for every property - so will implement onLivePaginationCursorChange and others as needed.

We could provide some service or API prop so you can get the current state of the table and data source - however, it would expose you to (unintended) changes within the state of InfiniteTable. We'll be giving this a thought to see how to best solve this.

PS: If you're using everything controlled, then you already have all this information.

[roblotter]

We're adding a changes object to onDataParamsChange, coming with an update soon

[roblotter]

Added a changes property to the argument received by onDataParamsChange in version 0.1.2