Use OData API to demonstrate real-life scenario

[cilerler]

Since this project is relatively new, please consider using https://services.odata.org/V4/TripPinServiceRW as a data source which is ODATA based.

Once you hit that service, it will generate a read-write endpoint as https://services.odata.org/V4/<InstanceId>/TripPinServiceRW/ where InstanceId is something like (S(pfvo2qaqwuyjvcsqafohkyyg))

It would give this project more attention since no other grid/table samples use ODATA as a source.

ODATA will be revamped by Microsoft and community pretty soon via a project called RESTier

[conficient]

I think a generic mechanism that allows the setting of a 'datasource' instead of the Items parameter would be a good idea - that could be an OData provider, a REST API or perhaps just an IQueryable. It would need to (optionally?) support count, paging, sorting, and filtering so a data source can be accessed in an efficient way.

A datasource could be a provider model that implements a common interface that the Table can query to get the data, e.g. EntityFrameworkProvider, ODataProvider etc.

Thoughts?

[IvanJosipovic]

@conficient, that's exactly what I was thinking.

The Table currently converts the Items parameter to a IQueryable, so exposing that interface would be the simplest way forward. This would allow the existing Filtering/Paging components to work without any modifications. It should also probably work with EF as is, I haven't tried though.

If there are no objections, I'll proceed with the IQueryable<T> route.

[IvanJosipovic]

I performed a quick PoC with Microsoft.OData.Client in the following branch.

Blazor Server Side, can load data and sorting appears to work. Blazor Wasm, will need more work.

Example loading data from, https://www.odata.org/odata-services/

Blazor Wasm error:

Nevertheless, this is very promising!