Routing in Elm

Key takeaways:
Elm requires manual routing; no built-in support.
Routing enables smooth view transitions in SPAs.
Define views in a custom model type (e.g., Home, Settings) to represent app state.
Use messages and the update function to manage state changes.
Create view functions for each state to render specific content.
Handle navigation with onClick events to trigger view changes.
Elm’s declarative routing keeps navigation clear and consistent.

Routing refers to the navigation or moving between different views or pages. Elm doesn’t support built-in routing. To do so, we need to manually manage the URL. It involves updating the state and view accordingly. A popular third-party library, elm/browser, is widely used for manually managing the application’s state.

Motivation for routing in Elm

Routing is fundamental to any modern web application, particularly in SPAs where users expect seamless transitions between different views without full page reloads. In Elm, routing isn’t provided out of the box, but understanding how to implement it manually is crucial for creating dynamic and interactive web applications. By mastering routing in Elm, developers can build applications that provide a more fluid user experience while maintaining the benefits of Elm’s strong type system and functional programming paradigm.

Steps to handle routing

Below are steps to handle routing in Elm:

Define the model

Include a type in the model to represent different pages/views. For example:

type Model
  = Home
  | Settings

The type Model declares a new custom type. In the context of an application, the Model type represents the state. Here, “Home” and “Settings” are two views. It means the application can either be in the Home or the Settings state.

Update the message

Define a message to change the current page. For example:

type Msg
  = ChangePage Model

Modify the `update` function

To update the model, it’s necessary to handle the ChangePage message in the update function. For example:

update : Msg -> Model -> Model
update msg model =
  case msg of
      ChangePage newPage ->
          newPage

When a ChangePage message is received, it updates the state to the new page specified by newPage. This is a simple state transition where the model is replaced by the new model specified in the msg. ]

Create views

Create a view function for each page/view. For example:

view : Model -> Html Msg
view model =
  case model of
      Home ->
          -- render home page

      Settings ->
          -- render settings page

For each view, we can create a different case. The view function checks the current state of the application.

If the model is Home, it renders the HTML for the home page.
If the model is Settings, it renders the HTML for the settings page.

Handle navigation

Use Html.Events to capture user interactions. For example, you can handle clicks on navigation links:

type Msg
  = ChangePage Model
  | NavigateToHome
  | NavigateToSettings

Next, modify the update function accordingly:

update : Msg -> Model -> Model
update msg model =
  case msg of
      ChangePage newPage ->
          newPage

      NavigateToHome ->
          Home

      NavigateToSettings ->
          Settings

The update function is modified to handle the new message variants:

ChangePage newPage: When this message is received, the function updates the state to newPage.
NavigateToHome: The function updates the state to Home when receiving this message.
NavigateToSettings: The function updates the state to Settings when receiving this message.

Add navigation links

Include links that trigger the navigation. For example:

view : Model -> Html Msg
view model =
  div []
      [ a [ onClick NavigateToHome ] [ text "Home  " ]
      , a [ onClick NavigateToSettings ] [ text "Settings  " ]
      , case model of
            Home ->
                -- render home page

            Settings ->
                -- render settings page
      ]

For navigation links:

a [ onClick NavigateToHome ] [ text "Home " ]: This creates an anchor element that acts as a link to the “Home” page. It has an onClick event handler that triggers the NavigateToHome message when clicked.
a [ onClick NavigateToSettings ] [ text "Settings " ]: This creates an anchor element that acts as a link to the “Settings” page. It triggers the NavigateToSettings message when clicked.

Inside the case expression, the Home -> branch is executed when model equals Home. It typically contains the HTML markup specific to the “Home” page. The Settings -> branch is executed when model equals Settings. It typically contains the HTML markup specific to the “Settings” page.

{
    "type": "application",
    "source-directories": [
        "src"
    ],
    "elm-version": "0.19.0",
    "dependencies": {
        "direct": {
            "elm/browser": "1.0.1",
            "elm/core": "1.0.2",
            "elm/html": "1.0.0",
            "elm/time": "1.0.0",
            "elm/http": "2.0.0",
            "elm/json": "1.1.3"
        },
        "indirect": {
            "elm/url": "1.0.0",
            "elm/virtual-dom": "1.0.2",
            "elm/bytes": "1.0.8",
            "elm/file": "1.0.5"
        }
    },
    "test-dependencies": {
        "direct": {},
        "indirect": {}
    }
}

Routing with two different views in Elm

In lines 46–47, we set up the main entry point for the Elm application. In the output, we can see two views: “Home” and “Settings.” Clicking the option will reroute us to the specific page.

Conclusion

Elm is well-suited for building SPAs, where routing is crucial for managing different views or pages within the application without full page reloads. Elm’s approach to routing ensures smooth navigation and seamless integration with the application's state management. Elm’s routing solutions often emphasize a declarative approach, where routes are defined in a clear and understandable manner. This makes it easier to reason about navigation flows and maintain consistency across different parts of the application.