Enable persistent oig-context elements

[shock01]

When adding oig-context element add ability to persist the context. Meaning that when the element is added to the dom again it should load the data from sessionStorage.... This means that the element somehow needs to assing a unique id that can be used as key for data storage. State of view model needs to be stored on removal of element from DOM

Let element be an instance of oig-context Let attribute mode be persist When element is removed from DOM then store viewModel properties inside sessionStorage When element is appended to DOM again then preserve the viewModel without triggering Obect.observe

[shock01]

Not sure yet.....

Should the element (Custom HTML Element) store the persisted state??? Sounds kinda weird

Might be better than if persisted is true that the 'framework' will take care of window unload,location.search change... dom removal should not really matter then because the active viewModel will be present if location has not reloaded or has changed etc....

http://stackoverflow.com/questions/6188584/viewmodel-and-singleton-pattern

[shock01]

Might be better to have like oigLocator.resolve('viewModelPersistService') or a persistService or a sessionService -> then the service can be changed and also then it can be either stored in sessionService...or actually be stored in whateer.

viewModelPersistService.register('key', viewModelRefererce); viewModelPersistService.resolve('key')

In a kinda way it's weird that the view takes care of this. However there's no need to make controllers / viewmodels singletons thus there can be multiple instances of the same viewModel within an application flow. Which both can have separate state

sessionService .has(key) .get(key) .put(key) .delete(key)

Then there's only need to have like oig listen to document and window events related to window onload etc...... Keep in mind that object observe is actually async....this might lead to inconsitent data

If listening to window etc....we need to add somekinda bootstrap init procedure which is now added to module.js. (Eg. setting up serviceLocator)......

oig.defaultView.bootstrap() maybe ???? where defaultView can be located using locator???? -> document.querySelectorAll('oig-context[persist]') ... that's it. then when resolving view model from Element instead of using dataContext.resolve the dataContext.resolve should take kinda like the key into account....then dataContextResolve will actually get it from persistService.....which is much nicer then having it in elements

[shock01]

And....do we want to persist eveything???? or should we kinda be able to specify what is persistable???? That way we can prevent actually to have blooted session storage.

Or....should we just use it with care?? Be smart about which viewModels to persist....don't be an idiot

fun is to have like a sessionStorage implemented it can actually be AOP'ed for eg. encrypting or whatever (wild ideas)

maybe something like..... function Controller () { /*!persistable/this.name = 'null'; }

[Nagogus]

Maybe it is good idea to provide some pre-saving and pre-loading methods on viewModel? In that way pre-save will be called as filter before persisting viewModel and user can choose which properties will be returned/saved from viewModel. And same for pre loading which will be executed before restoring viewModel from storage? But if you have pre-save do you need pre-load?? everything can be done before saving..

<div is="oig-context" data-view-model="someViewModel" persist="filterWhatToBeSaveDependingOnSomeConditions">

and like this if there is no conditions for saving and it should be done in regular way <div is="oig-context" data-view-model="someViewModel" persist>

[Nagogus]

and saving can be even canceled from pre-save method. As I see main use case for persisting viewModel is forms, correct me if I am wrong, but if it is then in many cases it should be canceled depends on values in viewModel

[shock01]

Persist can. Also mean like collapse expand state of component. Or like a selection that you want to preserve.so its not directly tied to forms but more to viewstate Op 21 mrt. 2015 21:08 schreef "Ruben Nagoga" notifications@github.com:

and saving can be even canceled from pre-save method. As I see main use case for persisting viewModel is forms, correct me if I am wrong, but if it is then in many cases it should be canceled depends on values in viewModel

— Reply to this email directly or view it on GitHub https://github.com/shock01/oig/issues/22#issuecomment-84447951.