Create a layout restorer.
Private _connectorPrivate _deferredPrivate Optional _deferredPrivate _firstPrivate _firstPrivate _modePrivate _promisesPrivate _promisesPrivate _registryPrivate _restoredPrivate _trackersPrivate _widgetsWhether full layout restoration is deferred and is currently incomplete.
This flag is useful for tracking when the application has started in 'single-document' mode and the main area has not yet been restored.
Private _dehydrateDehydrate a down area description into a serializable object.
Private _dehydrateDehydrate a main area description into a serializable object.
Private _dehydrateDehydrate a side area description into a serializable object.
Optional area: null | ISideAreaPrivate _onHandle a widget disposal.
Private _rehydrateRehydrate a serialized side area description object.
This function consumes data that can become corrupted, so it uses type coercion to guarantee the dehydrated object is safely processed.
Optional area: null | IDownAreaPrivate _rehydrateRehydrate a serialized main area description object.
This function consumes data that can become corrupted, so it uses type coercion to guarantee the dehydrated object is safely processed.
Optional area: null | IMainAreaPrivate _rehydrateAdd a widget to be tracked by the layout restorer.
The default implementation of a layout restorer.
Notes
The lifecycle for state restoration is subtle. The sequence of events is:
The layout restorer plugin is instantiated and makes a
fetchcall to the data connector that stores the layout restoration data. Thefetchcall returns a promise that resolves in step 6, below.Other plugins that care about state restoration require the layout restorer as a dependency.
As each load-time plugin initializes (which happens before the front-end application has
started), it instructs the layout restorer whether the restorer ought torestoreits widgets by passing in its widget tracker. Alternatively, a plugin that does not require its own widget tracker (because perhaps it only creates a single widget, like a command palette), can simplyaddits widget along with a persistent unique name to the layout restorer so that its layout state can be restored when the lab application restores.After all the load-time plugins have finished initializing, the front-end application
startedpromise will resolve. This is thefirstpromise that the layout restorer waits for. By this point, all of the plugins that care about restoration will have instructed the layout restorer torestoretheir widget trackers.The layout restorer will then instruct each plugin's widget tracker to restore its state and reinstantiate whichever widgets it wants. The tracker returns a promise to the layout restorer that resolves when it has completed restoring the tracked widgets it cares about.
As each widget tracker finishes restoring the widget instances it cares about, it resolves the promise that was returned to the layout restorer (in step 5). After all of the promises that the restorer is awaiting have settled, the restorer then resolves the outstanding
fetchpromise (from step 1) and hands off a layout state object to the application shell'srestoreLayoutmethod for restoration.Once the application shell has finished restoring the layout, the JupyterLab application's
restoredpromise is resolved.Of particular note are steps 5 and 6: since data restoration of plugins is accomplished by executing commands, the command that is used to restore the data of each plugin must return a promise that only resolves when the widget has been created and added to the plugin's widget tracker.