Open itpropro opened 1 month ago
I think instead of forcing the directory structure to be auth/login
, we should have an option to pass the route name (ex: just login
). Then it would be possible to automatically detect if i18n is installed, if it is, pass the name of the route to localeRoute and retrieve the localized name (ex: login__fr
or login__en
) or if i18n is not installed, simply resolve the provided name
I think instead of forcing the directory structure to be
auth/login
, we should have an option to pass the route name (ex: justlogin
). Then it would be possible to automatically detect if i18n is installed, if it is, pass the name of the route to localeRoute and retrieve the localized name (ex:login__fr
orlogin__en
) or if i18n is not installed, simply resolve the provided name
That's a good idea. This would only apply if nuxt-i18n is installed, no if vue-i18n is used (there could me multiple reasons for that), so I would also provide an array option with route rules that all redirect to your custom login page, so if wanted, the logic can be handled there individually. That would also handle some use cases outside or i18n.
Or maybe a onRedirect
callback like @nuxtjs/auth-next
and people handle the translation themselves
A custom login route is in the backlog, detecting i18n is probably not going to happen soon, as the users can implement their own login in a custom login site to handle multiple languages. Internationalized routes are pretty rare and more of a niche feature that adds a lot of complexity. Out of many projects I worked on for i18n, I only encountered one that actually did custom routes instead of translating the page, but I will still keep it in the backlog until I found a way to delegate this to the framework with something like callbacks/hooks that has minimal impact on the module.
Weird, I've done dozen of Nuxt 2 project and we've always translated the routes. To each their own 🤷♂️
I guess I prefer how @nuxtjs/auth-next
handle their middleware, you define the routes for login, logout, home, callback
URL and we use the onRedirect
callback to translate the route ourselves. And then you either load the middleware globally using router.middleware
(instead of the plugin injecting the middleware) and then you can use auth: false
or auth: "guest"
to override in the page component.
I don't like that the global middleware infer the pages from the file-system routing (which force the route URL).
There are definitely different requirements in terms of i18n, I probably just had a lot of projects without translated routes :)
The middleware is just a convenience, why it is kept as simple as possible. You can also just disable the middleware and use your own one for redirecting as well as creating redirected routes to the auth paths.
Like I said, I will definitely look into custom urls, especially for the base part (auth
), but I have to find a way that doesn't make it much more complex and which keeps it simple, if you do not want to use it.
@itpropro Yeah, I'll probably look into porting the middleware from @nuxtjs/i18n-next
in my app
The login urls are currently fixed to /auth/login or /auth/PROVIDER/login. It can help with i18n or other cases to have them customizable.
Follow up of #53