Configuration Option for Reload Prompt

[joshua-dean]

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.

[TrevorBurgoyne]

As of https://github.com/SenteraLLC/ulabel/pull/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]

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]

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 🤷