Provide a way to set the scroll behaviour when using redirect in a Server Action

[schimi-dev]

Goals

1. Provide a way to handle the scroll position when using redirect in Server Actions, similar to router.push and router.replace on the client.

Non-Goals

Everything else regarding Server Actions works fine for me :)

Background

When using router.push, router.replace and Link we can define whether to scroll to the top of the page or remain the position via a scroll option. When using redirect in a Server Action the app currently behaves as if { scroll: false } was passed to router.push.

However, there are use cases where a Server Action redirect should scroll to the top and other use cases where the scroll position should be kept unchanged by a redirect.

Proposal

Instead of providing a redirect function like this redirect(path, type), the second argument could be made an object of options. In Server Actions, or generally in a Streaming Context a scroll option could be made available when using redirect.

E.g.:

redirect('/dashboard', { type: 'push', scroll: true })

`

[valse]

I'm using the redirect method from an action to send a request information form and let the user to see a thank you page; the problem is that the form is to the page bottom and after the redirect the scroll still at the same point and not restore to the top.

[schimi-dev]

Yeah, this currently impacts the UX regarding redirects after form submissions negatively.

[gabooh]

Same problem here. Still looking for a solution.

[gabooh]

I use a hard redirect with an absolute URL to workaround the issue. Not optimal, but until there is something better it will do... :)

[SmartMointy]

Why don't you use an onClick function like:

const handleSubmit = () => {
    window.scrollTo({ top: 0, behavior: "smooth" });
}

You could also scroll to a specific position, e.g., where you show a “Thank You” message. You could also check if the form is submitting and wait until it is successfully submitted before scrolling.

If JavaScript is disabled, the page will reload and scroll to the top anyway, I think.

[schimi-dev]

I know that there are several workarounds and yes, React is very flexible in solving almost any UI problem. Nevertheless, I think that adding such an option to the redirect function would be nice.

Moreover, explicitly explaining in the docs how redirect handles the scroll position might help with decision making when to use redirect. In the context of progressive enhancement, there are many use cases where it is not suitable to reset the scroll position, but where UI state has to be adjusted after a form submission. For such use cases, using redirect in combination with search params might be a suitable approach. However, since currently the docs regarding redirect do not state what is the (intended) behaviour regarding the scroll position, it is quite difficult to make design decisions based on that.

So, providing an option regarding the scroll behaviour, and explicitly documenting this can help a lot with making reliable design decisions on when to use the redirect function.

[oreqizer]

@schimi-dev see my answer below

[oreqizer]

you can add metadata to the redirect URL to e.g. display toasts, scroll pages, etc. this is why the scroll is false by default — to make it opt-in, which is what you want with server-side redirects

e.g. to display toasts, you can do redirect('/some-page?action-success=Submit+successful'); and have the following component somewhere at the top level in your app:

export function ActionSuccess(): null {
  const toasts = useToasts();
  const router = useRouter();
  const pathname = usePathname();
  const searchParams = useSearchParams();

  React.useEffect(() => {
    if (!searchParams.has('action-success')) {
      return;
    }

    toasts.add(
      {
        message: searchParams.get('action-success') as string,
        type: 'success',
      },
      { timeout: 5000 },
    );

    const search = new URLSearchParams(searchParams);
    search.delete('action-success');

    router.replace(makeURL(pathname, search), { scroll: false });
    // eslint-disable-next-line react-hooks/exhaustive-deps -- toasts causes infinite loop
  }, [pathname, searchParams, router]);

  return null;
}

you could make something similar to scrolling, e.g. by doing redirect('/some-page?scroll=true');

export function Scroll(): null {
  const router = useRouter();
  const pathname = usePathname();
  const searchParams = useSearchParams();

  React.useEffect(() => {
    if (searchParams.get('scroll') !== 'true') {
      return;
    }

    const search = new URLSearchParams(searchParams);
    search.delete('scroll');

    router.replace(makeURL(pathname, search), { scroll: true });
  }, [pathname, searchParams, router]);

  return null;
}

Mount this in your root layout (make sure the file you're exporting this from is use client; and you wrap it in React.Suspense) and then whenever you use the corresponing redirect in a server action, this will clear the query param from the URL and perform the desired side effect.

This is how success/warn/error banners used to be handled back in PHP days, without the URL cleanup.

[schimi-dev]

@oreqizer Thank you for your response. However, I think that your example actually shows why a scroll option should be built into the redirect function of the framework. In your scroll position example there are two aspects that negatively influence UX:

1. useEffect needs to be some kind of useIsomorphicLayoutEffect, where internally useLayoutEffect needs to be used on the client. Otherwise, redirecting and scrolling will not happen in the same paint of the UI, leading to a flickering of a non-scrolled page before scrolling.
2. route.replace might also be delayed, so additionally window.scollTo(0,0) will be required to actually have redirect and scrolling happen in the same paint on the UI.

I would prefer to call the redirect function in a server action as follows:

redirect(`/dashboard?${new URLSearchParams({ message: 'Successfully saved!' })}`, { scroll: true })

And on the page where I redirect to I just do:

export default function Dashboard({ searchParams }: { searchParams: { message?: string } }) {
  return (
    <Main>
      {searchParams.message && <Message>{searchParams.message}</Message>}
      <Heading>Dashboard</Heading>
      <Content />
    </Main>
  )
}

This will conceptually do redirect and adjusting scroll position in one paint, without any pitfalls that useEffect might expose and without requiring multiple paints of the UI.

[lasseklovstad]

This solution works, i found out that if you want to avoid the delay you can do this instead:

window.scroll({ top: 0 });
router.replace(makeURL(pathname, search), { scroll: false });

[richardaday]

It is ideal for the framework to manage scrolling. Scrolling is already managed on client side redirects. It would be great to expect similar scroll behavior when doing server side redirects.

[whoisarjen]

So the workaround is to use # in the end of your url someUrl?search#id where the id is id of the element you want to be scrolled to. Hope they will give us better tool :)

[fxckdead]

Another workaround is just to have a component that scrolls to top:

"use client";

import { useEffect } from "react";

export default function ScrollToTop() {
  useEffect(() => {
    window.scrollTo(0, 0);
  }, []);

  return null;
}

Then in any page component you can just call this <ScrollToTop /> and will do the magic.

[ryan-dahlia]

Is there any update to this?

[ScreamZ]

Interest in this @leerob, I guess this is really important as next js is a server-oriented framework for now and more and more redirect occurs on server side

[leerob]

I haven't seen it explicitly stated here, so in the interest of doing that: I would recommend doing the route transition in a client action, which calls the server action.

async function clientAction() {
  await serverAction()
  router.push('/route', { scroll: true }) // default is `true`
}

[ScreamZ]

This was what I expected seems fair :)

[schimi-dev]

@leerob Is supporting a scroll option when redirecting in Server Actions planned? Most forms that do a redirect are suitable for being implemented with support for Progressive Enhancement. The solution you suggested does not support Progressive Enhancement.

[khaledxyz]

Is there any update to this?

[mirageN1349]

any updates?

[BorisBarzotto]

update?

[renemundt]

I also need this. Any updates?

[cdorfer]

Me too. Update?