On Monday, April 24, 2017 at 5:11:58 AM UTC-5, David Bruant wrote: > Le 17/04/2017 à 18:09, Milan Raj a écrit : > > It would be great to have more control externally to know and control > > when records are added or removed from the undo / redo stack. > I think Facebook gave up on this idea and created draft.js on top of React > https://draftjs.org/docs/overview.html#content (the talk video is a good > introductory material about their motivations and design decisions). > The implementation of an undo/redo feature with React and/or redux is > fairly straightforward > http://redux.js.org/docs/recipes/ImplementingUndoHistory.html > > IMHO as an author, this is sufficient and removes the need for more > integration in the browser. YMMV > > David
From Boris: > https://dvcs.w3.org/hg/undomanager/raw-file/tip/undomanager.html was an > abortive attempt to create a spec for this sort of thing, for what it's > worth. It hasn't really gone anywhere, and may or may not actually be > the right direction, but may be worth looking at anyway, for inspiration > if nothing else. > > -Boris Thanks for the replies David and Boris! tl;dr The reply got longer than I would like but the summary is that for applications embedding multiple disparate web apps, it is a large burden to have all of those web apps tailored to integrate custom js based undo / redo stacks synchronizing to the parent application undo / redo stack and that complexity can be reduced if the embedding api can improve undo / redo stack control for us. -- I think one difference with the WYSIWYG editor I have experience with is that the embedded browser is one of many views and not the primary UI for the whole application. There are multiple other browser views rendering user editable content in addition to platform specific views rendering user editable content. The difficulty is maintaining a consistent source of truth for the undo / redo stack among all of them. Right now the representation of the objects in the WYSIWYG editor and undo / redo stack are stored externally and the embedded browser is expected to be a stateless view. However the undo / redo stack of the browser means that there is undo / redo state that the user would expect us to be aware of externally in-case they invoke undo / redo operations. And y'all are completely right that what appears to be the best existing solution now is to track the state in JS and find a way to synchronize externally. The problem is that kind of synchronization is not a very easy thing to implement when all good browser embedded APIs rely on asynchronous communication. In addition it means that all the different browser views coming from different teams, etc, have to individually implement JS based undo / redo tracking that integrates with their component and communicates outward to the parent app. It's not insurmountable, and probably not even the biggest concern in the grand scheme of things, but if we are talking about improving the embedding experience of a web browser in another environment then having a built-in method for controlling the undo / redo stack would be mighty helpful. As a side note: The last statement could probably be generalized to all user modifiable state but right now the only things that come to mind are undo / redo, zoom level, and navigation events in terms of user modifiable state. The embedded browser we use right now gives good control of zoom level and some indirect support for navigation. For navigation we can inspect and abort network requests but cannot explicitly prevent navigation away from a page. So there are brittle js scripts used to try and intercept <a> link clicks and window.location assignments and other unsavory things. The biggest thorn has been all the edge cases for trying to intercept undo / redo behavior in a general way that doesn't require app specific integration. It would be a huge help if an embedded APIs provided hooks to the current undo / redo stack and it would be down right pleasant for something like UndoManager linked by @Boris to exist so that the JS stack can push custom state into the undo / redo stack and the embedding API can have one interface for tracking both browser and JS undo / redo state. Best, Milan _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
