Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configuration Option for Reload Prompt #119

Open
joshua-dean opened this issue Jun 30, 2023 · 3 comments
Open

Configuration Option for Reload Prompt #119

joshua-dean opened this issue Jun 30, 2023 · 3 comments
Labels
enhancement New feature or request

Comments

@joshua-dean
Copy link
Collaborator

There is a beforeunload eventListener which prompts the user to confirm navigation on unsaved changes.
There's a number of ways to implement ULabel into a project whilst allowing it to persist through several different annotation jobs, and depending on how they set the saved state this can break them.

Disabling this eventListener should be a configuration option, and additionally some reload/save utilities might be useful to streamline how different use cases manage state/save-state whilst doing soft/hard reloads.

@joshua-dean joshua-dean added the enhancement New feature or request label Jun 30, 2023
@TrevorBurgoyne
Copy link
Member

As of #135 a set_saved argument is available for custom submit buttons, this is what I have been using to avoid the beforeunload warning on custom submit navigation logic

@joshua-dean
Copy link
Collaborator Author

So if I'm understanding the logic correctly - every submit button has a optional set_saved entry. If provided, on pressing the submit button ULabel's edited value gets updated to the value of set_saved, effectively giving each button the power to fully invalidate or validate the edited state, correct?

Is there ever a case where it's useful for a submit button to set edited to false, forcing the prompt? I'd argue set_saved should be a binary rather than an optional binary: it either sets the value to true or does nothing (defaulting to false rather than null).

@TrevorBurgoyne
Copy link
Member

So if I'm understanding the logic correctly - every submit button has a optional set_saved entry. If provided, on pressing the submit button ULabel's edited value gets updated to the value of set_saved, effectively giving each button the power to fully invalidate or validate the edited state, correct?

Is there ever a case where it's useful for a submit button to set edited to false, forcing the prompt? I'd argue set_saved should be a binary rather than an optional binary: it either sets the value to true or does nothing (defaulting to false rather than null).

A reminder that set_saved is the opposite of the edited state:

  • set_saved(true) will set edited to false
  • set_saved(false) will set edited to true

The unload warning occurs when edited state is true

If the button arg set_saved defaults to false, then in the case where no edits are made and then a submit button is pressed, the unload warning will appear bc the button itself is marking the edited state as true. So I agree that I honestly don't see a use case for setting edited to true on button click.

So as is, we can technically achieve three kinds of behavior:

  • set_saved: true will NEVER show the unload warning when submitting
  • set_saved: false will ALWAYS show the unload waning when submitting
  • set_saved: null will show the unload warning when submitting only if something was edited

To go from optional binary to binary, we'd want to change set_saved: false to be the default, while also changing its behavior to be that of set_saved: null. So we lose the ability to ALWAYS show the unload warning, which i agree is useless anyways.

TL;DR the switch from optional binary to binary would eliminate one of the three current options, which also happens to be practically useless anyways 🤷

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants