fix(grid):Grid service wasn't being reset (#3068)

* fix(grid):Grid service wasn't being reset

* fix(service):Fix the initial service state

Services with mode specific state differed in internal state between
initial and subsequent load.  This fix address that structurally by
allows the mode to store/manage service state, but makes the
responsibility of service state central to the service.

platform/docs/docs/platform/extensions/index.md

@@ -206,8 +206,10 @@ used to initialize data.
 
 [`onModeExit`](./lifecycle#onModeExit): Similarly to onModeEnter, this hook is
 called when navigating away from a mode, or before a mode’s data or datasource
-is changed. This can be used to clean up data (e.g. remove annotations that do
-not need to be persisted)
+is changed. This can be used to cache data for re-use later, but since it
+isn't known which mode will be entered next, the state after exiting should be
+clean, that is, the same as the state on a clean start.  This is called BEFORE
+service clean up, and after mode specific onModeExit handling.
 
 ## Modules
 

platform/docs/docs/platform/managers/service.md

@@ -178,3 +178,27 @@ import BackEndService from "../services/BackEndService/BackEndService";
 
 export { BackEndService };
 ```
+
+# Service Mode Lifecycle
+Services may implement initialization and cleanup for mode specific data.
+In order to prevent defects where there are differences between initial
+and subsequent displays of a study, the contract of the service is that the
+state the service is in on mode entry shall be the same whether the mode was
+entered or was exited and entered again.
+
+To implement storage/recovery of state, the mode must store the data on
+exiting the mode, and restore the data in it's onModeEnter.  For example,
+the mode may decide to preserve measurement data in the onModeExit, and
+to restore it in the onModeEnter.  This does not violate the contract since
+it is the mode's decision to apply the stored state, and to cache it.
+
+## onModeEnter
+A service may implement an onModeEnter call to initialize the service to
+be ready for entering a mode.
+This is called before the mode `onModeEnter` is called.
+
+## onModeExit
+When entering a mode, the service contract states that the service needs to
+be in the same state whether it is a fresh load or has previously entered the mode.
+The onModeExit allows a service to clean itself up after the mode 'onModeExit'
+has stored any persistent data.

platform/docs/docs/platform/modes/lifecycle.md

@@ -16,7 +16,11 @@ Currently, there are two hooks that are called for modes:
 
 This hook gets run after the defined route has been entered by the mode. This
 hook can be used to initialize the data, services and appearance of the viewer
-upon the first render.
+upon the first render, in any way that is custom to the mode.
+
+This is called after service `onModeEnter` calls so that the entry into a mode
+is done in a predefined/fixed state.  That allows any restoring of existing state
+to be performed.
 
 For instance, in `longitudinal` mode we are using this hook to initialize the
 `ToolBarService` and set the window level/width tool to be active and add
@@ -64,9 +68,13 @@ function modeFactory() {
 
 ## onModeExit
 
-This hook is called when the viewer navigate away from the route in the url.
-This is the place for cleaning up data, and services by unsubscribing to the
-events.
+This hook is called when the viewer navigates away from the route in the url.
+It is called BEFORE the service specific onModeExit calls are performed, and
+thus still has access to stateful data which can be cached or stored before
+the services clean themselves up.
+This is the place for cleaning up NON-service specific data, and services
+by unsubscribing to the events.  The cleanup of the service itself is intended
+to occur in the service `onModeEnter`.
 
 For instance, it can be used to reset the `ToolBarService` which reset the
 toggled buttons.