Add refresh functionality

[SoapyDev]

Good day,

This PR aims to add a way to recalculate values based on rows, without reloading the table.

Ex.: I have a receipts table and would like to have the total.
Using the ReceiptsDataProvider, I will pass the sum of my currently loaded rows as a calculated total to the context of my application. This works with the current implementation of the table. But if I do update a row, I am forced to reload the table to have access to the new information, lose the currently selected row, etc....

With this implementation, we separate the loading of the data from the calculated values and can recall it as many times as needed without reloading data and keeping the selected row selected.

A nice unintended effect is that we gain access to the list of RwSignal that can be shared out of the table, while keeping the data in sync. This is not yet tested on my part, as it was not the intended use case. If this creates more problem then it solve, a signal would suffice to the intended use case of refresh. Otherwise, it would allow for side forms directly affecting the table and vice-versa.

I did not spend days studying the library, so if anything seems out of place, or could be improved, I am all hears.

[maccesch]

Interesting! Thank you very much.

I'm not sure if this is the way to go though. This basically adds a callback to an otherwise mostly loading focused trait. I mean the sorting method is a callback as well in a way, so it's not that absurd 😀.

There has been a demand to have access to the row signals, so there should be a way to deal with these kinds of editing data scenarios for sure.

I'm in the process of extracting the loading, caching and virtualization logic out into it's own crate that this crate can then reuse and I'm trying to take the lessons learned from here to make a nicer API.

So I'll definitely have to think about these scenarios more. If there's any insight you have on this I'm happy to try and incorporate it.

[SoapyDev]

That's great, so far this addition was mostly fuelling on a hack. That is, using the provider as a 2 way street, as its the only way to interact with the list without duplicating it. So a better API would be the most welcome.

Suggestions

Footer

The addition to the table of an optional footer element displaying calculated value. The default implementation could display the count provided by the call, or the length of the list as a Total. With the ability to override it with a custom footer_renderer.

This would be a way to minimise external requirements for the list by encapsulating what is for now an external implementation.

Mutable list access or extension of the API

A limitation of this PR is that we get access to a Vec<RwSignal>. This is great for row access and mutation, but not so much for list addition and subtraction. From my experience, I tend to create/delete rows externally and then reload the table quite a lot, even if my API returns the new value.

So getting access in a way or an other to a mutable list might make sense, but bring in considerable implications when it comes to the validity of the count returned by the API, since there is no proof that I have created/deleted the row in the data source as well, so my local count might be different from my data source's. This behaviour, might still be the desirable one, as it allow to add a row locally, then change values before submission and all of it from the table. The burden is then on the consumer to ensure count validity.

The other possible path that I can think of would be to extend the current API with optional insert_row, delete_row(s). This is less flexible, but also a sure way. Deletion would work well with the current selected_index.

Hopefully, this is helpful