Closed nicknisi closed 6 years ago
These notes are based on a discussion with the team about how the wrapper might work from a high level and are subject to change as more investigation occurs.
The dgrid wrapper should to the greatest extend possible mask the fact that the widget is running a dojo 1 widget. The user should not need to interact with the underlying dgrid or dstore code. Ideally, the data to be rendered in the grid will be passed a a property to the widget.
w(Grid, {
data: [
{ /* ... */ },
// ...
],
columns: {
// ...
}
});
Our initial idea is that the wrapper will be completely responsible for taking the data passed to the widget and internally creating and managing the accompanying MemoryStore
. When the data is changed it will efficiently update the underlying dgrid. We’re still determining the best way to do this.
When updating the grid, we need to be cautious of how the data passed through the wrapper changes the underlying dgrid. Simply calling update
on each record will quickly become a performance bottleneck. We could completely replace the data in the MemoryStore
with setData
but this could have unintended consequences related to scroll position, selection, etc.
The wrapper should allow for callbacks to be passed as properties that tie into events that occur in the grid.
w(Grid, {
onRowSelected(row) {},
onRowDeselected(row) {},
// ...
});
For this to work, we're going to need the ability to utilize the external-loader-plugin to allow for this wrapper to properly load dgrid/dstore/dojo. There is an issue for this work at dojo/cli-build-app#7.
Here is the current status of the dgrid wrapper widget...
We are going to use a webpack plugin that provides the Dojo 1 loader. @maier49 is working on updating the Dojo cli build and testing tools to support that plugin. This will allow the dgrid wrapper widget to use the dgrid modules.
The dgrid wrapper will live in dojo/interop and the current progress is in a branch named "dgrid-wrapper" in my fork of dojo/interop: https://github.com/edhager/interop/tree/dgrid-wrapper. That branch has been upgraded to use dojo/framework. The wrapper supports the dgrid pagination extension and there are unit tests that exercise the dgrid wrapper widget.
A sample app exists that demonstrates the dgrid wrapper. The most up-to-date version of that app lives here: https://github.com/edhager/dgrid-wrapper-app. That app has been upgraded to use dojo/framework but it uses a special version of the dojo cli build tool which is found in the "packages" directory. That build tool is the initial modification of the dojo cli to include the Dojo 1 loader webpack plugin.
The dgrid wrapper widget is useful and functional as it is but it does not support all of the dgrid features that are desired. What is left to do is to identify each dgrid extension that we want to support and add a new property to dgrid/DgridWrapperProperties#features
that will enable the appropriate mixin. Then look at the appropriate KwArgs
interface in dgrid/interfaces.d.ts
and copy the desired properties into dgrid/DgridWrapperProperties
. For each property added, decide if that property can be updated in an exiting dgrid grid. If not, add the property name to the constructionKeys
array.
The dgrid wrapper has landed here https://github.com/dojo/interop/pull/39
Dojo 2 should provide a robust grid widget.
Background
dgrid holds up as one of the best grid widgets around and there should be an easy way to use it within Dojo 2 applications for the time being and until a proper replacement is found or developed.
There is currently a version 2 grid implementation that is being considered but it is not yet ready for use and may change drastically.
Initial Goals and Ideas
Here is a list of high-level goals that the dgrid wrapper should adhere to: