Support for window.onBeforeUnload-like behavior with navigation system

dowhilegeek · June 26, 2024, 6:47pm

In our application, we have very large forms and we would like to warn the user before they navigate away that their form is dirty. Right now, we can use window.beforeUnload to catch “browser-level navigation”, but seemingly we can’t do something similar with RedwoodJS-based navigation. I’ve looked through the navigation documentation and I don’t seem to see what I’m looking for there. Am I missing something, or is this something that RedwoodJS doesn’t support right now? I’m sure we’re not the only folks that would like to parry an accidental navigation

Tobbe · June 26, 2024, 7:15pm

Would this PR help you?

github.com/redwoodjs/redwood

feat(router): add router useBlocker hook

redwoodjs:main ← xmaxcooking:xmax-router-blocker-hook

opened 03:54PM - 24 Jun 24 UTC

xmaxcooking

+131 -25

Successor of: https://github.com/redwoodjs/redwood/pull/9843 Can be used like… this: ``` const PostForm = (props: PostFormProps) => { const form = useForm<FormPost>() const blocker = useBlocker({ when: form.formState.isDirty }) return ( <div className="rw-form-wrapper"> <Form formMethods={form} onSubmit={onSubmit} error={props.error}> State {blocker.state} {blocker.state === 'BLOCKED' ? ( <div> <button type="button" onClick={() => blocker.confirm()}> Confirm </button> <button type="button" onClick={() => blocker.abort()}> Abort </button> </div> ) : null} ... </Form> </div> ) } ``` `Tab close`, `Browser Close` and `Navigation` with the redwood router components and functions can be blocked. The only thing not working is the interception of the browser `back` button. I found possible solutions to block the navigation `back` too, but not without losing any user changes and/or messing with the history. React-router defined the situation like this: https://github.com/remix-run/react-router/blob/aacc2b94088835d1247bdf3a3f883f74cc3570a0/decisions/0001-use-blocker.md?plain=1#L37C1-L37C127 `Blocking POP navigations is different - since we don't know about them via popstate until _after_ the URL has been updated` Currently the redwood router and the active page are coupled to the real location (URI) and it would require a refactoring to couple it with something like a location proxy instead which could be kept in sync with the history and location. Any thoughts? Would a refactoring be worth it? Or is this implementation with a missing piece of functionality good enough?

dowhilegeek · June 26, 2024, 7:23pm

That looks like its exactly what we’re looking for .

Tobbe · June 26, 2024, 7:27pm

Cool! As I said in the PR - I’ll take a look as soon as I find some free time for it