Autosave entire edit form with debounce
Hi all
Has anyone implemented autosaving for an entire edit page's form, along with some kind of debounce? I'll need to use debounce to avoid blowing up my server.
Honestly have no idea on the approach to take for this one...
Would I have to set
live, debounce and use afterStateUpdated on every field of the form? Or is there a cleaner way?
Also not really sure of the best way to save the current form state to the record using afterStateUpdated
Any help or suggestions would be appreciated. Thanks!16 Replies
I'm interested in this. I don't have a solution unfortunately, but if you want to think outloud...
How would the autosave interact with form validation?
That's a good point... Hadn't considered that 🤔
If the ideas is to save a draft, it shouldn't be too complicated to save a dump of all fields without validation. Probably not directly on the record, maybe in like a separate table?
Ideally there'd be a way to save the raw form state without any validation, then just repopulate the fields
lol
Yeah exactly
Maybe this could be done with
wire:poll? At an interval, call a method that will get the raw state of the form and dump it in the autosave table.Separate drafts table + a relationship to the resource which is checked when the edit form is re-opened, and if an entry is found, a modal appears saying there's an autosave and do you want to restore it
Plus something like wire:poll, yeah
I think relationships will be the main issue.
Could also take a look at the form hash logic that the unsaved changes feature uses. I dug into that a bit in my PR to add it to SPA mode. It takes a hash of the current state, then compares it to the current state when the user tries to leave the page. It all happens on the frontend.
I wonder if something similar could be used to prevent endless polling if the user leaves a page open overnight?
I.e. just autosave if there has been a change
I guess you could store the hash of the last autosave in localstorage maybe?
Yeah, interesting. Maybe this could be done in JS instead of
wire:poll. You could add a custom event listener to the form to make all fields behave as "lazy", and trigger the autosave on blur. I'm doing something similar in Peek actually. Hehe.Yeah that's what I was thinking. A bit above my skillset to implement though.
Oh nice, that'd be a sweet addition to Peek! Btw let me know when you've got that in-form preview field ready to test - keen to try it out and give feedback
Back to the autosave though - I think some kind of drafts / restore draft dialog system is pretty essential tbh. Data loss when authoring long-form content is such deal-breaker for so many apps. Dan wasn't above adding some extra tables for import / export. Maybe he'd consider something similar for an autosave feature?
Otherwise a plugin would be great, but I'm not sure you'd be able to hook into enough core functionality with a plugin to make it work
I know @Dan Harrin hates being pinged and will probably ban me for life, but there are some interesting ideas here. May be worth a look
updatedData() method, add a rate limiter, and call $this->save()That would overwrite the main content though, not save an autosave draft right?
The idea of a drafts table for a timed autosave feature for resource edit pages that was discussed above was what I meant. Could be cool in core.
you can use a drafts plugin then instead of saving?
as a general rule, we dont add features with opinionated db structures in core
what you're asking for is way too CMSey for the core framework
Yeah that's fair enough. The current drafts plugins don't really do the autosave / optionally-recover-autosave-on-crash thing we're talking about - could be a good candidate for a new plugin
Maybe something you could tackle @pboivin 🙂
I'll poke around. I don't really have a need for this atm but it's been coming up one in a while in the chat. It would be a cool plugin.
For sure. I think a lot of people would really use / appreciate it.