How do you handle situations like this: Your application navigates to some route that involves loading some data. Lets say its a folder that may contain some images. Browser.Navigation.pushUrl key "/myapp/folder/1/" results in Browser.application.onUrlChange being called. The URL is parsed to get a new route, and this triggers the next step, which is to see what is in the folder. An HTTP request is made to fetch the contents of folder 1. There may be no images in it, but in this case a list of image files and their URLs comes back. In this particular application, if there are no image files we just want to list what files are in the folder (maybe some non-image files), but if there are images, we want to show the first one. The Model is updated to reflect that a single image is to be shown, and the view displays it. Since we are now on a particular image, we want to update the URL to reflect that (in case the user bookmarks it): Browser.Navigation.pushUrl key "/myapp/folder/1/holliday-snaps.jpg" results in Browser.application.onUrlChange being called. The URL is parsed to get a new route, and this is different to the folder route we were on previously. This application reacts to this route change by loading the image again, even though that is the state we are already in. In other words, I just want to change the URL, and not fire an event that will trigger whatever side-effects the application generates when switching to a new route. Seems like one answer is that I should store the current route in the top-level Model, change that to ViewImage (Folder 1) "holliday-snaps", then push that URL. In onUrlChange compare the new route to the current one, find that there is no change, and fire a Noop to ignore it. Sometimes feels like there should be additional options to Browser.Navigation.pushUrl/replaceUrl that simply sets the URL in the browser, but does not trigger a navigation event to Browser.application.onUrlChange. I feel this area of Elm applications can easily get a bit muddled, and interested to hear how others deal with this to ensure that the URL is always accurate and changes to it do not result in duplication of side-effects.

Thinking about this some more, I realised my example works better the other way around. Suppose a user ends up at /myapp/folder/1/holliday-snaps.jpg, and bookmarks it because it is a nice picture. Later on they return to this bookmark, but the picture has been deleted. The application responds to a 404 on an image in a folder by showing the rest of the folder of images as thumbnails so they can perhaps choose something else. The URL for the folder would be /myapp/folder/1/. The normal sequence of events is that the user or application navigates to a URL, and then the application responds by setting itself up in the correct state to display the requested information. Sometimes something happens, and the application cannot achieve the originally requested state. It shows a different state instead. If that state has a particular URL that describes it well, it is helpful to update the URL to that (possibly also adding it to the browsers history). In this case, it is not the application state that follows from the URL, but the URL that follows from the different application state chosen. That update to the URL should not trigger a repeat of the work needed to get to that state, since the application is already in it. The question is how do you tie the application state and route together such that one can follow from the other in either direction? It seems like some de-duplication is required, either on the routes or on the application state, where is best to do that? Or perhaps it is possible to always arrange that the flow in an application is always unidirectional (route → state and never state → route)? Examples or thoughts appreciated. :thinking:

I don’t think this issue is particularly unique to Elm. It comes up lots of front-end frameworks. IMO, if fetching data is your bottleneck (and it often is), setting even fairly short cache times on the HTTP responses can go a long way to reducing duplicate network activity, even if the app thinks it’s making requests from scratch each time. Then you don’t have to worry about whether route is driving state or vice versa. There are lots of front-end frameworks that have libraries for caching responses to XHR requests in JS memory rather than the browser cache. I’m not generally a fan of that approach, but lots of other people seem to be. It seems like maybe you’re also trying to get at a more general question, but maybe this is a case where generalizing the problem only makes it harder, and it’s better to just solve specific cases for specific apps/features?

We ended up applying a simple rule: All state changes and side effects that are linked to a url should be a reaction to the url change. Then, in the image example, just push the new url, and wait for Elm to react to this change. Many times we move side effects calls from update to init of a page because we exposed them as query string arguments, which means that they have become linked to the url. This rule has clarified and simplified the scenarios that before were a bit messy. Then, we also make the check for duplicate urls a responsibility of each page because sometimes you might want to allow it and sometimes not.

In our framework we default to the load the world approach - i.e. a url change would call the page’s init function that would presumably load stuff from scratch (although our framework does support caching which can also mitigate this problem). However, for cases like this a page can opt in to instead receive a onFlagsChanged message which is meant for situations akin to this (for us for instance if a user types into a search field, we want to persist the search in the url, but don’t want to reload the whole page on every keystroke). We call it onFlagsChanged since our framework decides which page to show based on a function matchRoute : Route -> Maybe flags, where flags is sent as the input to a page’s init function, and the framework loads the first page that evaluates to Just. Hence we detect this situation by checking if the matchRoute oldRoute evaluates to Just x, and matchRoute newRoute evaluates to Just y and x /= y, then we can alert the page to this condition.

[image] matt.cheely: I don’t think this issue is particularly unique to Elm. It comes up lots of front-end frameworks. IMO, if fetching data is your bottleneck (and it often is), setting even fairly short cache times on the HTTP responses can go a long way to reducing duplicate network activity, even if the app thinks it’s making requests from scratch each time. Then you don’t have to worry about whether route is driving state or vice versa. The particular issue I have (which is in a propriatary codebase not the example folder-of-images-app described above) is not that I am worried about making the same HTTP request more times than needed - It is that the application has an issue reliably creating its state from the URL, if the same state is initialized more than once! It is a bit of a difficult one to tackle, as the state is spread out in quite a few places, but it is essentially an issue of being able to represent illegal states. I was able to fix it by writing some JS code on a port, and calling it Navigation.silentReplaceUrl. As you can guess from the name, this sets the browser URL, but does not trigger a navigation event back to Browser.application.onUrlChange. This is a tactical fix that will do for now, but it feels hacky. The proper fix will be to sort out the illegal states and latching issue that happens during init (its a bit like latching during a reset in digitial circuit design isn’t it?) [image] matt.cheely: It seems like maybe you’re also trying to get at a more general question, but maybe this is a case where generalizing the problem only makes it harder, and it’s better to just solve specific cases for specific apps/features? Yes, I’ve now seen the wrong way of doing it, so I got curious about what is the correct way, if I were writing another application from scratch. I think handling specific cases without sight of what principles could be followed to ensure that navigation always works cleanly, is probably a bad idea, and the kind of thinking that lead to my problems in the first place. @francescortiz , @gampleman - you both seem to be advocating the forward only, url -> state approach, which seems like the right principle to follow. Browser.Navigation.pushUrl always triggering an event -> Browser.application.onUrlChange also seems to bias Elm applications towards working that way. I am thinking that checking for a duplicate route is best done on the Route and not the application Model (or page State or however you model your state)?

[image] rupert: I am thinking that checking for a duplicate route is best done on the Route and not the application Model (or page State or however you model your state)? What if you have a route that every time you access it gives you random dice throw. Then it makes sense to allow for duplicate urls. As long that you take into account that some urls might want repetition, then where the logic sits doesn’t seem that relevant to me right now.

Something along the lines of: type Route = ShowImage Folder ImageId | RollDice | ... dedupeNavEvent : Route -> Route -> Bool dedupeNavEvent current proposed = case (current, proposed) of (ShowImage folder1 image1, ShowImage folder2 image2) -> Folder.isEqual folder1folder2 && ImageId.isEqual image1 image2 |> not -- Don't re-route to the image we are already showing. (RollDice, RollDice) -> True -- Always roll again _ -> True -- All False cases should be covered above update msg model = case msg of ... OnUrlChange route -> if depdupeNavEvent model.currentRoute route then changePageToRoute route model else (model, Cmd.none) -- Already on the requested route and in the correct state.

I wrote a bit about this here a couple months ago: [image] "Route reuse" + looking for general advice Learn I’ve found the onUrlRequest / onUrlChange bifurcation in Browser.application to be really tedious to work with. It’s better than it was in 0.18, but still doesn’t feel natural to me. See more discussion in this thread: Since that thread, I’ve completed updating elm-route-url to 0.19 (but it hasn’t been merged yet). I’ve also built upon that to create a feature I call “anchor management”. I’ve been using it in my app for a while now and really like it. The basic idea is that your view fun…

The “philosophically” section of the elm-route-url readme has some good discussion and links too.

Using the URL both as a snapshot of the navigation state and as a source of truth for the navigation state looks like a bidirectional binding, which I something that I try to avoid as much as possible. In which situations do you see it as an advantage?

Routing when you already there

Learn

jerith December 12, 2021, 3:07am 9

I wrote a bit about this here a couple months ago:

Topic		Replies	Views
"Route reuse" + looking for general advice Learn	12	1971	November 2, 2021
Understanding the "double update" behavior of Browser.application Learn	11	2290	January 27, 2019
Solving Elm Router "Double Update" Problem Show and Tell	4	399	September 24, 2025
What is the Elm 0.19 equivalent of Navigation.modifyUrl Learn	2	1025	November 26, 2018
Do I have to save current URL into model if I want to use Nav.pushUrl? Learn	1	595	March 21, 2022

Routing when you already there

Related topics