Studio state allows reports to be saved and restored. Reports can be created in edit mode, saved down as state, and then reloaded in view mode.
Saving and Restoring State Copy Link
const initialState = useMemo(() => {
return {
pages: [
{
id: 'page-1',
widgets: {
'1': {
type: 'grid',
dataMapping: {
cols: [
{ id: 'medals.country' },
],
},
},
},
widgetLayout: {
'page-1': {
xTrack: 0,
yTrack: 0,
xSpan: 24,
ySpan: 16,
},
},
},
],
selectedPageId: 'a',
};
}, []);
<AgStudio initialState={initialState} />State is provided to Studio on initialisation via the initialState property.
State can be saved and restored on demand via the API methods getState() and setState().
Any time state changes, a stateUpdated event is emitted with the latest state. When Studio is destroyed, the studioPreDestroyed event is fired, which contains the latest state at the time.
These are all demonstrated in the above example. See the State API below for more details.
State is immutable. Studio uses reference equality to detect which parts of the state have changed, and updates them accordingly. If updating state and providing it back to Studio, ensure that a shallow copy is made to the depth of the changes.
Changing Pages Copy Link
Reports support multiple pages. These are all defined in state, with the currently displayed page set via the top-level selectedPageId state property. The page can be changed by getting the latest state from Studio and setting back a copy with the selectedPageId updated.
const state = api.getState();
api.setState({
...state,
selectedPageId: 'page-2',
}); Invalid State Copy Link
When state is invalid, Studio will do a "best-effort" attempt to load the state. This generally means removing invalid properties, which can leave widgets incomplete.
In Edit Mode, the UI can be used to fix the properties that were invalid, however in View Mode the user cannot make updates.
Studio will emit an errorRaised event with errorType: 'state' when there is invalid state (see Studio Events for how to listen to events). When in View Mode, where the report cannot be loaded properly, the event will have fatal: true.
It is recommended that you handle fatal error events by preventing the user from interacting with Studio. E.g. hiding Studio with your own error component, prompting the user to load a different report, switching into Edit Mode if the user has permissions, etc.
To help avoid invalid state, we strongly recommend creating state in the UI and then retrieving it from Studio. You can then make minor tweaks if required, rather than hand-crafting the entire state object.
State Versioning Copy Link
If there are breaking changes to the shape of the state object, Studio will try to automatically upgrade any provided state based on the version property.
version is always set with the current version when retrieving state from Studio.
If version is not set, Studio will assume that the state is for the current version, and will not perform any migrations.
Ensure that any saved-down state is read from Studio or has the version set. Otherwise you will have to manually update it if there are breaking changes to the shape of the state object.
State API Copy Link
Properties Copy Link
Initial state for Studio. Only read once on initialization. Can be used in conjunction with api.getState() to save and restore Studio state. |
API Methods Copy Link
Get the current state of Studio.
Can be used in conjunction with the initialState Studio property
or api.setState() to save and restore Studio state. |
Set the current state of Studio.
Can be used in conjunction with api.getState() or onStateUpdated
to save and restore Studio state.
The state is expected to be a full state object, not a partial state object.
State must be updated immutably as Studio uses reference equality
to determine which parts of state have changed. |
Events Copy Link
State has been updated. |
Invoked immediately before Studio is destroyed. This is useful for cleanup logic that needs to run before Studio is torn down. |