OData
index
Description
OData Backend Service (for Pagination purposes) to get data from a backend server with the help of OData.
Demo
Note
Use it when you need to support Pagination (that is when your dataset is rather large, more than 5k rows) with a OData endpoint. If your dataset is small (less than 5k rows), then go with a regular grid with the [dataset]
binding property. SlickGrid can easily handle million of rows using a DataView object, but personally when the dataset is known to be large, I usually use a backend service (OData or GraphQL) and when it's small I go with a regular grid.
Implementation
To connect a backend service into Slickgrid-Universal
, you simply need to modify your gridOptions
and add a declaration of backendServiceApi
and pass it the service
. See below for the signature and an example further down below.
IMPORTANT NOTE
All the code below assumes that your Backend Server (probably in C#) will return the data into an items
property. You could return the array directly but it is strongly discouraged to do that because that will conflict with the metrics
that you will see in the code below. The best approach is to return your data into a property, like items
or any property name you wish to use, on your backend server side. Your result should have this kind of structure
TypeScript Signature
As you can see, you mainly need to define which service to use (GridODataService or GraphQLService) and finally add the process
and postProcess
callback.
Grid Definition & call of backendServiceApi
Notes
Pagination is optional and if not defined, it will use what is set in the Slickgrid-Universal - Global Options
onInit
is optional and is there to initialize (pre-populate) the grid with data on first page load (typically the same call asprocess
)you could load the grid yourself outside of the
gridOptions
which is why it's optional
filterTypingDebounce
is a timer (in milliseconds) that waits for user input pause before querying the backend serverthis is meant to throttle the amount of requests sent to the backend (we don't really want to query every keystroke)
700ms is the default when not provided
Code
Passing Extra Arguments to the Query
You might need to pass extra arguments to your OData query, for example passing a userId
, you can do that simply by modifying the query you sent to your process
callback method. For example
OData options
All options can be found here: Slickgrid-Universal - OData Options
Some are described in more detail below.
OData version
By default the OData version is set to 2 because it was implemented with that version. If you wish to use version 4, then just change the version: 4
, there are subtle differences.
Query total items count
The total items count can be queried from the backend by:
When enabled that will add $inlinecount=allpages
(v2/v3) or $count=true
(v4) to the query. And the count from the backend's response is extracted and pagination.totalItems
is updated with that count. The property in the response that is used depends on the oData version specified: d.__count
for v2, __count
for v3 and @odata.count
for v4. If needed a custom extractor function can be set through oDataOptions.countExtractor
.
Query only the grid column's fields
Query only the grid column's fields from the backend by:
For example columns: [{ id: 'col1', field: 'field1' }, { id: 'col2', field: 'field2' }]
results in the query: ?$select=id,field1,field2
.
A property id
is always selected from the backend because the grid requires it. This property can be changed by setting gridOptions.datasetIdPropertyName
.
Query related resources / expand navigation properties
Specify that related resources (navigation properties) should be retrieved from the backend:
A navigation property is identified as a field having /
in it's name. For example columns: [{ id: 'col1', field: 'nav1/field1' }, { id: 'col2', field: 'nav2/field1' }]
results in the query ?$expand=nav1,nav2
Often enableSelect
and enableExpand
are used in conjunction. And with oData v4 then also navigation properties are selected from the backend. For example columns: [{ id: 'col1', field: 'nav1/field1' }, { id: 'col2', field: 'nav2/field1' }]
results in the query ?$select=id,$expand=nav1($select=field1),nav2($select=field2)
Navigations within navigations are also supported. For example columns: [{ id: 'col1', field: 'nav1/subnav1/field1' }]
.
The dataset from the backend is automatically extracted and navigation fields are flattened so the grid can display them and sort/filter just work. The exact property that is used as the dataset depends on the oData version: d.results
for v2, results
for v3 and value
for v4. If needed a custom extractor function can be set through oDataOptions.datasetExtractor
. For example if the backend responds with { value: [{ id: 1, nav1: { field1: 'x' }, { nav2: { field2: 'y' } } ] }
this will be flattened to { value: [{ id: 1, 'nav1/field1': 'x', 'nav2/field2': 'y' } ] }
.
Override the filter query
Column filters may have a Custom
operator, that acts as a placeholder for you to define your own logic. To do so, the easiest way is to provide the filterQueryOverride
callback in the OdataOptions. This method will be called with BackendServiceFilterQueryOverrideArgs
to let you decide dynamically on how the filter should be assembled.
E.g. you could listen for a specific column and the active OperatorType.custom in order to switch the filter to a matchesPattern SQL LIKE search:
Last updated