I have a JavaScript web app (Backbone for my models, ReactJS for my views) which has two 'display modes', which the user can toggle between, using a button. These modes render data from my model - which is a tree structure, implementing the Composite Pattern - by rearranging leaf objects within the hierarchy, moving multiple objects between containers on the same 'level' in the tree (think of a drawer containing boxes of socks, and moving multiple socks around at random between boxes in the same drawer). Often this entails a complete rearrangement of the data. Currently I am handling this with the Memento Pattern, serializing and saving the current model until the user toggles the display mode again, when it is restored.
At the same time I also want to allow the user to make sequences of what can be thought of 'edits' in the usual sense - a sequence of arbitrary, redoable changes to objects, altering their size, colour, shape, etc. So it's a standard undo-redo pattern. I haven't written any code for this yet, but I am wondering exactly how I should implement this with respect to the Memento approach I already have in place for toggling between display modes. Is this something entirely different, or can/should I integrate the two?
One situation that possibly suggests the latter is this: the user might make an edit, which they wish to save, whilst in a display mode which will be toggled back to the previously stored one, which will now contain stale data. This suggests managing display mode changes and edit sequences together, thinking of them in terms of user commands, rather than app states (presumably modelling this in terms of the Command Pattern). Presumably on this pattern I would have a set of 'paired' commands for the display modes, which, rather than using a serializing pattern like Memento, know how to structure my underlying data in the appropriate ways and switch back and forth between these representations (though on the face of it this seems more complicated than my current Memento-based pattern, since I would - going back to my 'drawer' analogy - have to keep track of which box every sock has been, immediately previously). Is this the right approach? Am I reasoning about this correctly?
N.B: My models are quite small, usually no more than a few Kb, and even with user interaction wouldn't grow much beyond that. So the Memento Pattern doesn't cost me anything. It's just whether it's right to continue using it in the place where it's implemented.
Edit
Another possibility which has occurred to me is of handling the display modes through a viewmodel approach. So instead of swapping out the actual model each time, as I'm doing with the memento approach, a viewmodel sits between the model and view and 'restructures' the model data in the appropriate way for the current display mode. So there would be a 'default' mode, which just renders the model 'as is', but another mode which restructures the data hierarchy using the intermediary viewmodel. The main drawback of this approach, it seems to me, is that it introduces yet another mutable layer into the application architecture, which might prove too brittle to be manageable. The memento-based approach is certainly much simpler.