Table Widget: core functionality

[edgarberm]

Screenshot from integration in carto-react-template sample app 3

This PR introduces TableWidgetUI as a new UI component and TableWidget as a new widget.

For now, supports sorting, pagination and click on row behavior.
Selection, search and export will be managed in further PRs.

TableWidgetUI behavior is fully controlled, so filtering, sorting and pagination has to be done by the parent component. This allows TableWidget to use the new getRawFeatures API from #225, to access and sort features in an efficient way.

[coveralls]

Pull Request Test Coverage Report for Build 1648975353

• 26 of 29 (89.66%) changed or added relevant lines in 3 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.4%) to 70.303%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
packages/react-ui/src/widgets/TableWidgetUI/TableWidgetUI.js	21	24	87.5%

Totals
Change from base Build 1648762511:	0.4%
Covered Lines:	1142
Relevant Lines:	1529

---

💛 - Coveralls

[bbecquet]

Shortcut link: https://app.shortcut.com/cartoteam/story/183138/implement-table-widget-basic-functionality

[bbecquet]

We need to make this adjustment because TablePagination from MUI is zero-based whereas our pagination API is 1-based (see https://github.com/CartoDB/carto-react/blob/master/packages/react-workers/src/workers/features.worker.js#L166)

Or maybe we could change our own implementation to start at page 0 too? Would it be possible @Clebal?

[Clebal]

@bbecquet totally agree, it's a mistake that page is 1-based. Sorry for my late response, I didn't saw this. Can you open a PR with that change?

[padawannn]

The PR looks really web but I'm wondering about the behavior when we change the page and after that, the data changes because the viewport has changed or we've applied a filter. In that case, we could be consulting a page that no longer exists and the table would show no data.

@alasarr, @borja-munoz we need to talk about what to do in that case (because is a very common case). Probably, we would need to go back to the first page every time that the data changes.

[alasarr]

Looks good to me for a first version. Remember to update the changelog.

[bbecquet]

@padawannn about your comment on pagination vs. viewport, I've added this piece of code 17454dd which resets the page to 1 when the features change.
It uses the fact that the ready state of the source goes through the cycle true -> false -> true when the viewport changes.
Do you think it's robust enough?

[padawannn]

@padawannn about your comment on pagination vs. viewport, I've added this piece of code 17454dd which resets the page to 1 when the features change. It uses the fact that the ready state of the source goes through the cycle true -> false -> true when the viewport changes. Do you think it's robust enough?

@bbecquet we also need to reset the page to 1 if filters change. For example, in your branch template when you click hover a category in the category widget. We also should reset the page to 1 if the datasource change although this case is not common

[padawannn]

#154 (comment)

[bbecquet]

@padawannn Thanks for the explanation about filters. I've changed the reset callback.

[padawannn]

@bbecquet you forgot to include the dataSource as a reset condition although it is not a common case.

On the other hand, it could be great if we add some tests about page reset