In order to be able to stabilize the DataViews package and APIs, we need to work on versioning the different configuration objects that live in that package. This doesn't mean we'll be stabilizing the package soon but at least we'll be ready to do so when we decide that it's ready.
These are the properties that need to support apiVersion and migrations:
view config in DataViews
fields config in both DataViews and DataForm (same config)
form config in DataForm
action config in DataViews
For each of these we need to:
Add an apiVersion key to the objects (defaulting to 1 if absent)
Build a migration framework that normalizes the upgrades the configs to the latest version at the entry level of both DataViews and DataForm
One thing we should avoid for the initialization stable release is to offer any public selectors or accessors for view, form, fields and actions. This is to avoid third-party developers assuming a certain shape for these objects while the format itself can evolve over time because of the apiVersion key.
In order to be able to stabilize the DataViews package and APIs, we need to work on versioning the different configuration objects that live in that package. This doesn't mean we'll be stabilizing the package soon but at least we'll be ready to do so when we decide that it's ready.
These are the properties that need to support apiVersion and migrations:
view
config inDataViews
fields
config in bothDataViews
andDataForm
(same config)form
config inDataForm
action
config inDataViews
For each of these we need to:
apiVersion
key to the objects (defaulting to 1 if absent)DataViews
andDataForm
One thing we should avoid for the initialization stable release is to offer any public selectors or accessors for view, form, fields and actions. This is to avoid third-party developers assuming a certain shape for these objects while the format itself can evolve over time because of the apiVersion key.