Implementing automatic saving in a TinyMCE-based form

Other Questions Google docs
1

Hey folks, I’m working on a form that uses TinyMCE Editor on a LAMP setup. I want to add an auto-save feature like the one in Google Docs. I’ve been thinking about two ways to do this:

  1. Send an Ajax request every time a key is pressed
  2. Send an Ajax request every minute

The first option seems like it would put too much strain on the server. Does anyone have a better idea than the second option?

Update:

I’ve come up with a third option:

  1. Send an Ajax request every minute, but only if there’s been a big enough change (like 10 or more characters)

Any thoughts on this? I’d love to hear your ideas!

Update 2:

I’ve put together a basic version based on option 3. Here’s how it works:

function initEditor() {
  tinyMCE.init({
    // other settings...
    on_key_up: countKeystrokes
  });
}

function countKeystrokes() {
  let count = parseInt(document.getElementById('keystrokeCount').value);
  document.getElementById('keystrokeCount').value = count + 1;
}

function saveAutomatically() {
  let keystrokeCount = parseInt(document.getElementById('keystrokeCount').value);
  if (keystrokeCount > 30) {
    tinyMCE.triggerSave();
    let formInfo = new FormData(document.getElementById('editorForm'));
    fetch('/save', {
      method: 'POST',
      body: formInfo
    })
    .then(response => response.json())
    .then(data => {
      if (data.ok) {
        document.getElementById('keystrokeCount').value = 0;
      }
    });
  }
  setTimeout(saveAutomatically, 10000);
}

document.addEventListener('DOMContentLoaded', function() {
  initEditor();
  saveAutomatically();
});

This setup saves the content every 10 seconds if there have been more than 30 keystrokes. What do you think?

2

Having worked on similar projects, I can offer some advice based on my experience. Your third option is a good start, but you might want to consider a more sophisticated approach. Instead of relying solely on keystroke count, you could implement a debounce function. This would trigger a save after a short period of inactivity, say 1-2 seconds after the user stops typing.

Additionally, you could combine this with a periodic save, perhaps every 2-3 minutes, to ensure you don’t lose large chunks of work if the user is continuously typing. Don’t forget to add a save trigger when the user leaves the editor area.

On the server side, consider implementing a diff algorithm to only save the changes rather than the entire content each time. This can significantly reduce server load and improve performance, especially for larger documents.

Lastly, make sure to provide clear visual feedback about the auto-save status to improve user confidence in the system.

3

hey man, ur approach looks solid! i’d suggest adding a debounce function tho. it’ll prevent too many saves when someone’s typing fast. also, maybe add a visual indicator so users know when it’s saving? like a lil spinning icon or smthin. keeps ppl from worryin bout losing their work, ya know?

4

I’ve implemented a similar auto-save feature in one of my projects, and I can share some insights from that experience. Instead of using a fixed interval or keystroke count, I found that a combination of time-based and event-based triggers worked best.

Here’s what I did:

  1. Set up a debounce function with a 2-second delay after the last keystroke.
  2. Implement a 30-second timer that forces a save regardless of user activity.
  3. Add a save trigger on the blur event (when the user leaves the editor).

This approach reduced unnecessary server requests while ensuring frequent saves. It also handled cases where users made small, infrequent edits or left the page without explicitly saving.

For the server-side, I used a diff algorithm to only save the changes rather than the entire content each time. This significantly reduced the payload size and improved performance.

Remember to provide visual feedback to users about the auto-save status. A small indicator showing ‘Saving…’ or ‘All changes saved’ can greatly improve user confidence in the system.