feat: Update useBlocker hook to provide current and next location when conditionally blocking
#1790
Conversation
|
we wanted to follow react-router's API for this: https://reactrouter.com/en/main/hooks/use-blocker can you adjust your PR to match it? also, the location should be typesafe instead of just a additionally, we would also need tests for |
Yes sounds good, I will update the PR as soon as possible |
|
This implementation should now be providing the Things left to do:
I am not quite sure how to do with the old Would also like to give a quick pitch for a different interface that could be used for import React from 'react'
import type { BlockerFn } from '../../lib/router/qudak-router'
import { BlockerFn, useRouter } from '@tanstack/react-router'
type BlockerOpts = {
blockerFn: BlockerFn
disabled?: boolean
}
export function useBlocker({ blockerFn, disabled = false }: BlockerOpts) {
const { history } = useRouter()
React.useEffect(() => {
return disabled ? undefined : history.block(blockerFn as BlockerFn)
}, [blockerFn, disabled, history])
}Which gives very clean implementations for custom UIs using hooks and could look something like this: useBlocker({
blockerFn: () => {
if (blockerDisabled && blockerDisabled.current) {
blockerDisabled.current = false
return false
}
if (!blockerDisabled && _blockerDisabled.current) {
_blockerDisabled.current = false
return false
}
const shouldBlock = props.blockerFn()
if (!shouldBlock) return false
const promise = new Promise<boolean>((resolve) => {
modals.open({
title: 'Are you sure you want to leave?',
children: (
<SaveBlocker
onSave={onSave}
onDiscard={onDiscard}
close={() => {
modals.closeAll()
resolve(false)
}}
confirm={() => {
modals.closeAll()
resolve(true)
}}
reject={() => {
modals.closeAll()
resolve(true)
}}
/>
),
onClose: () => resolve(false)
})
})
return promise
},
disabled
})Any thoughts on this? |
tomrehnstrom
changed the title
blockerFnuseBlocker hook to provide current and next location when conditionally blocking
|
This would be a breaking change to |
|
While this might be out of scope for this PR. I think we can likely do much better from a type safety point of view for I was imagining a more type safe hook. useBlocker({ from: Route.fullPath, to: '..', blockerFn: ({ fromMatch, toMatch }) => // have I saved? })
When |
|
we should make this as typesafe as possible, as per @chorobin's comment. |
|
@tomrehnstrom, are you planning to continue working on this PR? Does anyone know a quick and dirty workaround I can apply in the meanwhile? |
Yes, but have been quite busy elsewhere recently. The way i have solved this quickly in our codebase is just to copy the history package index.ts file and make the changes required to make it work, and then use it as a custom history: const history = createCustomBrowserHistory()
export const router = createRouter({
routeTree,
defaultPendingComponent: FullWidthLoader,
defaultErrorComponent: RouterSuspenseErrorFallback,
defaultNotFoundComponent: Error404,
context: {
auth: undefined!,
queryClient
},
defaultPreload: 'intent',
// Since we're using React Query, we don't want loader calls to ever be stale
// This will ensure that the loader is always called when the route is preloaded or visited
defaultPreloadStaleTime: 0,
history
})With the changes in my first commits to this pr Then written a custom blocker hook like this: type BlockerOpts = {
blockerFn: CustomBlockerFn
disabled?: boolean
}
export function useCustomBlocker({ blockerFn, disabled = false }: BlockerOpts) {
const { history } = useRouter()
React.useEffect(() => {
return disabled ? undefined : history.block(blockerFn as BlockerFn)
}, [blockerFn, disabled, history])
} |
|
Thanks @tomrehnstrom, I needed this urgently and managed to make do with the suggested temporary solution for now. |
|
Hello @schiller-manuel, I have finally got this PR into a pretty nice shape. However, I am not sure about the way I implemented route from/to matching in the useBlocker hook, any suggestions there would be appreciated. |
☁️ Nx Cloud ReportCI is running/has finished running commands for commit 162a445. As they complete they will appear below. Click to see the status, the terminal output, and the build insights. 📂 See all runs for this CI Pipeline Execution ✅ Successfully ran 2 targetsSent with 💌 from NxCloud. |
Currently, when using the
useBlockerhook there is no way to ascertain where the navigation being blocked is headed.For my usage of blocking, this is necessary to allow navigation within a selected bunch of nested routes, but not allowing the user to exit the base route. Thought this could be a useful feature to have.