Is a separate program for login a good idea in this case? How to route between?

The main reason separating the login page of my app into a separate Browser.document program is seeming like a good idea in my case is that I want to authenticate the user, then fetch the app state data from the DB and pass it into the main Browser.application through flags.

This would theoretically save the extra wiring of having to fetch that data to populate the model and pass it in through ports during runtime and also avoid having to cover the cases for when my model is not yet populated by making that state impossible.

Does anyone have experience with this approach or know if my reasoning is sound at least? Much appreciated.

1 Like

We do it in related way. Our login is a plain Rails page. Our Elm application is only served if logged in. It does simplify a lot.

The big drawback for us is deployment, as in our way we have to serve some views from Rails and we cannot put those in a CDN / S3 / whatever.

1 Like

Thank you for the affirmation Sebastian, that is encouraging to hear!

One piece I am still a bit hazy about with this idea is whether the login page needs to have a distinct url domain so it will not be considered ‘internal’ to the rest of the app’s internal url scope? Not sure how I would get back out of the main app program on logout otherwise?

One thing I added to our app at work recently was around this, I ended up adding a function to the onUrlRequest setup that converts it from an internal to an external link if it isn’t a valid Route in the app.

1 Like

Ah, that sounds like what I need, but how did you perform this conversion exactly?

I tried adding a case for the internal url update branch to redirect a ‘/login’ request to Nav.load "/login.html" instead of Nav.pushUrl for it. This partly worked but the login.html request was still captured within my main app and just redirected to the NotFound route. Hopefully if I figure out how to convert it all the way to an external url I can get around this? Or do I also need to make an extra exception in my routing as well maybe?

Much appreciated!

Yeah it is kinda tricky, we have a NotFound route as well, and the url parsing function goes from URL -> Maybe Route. In the onUrlRequest handler, if we get a Nothing it is converted to an external link, and then rely on the server returning the right html file for that path.

I tried to make it so that the app can enumerate all urls that it can handle, but we have some quirks because our user pages are at /:username and could conflict with routes from other apps, currently we have a list of reserved usernames that the route parser knows about, like app2, app3, etc. so we can say that /:username is valid as long as it isn’t one of the reserved names.

One other way you can switch between apps is doing it at each link, if you add a target to the link elm will skip handling that link when clicked, it’ll trigger a full page load, you can use "_self"

1 Like

Hm, this almost makes sense for me. I am just a little confused how you can end up with a route of Nothing if NotFound is a base case variant for a Route as well?

In my current setup, NotFound is not an actual Route variant, but rather a page/view that is only ‘routed’ to when my Maybe Route is a Nothing. That happens within the update’s onUrlChange path by calling: changeRouteTo : Maybe Route -> Model -> ( Model, Cmd Msg )

I think I am just a unclear how a NotFound (presumably default?) Route vs a Nothing Route can both be possible? Also, when you say you convert the Nothing to an external link, does this just mean using Nav.load instead of Nav.pushUrl for it, or is there an actual conversion mapping involved?

Thanks again, best.

In onUrlRequest we try to parse the route. If we get NotFound then we assume that is an external url and call Nav.load

1 Like

Hm ok, it looks like Parcel was just not building my login html page and I am able to Nav to it now with that in place. Thanks for helping me isolate the issue. Really appreciate the helpful feedback all!

Cheers :slight_smile:

We used to do that at first and it worked
well. I prefer to handle everything from a single frontend app now for deployment simplification

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.