simsalabim / sisyphus

Gmail-like client-side drafts and bit more. Plugin developed to save html forms data to LocalStorage to restore them after browser crashes, tabs closings and other disasters.
http://sisyphus-js.herokuapp.com
MIT License
1.99k stars 221 forks source link

Suggestion : onBeforeRestore/onRestore could get array of restored fields #138

Open nWidart opened 8 years ago

nWidart commented 8 years ago

Hello,

It would be nice of the onBeforeRestore and onRestore callback could get a parameter that contains an array of all the restored fields.

With this data we could do some custom logic on the fields for instance.

My use-case:

I display a warning message using the onRestore callback, to hint the user that some data was restored but not persisted.

I have a select, which doesn't have a default empty option. When reloading the page, or coming back to the form, it will always show the warning message. I'm guessing this is because of the dropdown that doesn't have an empty option.

I also can't use the ignore config since the restore on the dropdown can be useful if an option was selected, but not the first one.

Thank you,

thomas-preuss commented 7 years ago

Is onRestore() called everytime I re-visit the form or only if there is data locally stored?

Background: I want to display a hint if there locally stored, but unsaved data. It seems, that onRestore is called everytime:-(

Any help is welcome, Thomas

hbalagtas commented 6 years ago

I'm having the same issue as @thomas-preuss every time a user goes to my form even though there is no saved data for that form the confirmation is fired. Is there a way to tell if there is saved data or not?

$('#rtform-{{$asset->id}}').sisyphus({ excludeFields: $('.exclude-sisyphus'), onBeforeRestore: function(){ return confirm('Would you like to restore saved form data?'); }, });

brendon commented 6 years ago

I'd like to chime in on this one too. It seems to fire even on pages that don't have matching jQuery elements.

simsalabim commented 6 years ago

@nWidart sorry, I can't contribute much to the original feature request but am open to seeing what you mean in a pull request.

@thomas-preuss looks like this is your answer, that's a conditional call.

@brendon onBeforeRestore doesn't depend on the presence of the target elements, judging by this code.

brendon commented 6 years ago

Thanks @simsalabim, I see what you mean. What is your opinion on that? I'd imagine most users would only expect the callbacks to fire if there are target elements to fire them on?

Perhaps onBeforeRestore could fire once per target form (if it has anything to restore), passing in the form?

My use case is that I want to ask the user if they want to restore the saved form or not. I initially decided to create a selector $('form.recoverable') to abstract this away.

simsalabim commented 6 years ago

I'd imagine most users would only expect the callbacks to fire if there are target elements to fire them on?

What if a callback's logic has nothing to do with target elements? But if callbacks always fire, you can check inside the callback if there are target elements and go from there.

brendon commented 6 years ago

That's true. In what situation would you imagine that would be the case? :) Just trying to get my head around it. I was going to do a PR with the modification but if it's not the direction you want to go then I can work around it as you mention :)