Router Set: distinction between unauthenticated vs not having a role

[Tobbe]

On the sign-in page you could check if the user is already logged in, and if so check their roles. Then you could display the correct error message and UI depending on what roles they have.

Or you have a separate page for that logic that you use for the unauthenticated prop. And if the user isn’t logged in you can do a manual redirect to the sign-in page.

I’m personally not a big fan of adding too many props to our router components (routes, sets, etc). But I think your question highlights a need for what I call “route guards”. I.e. a more powerful/flexible way to determine who can access what routes. It’s been discussed here:

Feature proposal: `useGuard` hook for checking preconditions on page render

Hey everyone! I’ve been struggling for the last few days with the right way to check that certain preconditions are met when rendering a cell or a page. And I think I’ve come up with a pattern that feels both robust and generally useful that I’d like feedback on. Short version I wrote a new hook, useGuard, with the following type signature: function useGuard( condition: any, redirectTo: string | (() => string), options?: NavigateOptions ): asserts condition the useGuard hook checks th…

And your exact use case has been discussed in the linked RFC issue:

[RFC]: Add a authenticated props for Private Set