Process CentralAuth redirects on new lexeme as TempUser

[codders]

With T357024, the API will return a URL initialized by CentralAuth when a TempUser tries to create a new lexeme. We need to redirect to this URL instead of the new lexeme (the URL will then redirect to the new lexeme once it’s finished setting up the temporary account).

Bug: T357152

[github-actions]

https://b5df8f1cc0235e2249aa268f46dd14f6ef48--new-lexeme-special-page.netlify.app

[lucaswerkmeister]

I feel like we should turn the WikiRouter service into something else, because this basically takes the “routing” out of it – we still need it to be configurable (because we don’t want window.location to be assigned in the tests), but I wouldn’t call it a “router” anymore. Perhaps it’s a “navigator” now? (Though the Navigator API doesn’t include “redirect”-like functionality, so maybe that would be confusing.)

In theory we could also keep the “routing” in the service – e.g., the lexeme creator can return either a URL or a string, and if it’s a string then it represents a title and the router is still responsible for turning that into a URL – but that feels silly to me tbh. Having the lexeme creator always return a URL is cleaner, even if that means that it sometimes has an extra responsibility (turning a title into a URL).

We could also extract the changes to the router service into a separate commit (with or without a separate pull request) – first move the “routing” into the lexeme creator (but always using MwUtilGetUrl), then use the redirect URL in the response if it exists.

[codders]

What's the advantage for you of having the changes in a separate commit? I don't imagine that anyone will be interested in the intermediate state, and at this point its just extra work to turn the one commit into two individually meaningful and functional commits.

[codders]

I've updated this now to use the correct fields from the API response. In my local testing the redirect is functioning, so from my side this is now no longer WIP - it should be good to go (though it depends on those other changes).

[lucaswerkmeister]

What's the advantage for you of having the changes in a separate commit? I don't imagine that anyone will be interested in the intermediate state, and at this point its just extra work to turn the one commit into two individually meaningful and functional commits.

It makes the change easier to review, and at least for me, easier to work on as well; I start to get nervous if too many things are happening at once in a change ^^ (e.g. in the redirect/merge change I’m starting to lose track of what parts are done and what still needs doing)

[codders]

Okay. I split that into two commits. Can also make that two PRs if you prefer.

[lucaswerkmeister]

Seems to work fine locally, thanks!