Follow-up to #138, which added an optional redirectUri to requestMagicLink.
That is reachable only from the headless client path. An application using the bundled AuthRoutes has no way to set one: Login.sendMagicLink calls authClient.requestMagicLink() with no argument, and there is no prop or provider option carrying a destination. So the deployment-wide destination is still the only option for anyone using the batteries-included UI, which is the audience least likely to be wiring up their own client.
Scope
Give the destination a route into the bundled views. Most likely an AuthProvider option, since it is application configuration rather than something a user chooses in a form, and it would then be available to any view that needs it.
The part to get right
MagicLinkSent.resend also calls requestMagicLink() with no argument. Today that matches Login, so the two agree and there is no bug. The moment Login starts sending a destination and the resend does not, a user who clicks "resend" gets a link that lands somewhere different from the first one, which is a confusing failure and an easy one to miss in review.
Login navigates to magicLinkSent with { state: { identifier } }, so the state channel between the two views already exists if the destination should travel that way rather than coming from a provider.
Notes
Not urgent. Nothing is broken today, and the headless path covers the case the API change was built for. This records the gap and the resend trap while the reason for both is fresh.
Follow-up to #138, which added an optional
redirectUritorequestMagicLink.That is reachable only from the headless client path. An application using the bundled
AuthRouteshas no way to set one:Login.sendMagicLinkcallsauthClient.requestMagicLink()with no argument, and there is no prop or provider option carrying a destination. So the deployment-wide destination is still the only option for anyone using the batteries-included UI, which is the audience least likely to be wiring up their own client.Scope
Give the destination a route into the bundled views. Most likely an
AuthProvideroption, since it is application configuration rather than something a user chooses in a form, and it would then be available to any view that needs it.The part to get right
MagicLinkSent.resendalso callsrequestMagicLink()with no argument. Today that matchesLogin, so the two agree and there is no bug. The momentLoginstarts sending a destination and the resend does not, a user who clicks "resend" gets a link that lands somewhere different from the first one, which is a confusing failure and an easy one to miss in review.Loginnavigates tomagicLinkSentwith{ state: { identifier } }, so the state channel between the two views already exists if the destination should travel that way rather than coming from a provider.Notes
Not urgent. Nothing is broken today, and the headless path covers the case the API change was built for. This records the gap and the resend trap while the reason for both is fresh.