1. EditScope – Managing unsaved edits in Ibiza
Brad Olenick – Principal Architect
3/12/2015

2. Demo – Scenarios

3. UX goals Unsaved edits shouldn’t inhibit spontaneous navigation
ex. clicking a Notification, switching Journeys
No “Discard changes?” decision on navigate
No “Will I lose my edits if I navigate now?” uncertainty
Predictable, consistent model across experiences
UI virtualization is our basis for perf/scaling
Ibiza disposes view models as UI goes off-screen and…
…recreates view models as UI comes back on-screen
Imperceptible to the user. Must retain unsaved edits!

4. UI virtualization Approach:
Capture all Part state in a view model…
…and make view models rehydratable
Server data – Extension reloads from server/service
View state – Ibiza Shell persists to/from “user settings service”
Ex. current selection, tree node collapse/expand
Unsaved edits – Use EditScope!

5. EditScope Simply a class in MsPortalFx.Data
Preserves unsaved user edits on behalf of extensions
EditScope…
…when a user edits data via a form or editable grid:
detects changes to an extension’s model data
persists changes to Ibiza’s “user settings”
…when a view model is recreated:
applies persisted changes to an extension’s model data

6. Demo – Simple editing

7. First use User modifies editable observables.
View (form/grid)
Controls determine “dirty” based on comparing
editable/original observables.
The editable/original data is bound into the view.
EditScope exposes the editable data as editScope.root.
Copy*
Copy
Copy
The original data is available via editScope.getOriginal.
EditScope compares corresponding editable/original observables to generate edits.
EditScope
EditScope makes a copy of the input data. This is the “editable data”.
Copy
Copy*
EditScope instantiated with “input data”.
This is the “original data”.
EditScope persists edits to “user settings”.
Input data
First use

8. Rehydrate Controls show the edited editable data.
View (form/grid)
Controls show the edited editable data.
Controls determine “dirty” based on comparing
editable/original observables.
The editable/original data is bound into the view.
Copy
Copy*
Input data
View is restored to its edited state!
EditScope
Copy*
Copy
EditScope instantiated as before.
EditScope applies edits to editable data.
Input data
Rehydrate

9. Demo – EditScopeId

10. EditScopeId EditScopeId associates an EditScope with a Part or Blade
…and edits then share the lifetime of the Part/Blade
<Blade Name="DetailBlade"> <Blade.Parameters> <Parameter Type="NewEditScope" /> …
<CustomPart Name=“DetailPart" NewEditScope="True“/>
<!-- inputs.editScopeId is then available to onInputsSet -->
Prompt “Discard Changes?” when…
A Blade is closed…that is associated with a dirty EditScope
A Blade is closed…that contains a Part associated with a dirty EditScope
A Part is unpinned…that is associated with a dirty EditScope

11. Demo – Integrated forms

12. Forms integration EditScopeAccessor
Binds your form field to a pair of EditScope observables
Validates that you use only EditScope observables…else bugs!
Advanced – Allows binding a form field to a computed observable
…computed over multiple EditScope observables
Enables Master/Detail form editing too
When Master selection changes…
…Detail form is rebound to new EditScope (and not recreated)

13. Demo – List editing

14. Entity data model
Without type metadata, objects are treated like property bags…and arrays as single values.
Entities can be individually in Created, Updated or Deleted state.
editScope.addCreated(newEntity, entityArray);
entity.city(“Kirkland”);
editScope.markForDelete(entity);
var state = editScope.getEditState(entity);
Entities can be individually reverted to an unedited state.
editScope.revert(entity);
editScope.revertAll();
EditScope ‘dirty’ property reflects whether there are any edited entities.
var dirty = editScope.dirty;
With type metadata, EditScope objects treated as discrete, editable entities. U U D C C

15. Demo – EditScope management

16. EditScope management Save edits to server
Use ‘saveEditScopeChanges’ option on EditScopeCache
Refresh existing data from server
Use ‘refreshEditScopeChanges’ option on EditScopeCache
Revert unsaved edits
Use ‘editScope.revert(entity)’ or ‘editScope.revertAll()’
Do these at the EditScopeCache level since they are async calls
DataContext is long-lived
View models can be disposed during async save/refresh!

17. Why so much machinery?
EditScopeView – Forms can rebind to new (possibly edited) data
Master/Detail form editing
EditScopeCache/EditScopeId – EditScope sharing across view models
Blade with “form Part” and “’Save’ Command”
Multi-Part, multi-Blade “document editing”
We’re simplifying common cases!
Parameter Collection FX pattern
Encapsulates EditScopeCache/View for simple form scenarios
Blade Toolbars – Commands in locked Blades can share Part’s view model
No need to share an EditScope across view models
More in the future?

18. Wrap-up Caveats Try CTRL-ALT-d
Don’t programmatically modify EditScope observables!
…or you’ll get “Discard edits?” dialogs after no user edits (BUG!)
Supply type metadata to treat arrays as entity arrays
…efficient, per-entity edits; better concurrent editing
Try CTRL-ALT-d
EditScope debug visualization
Didn’t cover – EditScope use in Parameter Collection pattern
Learn more:
Search auxdocs for EditScope:
Relevant from SamplesExtension:
Data…MasterDetailEdit, Controls…Grid…Editable, Forms
Yammer group – Ibiza discussion

19. EditScope – Managing unsaved edits in Ibiza
Brad Olenick – Principal Architect
3/12/2015