Choice #2: Validate a new route before navigating to it?

Another choice to make is whether you want to validate a new route before your app navigates to it. I talked about this in a previous post. The idea is that your SPA code will validate any new route before actually navigating to it. The app stays on the current page, until the necessary data for the new page is in, and until the new route is validated.

Loading and validating on the new page has an advantage: the user will immediately and clearly notice that the app responds to navigation. And in most cases, there will be valid content to show on the new page, right?

My personal preference is to load and validate before navigating to a new page. I find it more user friendly to let the user spend any waiting time on the current page, instead of on some empty new page.

But that’s your choice really.

Choice #3: Only <a> links for navigation in your view functions?

Another choice is whether you will only use a [ href .. ] elements in your view functions for navigation. After all, this is standard HTML for navigation links. My preference is to always use a elements in my views for navigation.

But this may not always be an option. If you are using a UI library like mdl or elm-ui, then you may want or need to assign navigation actions to other HTML elements too.

If you do use more than just a elements for navigation, there is still a trick you can use to make any element behave like a link. Which brings us to choice #4..

Choice# 4: Are you OK with a javascript trick for non < a> elements in your views?

There is a trick you can use to make any element behave like a link. It uses the possibility to provide a one-line javascript statement to the attribute from the Html.Attributes package:

div [ customRef "/movies/maleficent" ] [..]



-- Custom helper function

customRef : String -> Attribute msg

customRef path =

let

javascriptCode =

"history.pushState({},'','" ++ path ++ "');"

in

attribute

"onclick"

javascriptCode

The javascript-oneliner history.pushState() will push a new entry to the browser’s history. This will in turn fire the UrlChange message in your elm app, to handle the new route. To make this happen upon a user click, it is provided to the onclick attribute of the element.