Text assets should have auto-save feature

[jwirfs-brock]

This is related to issue #847.

[ghing]

Assigning to @jwirfs-brock to specify desired behavior.

[jwirfs-brock]

This is also related to issue #711 (summary save behavior is different than text asset save behavior).

[jwirfs-brock]

To clarify, there is a suite of issues that are related:

• 711, which points out that to save the Summary and Call to Action text, users don't use a save button. Text is automatically saved.

• As a result of this, users often forget to click "Save" when typing a text asset, resulting in #847, where unsaved text gets lost when a user navigates to a different section.

I think these three issues can all be solved with one solution. Either we can,

1. Implement auto-save in text assets (the solution discussed in #847), or
2. Add a save button to the Summary and Call to Action fields (the solution discussed in #711)

I prefer (1) to (2). @ghing do you have a preference? I'm open to discussion on this issue.

If we implement an auto-save, I have a few questions:

1. Should we keep the "Save/Cancel" buttons, and have the auto-save be a redundancy? My initial reaction would be yes to keeping the buttons, because this keeps it consistent with other asset types.
2. If a user types in some text (thus triggering the auto-save), then hits cancel, should that asset sill be saved (i.e., it goes into the asset drawer), or should it disappear? My initial reaction is that it should not be saved (again, to keep it consistent with other asset types).
3. To keep the text editing consistent with the summary and text assets, should we add a "Save" button to the summary as well? I'm not sure what makes the most sense here. There is a "Save" button at the top that will save the summary (which does not save text assets that have not been individually saved), so in a way we already have this feature. Thoughts?

[ghing]

@jwirfs-brock:

I'm really not sure about 1 (keeping the Save/Cancel) buttons or 2 (behavior of the cancel button). I think I'll have to get a bit deeper into the implementation to decide, though I'm pretty sure some changes to the buttons (for text assets) will have to happen.

As for 3 (save button for summary), I don't think we need this, especially if we're going to reconfigure some of the metadata editing as part of the story building workflow.

[ghing]

Note to self:

The saving flow is submit form -> processForm() -> saveModel()

Gotchas:

• saveModel() defines a success callback that changes the view state to 'render' and then re-renders the view.

Questions:

• Should I update saveModel() to make the re-rendering optional, or make a specific method for saving Text?
• What should trigger the autosave? I don't think we want it to happen on every keystroke.
• Should the triggers be bound to the rich text editor or the underlying textarea (I think the latter)

[ghing]

Triggering the auto-save is a little tricky.

The wysihtml5 editor has a number of events but I'm not sure which one is the best one for our case.

We could trigger autosave on:

• When the editor loses focus, i.e. "blur" (the change event on the wysihtml5.Editor object)
• When a new word is entered, essentially when the space bar is pressed within the editor (the newword event on the wysihtml5.Editor object)
• Every X seconds

There's some "cost" to making a request to the server every time we save our item, so we want to autosave as little as possible. Of these options, I think I like either the blur event, or the time-based event. The blur event won't save as often, but it definitely addresses the case that seems to motivate this feature: clicking away from the editor without remembering to click the save button.

I've also done a little more thinking about the buttons. I think we should keep the Cancel and Save buttons to be consistent with other asset types and the previous behavior. The behavior would be:

• Save - perform a final, explicit save, just like the present functionality
• Cancel - If the model is new, remove it from the section. If the model had content, revert to the previous content, before the user clicked "Edit" and save the old text to the server.

[ghing]

Brainstormed test cases:

• typing in the text asset editor, then clicking on the change section layout button [desired behavior would be to autosave the text asset, and then put it into the asset drawer]
• Add new text asset, trigger autosave
• Edit text asset, add new section (should trigger autosave)
• Edit text asset, move section
• Add a new text asset, edit text, click cancel (asset is removed, not sent to drawer)
• Edit an existing text asset, edit text click cancel (text before the "edit" link was clicked is restored, view switches to display state)
• Add a new text asset, edit text, edit asset in another container in the same section (should trigger autosave)

[ghing]

@jwirfs-brock Reported that the text wasn't being autosaved when switching sections. I did some debugging and this is what I found:

• The current implementation listens to the wysihtml5 editor's 'change' event
• The change event is fired on the editor element's blur event.
• The blur event is only fired when another element gains focus
• Clicking on another section doesn't cause a new element to gain focus, so blur/change are never fired

Quirksmode has a good rundown of all the weirdness (e.g. Chrome doesn't trigger focus/blur when clicking on links with the mouse) around these events.

There doesn't seem to be a prefarable wysihtml5 event to listen to, but perhaps we could listen on a DOM event (like mouseout).

[ghing]

I tried listening to mouseout events like this:

        view.bodyEditor.on('focus', function() {
          var editor = this;
          $(editor.currentView.element).on('mouseout', function() {
            view.form.fields.body.editor.determineChange();
          });

          $(editor.toolbar.element).on('mousein', function() {
            view.preventDelayedSave();
          });
        })
        .on('blur', function() {
          $(this.currentView.element).off('mouseout');
          $(this.toolbar.element).off('mousein');
        });

but it didn't work great, largely due to the toolbar being outside the element itself. Next idea is to trigger autosave on keyup, but debounce the functions.