In-Memory DataSource
We name an In-Memory data source when you provide your data set in one go.
Providing a data set in one go means that the DikeGrid receives the data in any of the following ways:
Array
When you directly assign a variety of entries.
Observable<Array>
This type of data usually comes from an HTTP get
invocation.
DikeGridDataSource
You can create an instance of DikeGridDataSource
, then assign your data to the entries
property.
When you provide your data in one go, the DataGrid manages the data in memory during all the execution.
Since you can change the datasource
property at runtime, consider the following code snippet:
With the previous UI, you can do the following actions:
Array button. It creates an array of five entries.
Observable button. It makes a call to an
HTTP get
. Then, it retrieves 500 entries from the REST API.DikeGridDataSource button. It creates a
DikeGridDataSource
instance. Then it makes a call to anHTTP get
. We assign the response to theentries
property from theDikeGridDataSource
.
You can see how the unique id changes every time the datasource
property changes.
DataSource Decorators
Once you assign your data source to the DikeGrid instance, it takes those rows into a pipe of operations.
See the following diagram:
The DikeGridDataSource
instance is always the first instance in the chain.
As you can see, the DikeGrid creates the following instances:
DikeRefreshingDataSource
This decorator always wraps a DikeGridDataSource
instance. It pushes the rows when the user has updated them. The DikeGrid creates this decorator if you have allowed the edition operation.
DikeEditionStateDataSource
It splits the set of rows depending on their status, Modified
, Deleted
, or Editing
. The DikeGrid creates this decorator if you have allowed the edition operation.
DikeFilteringDataSource
This decorator manages all the filtering operations. Even the filters applied to the rows in edition mode.
DikeSortingDataSource
This decorator manages all the sorting operations.
This pattern gives us great flexibility in adding or removing operations to the chain and encapsulating responsibilities in each decorator.
Custom Decorators
Let us define a custom decorator:
In the previous code, we only hide the Employee Id value. We intentionally left a tap RxJS operator to verify that the DikeGrid invokes the custom decorator.
Be aware that you can assign the decoratorFn
property only at the initialization phase.
Let us assign the decoratorFn
property.
As you can see, you have access to the property named dataSourceFactory
under the DikeGrid instance.
Decorators and Row Grouping operation
When the user groups rows, the DikeGrid internally creates a tree where every node represents a group of data rows. Only the leaves have the actual data rows.
According to the previous statement, the DikeGrid takes the defined chain of operations and sets it to every tree leaf.
Summary
Complete code for this section
Last updated