Follow-on items on ViewManager release

[amcclain]

Tracking several follow-on enhancements and fixes to ViewManager

Bugs

• Bug - reverting changes to default view does not work if there are no other saved views, due to early out in selectViewAsync
  Fixed in branch

• Bug - Folder names are incorrect when depth > 2.
  Fixed in branch

Enhancements

• Add ability to persist and restore user's pendingValue state - the dirty state of the persisted components - so changes to views can be sticky even without being saved. This state would be persisted via the VMM's own persistWith provider - so not saved back to JSONBlobs.

• When initially loading VMM, list JSONBlobs without values, then make async call to server to get value for selected view at selection time. Avoids eagerly loading large blocks of state on app init for use cases with many large saved views. Also reduces chance of having a stale view, or worse saving a change to a shared view that overwrites a more recent change.
  Fixed in branch

  • Consider if we want to defend against that last case more explicitly - e.g. by re-fetching shared view before saving and ensuring not updated since loaded.

• When showSaveButton != 'never', show the save button next to the menu even if the default or other view is selected that cannot be saved directly in place. For these views, the button should trigger the "save as" dialog, but is still useful as a dirty indicator and to allow users to persist their changes.

• Add option to show "Revert" button next to top-level menu + save button. Could take same triplet of options - always|whenDirty|never. Could default to never.

• Add option to place save/revert buttons to left of main menu button vs right, for usages that have viewManager at far right edge of a toolbar. Not sure what to call it - buttonSide a bit too weird, since everything is actually a button....

• Revisit language around "shared" views. Consider a term like "published" or "global" when referring to globally available shared views that appear in the menu (currently our only form of sharing), to make more room for future "sharing" implementations that might be more along the lines of "send a copy of this view to another user, or let other users find this view to copy".

  • In immediate term, could provide option for devs to customize the word used in the display layer for "shared" - eg could change to "Firmwide" or "MyCompany"

• Remove context menu in Manage Views dialog grid and fix to standard grid sizing mode. (Grid used here more as a direct UI control than a data grid - check other usages like column chooser)

• Need to decide about what we show for buttons when when user is in 'autosave' mode. The save button "flashing" its appearance (whenDirty) or enabled state (always) could be considered a feature or a bug. _Greg and I decided this was a bug -- we just hide the buttons when autosaving _

Larger Topics

• Alternate sharing models, such as "pushing" a copy of view to another user or providing a way for users to "discover" other users' views and make their own copy. Both of those contrasting with current sharing model where multiple users access (and potentially edit)
• Dirty state considerations around changes to grid columns, specifically new columns added in code will dirty every view, as once loaded the grid will flush updated state back into pendingValue with the new columns added. Consider feasibility of saving a "baseline" snapshot of state for dirty comparisons that is taken after saved view has been loaded into persistables but before user has had a chance to make any interactive changes.

[amcclain]

Opened branch https://github.com/xh/hoist-react/tree/viewManagerFollowUps to collect a few of the immediate "quick-wins" here and review/merge in a consolidated way

[lbwexler]

Thanks for this fantastic write-up Anselm -- I pushed a fix to the tree construction, and am now looking at the dynamic loading

[lbwexler]

NOTE: Added toolbox branch under the same name

[amcclain]

Reopening