Modeling a save button in Elm

One common piece of functionality in web apps is the save button. I recently had to implement one for an Elm app and was reasonably pleased with the result, so I'd like to share the approach in this post.

I believe the approach would work regardless of what we're trying to save, whether it's garden designs or sheet music. In this post I'm going to use a blogging app as an example, but really we could be saving anything.

Our blogging app is going to be super simple: It's just a text area with a save button. We'd like the save button to behave in the following way:

1. If any unsaved changes exist, a 'Save' button will appear.
2. Clicking the 'Save' button will send an HTTP request with the current contents of the post.
3. The 'Save' button should be replaced with a spinner while the request is underway.
4. If the request fails an alert should be displayed.
5. The user can continue editing the post while it is being saved.

First lets decide on a type for our blog post. As I mentioned before it doesn't matter a ton what we're saving, so for the purpose of this example let's just take the simplest blog type we can think of: A single string.

type Blog
    = Blog String

Now let's take a look at our first requirement: showing a save button if the there are any unsaved changes.

Detecting changes

We need to distinguish between a post that was saved and a post that contains unsaved changes. One approach would be to define a type with a constructor for either scenario:

type MaybeSaved doc
    = Saved doc
    | HasUnsavedChanges doc doc

The HasUnsavedChanges takes two constructors so we can store both the last saved post and the current version of a post. There's a problem with this type though: it allows an impossible state:

blog : MaybeSaved Blog
blog =
    HasUnsavedChanges
        (Blog "# Bears")
        (Blog "# Bears")

Does blog contain changes or not? The HasUnsavedChanges constructor suggests it does, but the last changed and current version of the post are identical. We can write logic to automatically turn a HasUnsavedChanges doc doc into a Saved doc if it is detected both docs are the same, but it would be nicer if type didn't allow the invalid state in the first place.

Luckily we can make an easy fix to our type to remove this impossible state:

type MaybeSaved doc
    = MaybeSaved doc doc


{-| Get the doc containing the latest changes.
-}
currentValue : MaybeSaved doc -> doc
currentValue (MaybeSaved _ current) =
    current


{-| Check if there are any unsaved changes.
-}
hasUnsavedChanges : MaybeSaved doc -> Bool
hasUnsavedChanges (MaybeSaved old new) =
    old /= new


{-| Update the current value but do not touch the saved value.
-}
change : (doc -> doc) -> MaybeSaved doc -> MaybeSaved doc
change changeFn (MaybeSaved lastSaved current) =
    MaybeSaved lastSaved (changeFn current)


{-| Call this after saving a doc to set the saved value.
-}
setSaved : doc -> MaybeSaved doc -> MaybeSaved doc
setSaved savedDoc (MaybeSaved _ current) =
    MaybeSaved savedDoc current

In this type we always store two versions of the post and use a function compare the two. If there's differences we know there are unsaved changes and we need to show our 'Save' button.

This approach is the basis for the NoRedInk/elm-saved library.

Cool, one requirement down, four to go! Let's take a stab at implementing the save request.

Hitting 'Save'

When we save our post we will send out an HTTP request. We can use a separate property on our model to track this request:

type SaveRequest
      -- There's currently no save request underway
    = NotSaving
      -- A save request has been sent and we're waiting for the response
    | Saving
      -- A save request failed
    | SavingFailed Http.Error

Do you notice how there's no place to store a blog in this type? There doesn't need to be because storing the blog is the responsibility of our MaybeSaved a type. Of our SaveRequest type we only ask that it tracks the status of a request, not its result.

If you worked with the krisajenkins/remotedata library before our SaveRequest type might look familiar to you: It's like RemoteData e a without a Success variant. We don't really need that Success variant to meet our requirements, but your situation may be different.

Putting it all together

With our two types in place, lets construct our Model, Msg, and update function.

module BlogApp exposing (..)

import Blog exposing (Blog)
import Http
import Json.Decode
import MaybeSaved exposing (MaybeSaved)


type alias Model =
    { blog : MaybeSaved Blog
    , saveRequest : SaveRequest
    }


type Msg
    = MakeChange Blog
    | Save
    | ReceivedSaveResponse Blog (Result Http.Error ())


update : Msg -> Model -> ( Model, Cmd Msg )
update msg model =
    case msg of
        -- The user changes their post, for example by typing some words.
        MakeChange newBlog ->
            ( { model | blog = MaybeSaved.change (\_ -> newBlog) model.blog }
            , Cmd.none
            )

        -- The user presses 'save'.
        Save ->
            let
                blogToSave =
                    MaybeSaved.currentValue model.blog
            in
            ( { model | saveRequest = Saving }
            , Http.post "/my-blog"
                (Http.jsonBody (Blog.encode blogToSave))
                (Json.Decode.succeed ())
                |> Http.send (SaveResponse blogToSave)
            )

        -- We successfully saved the blog post!
        ReceivedSaveResponse savedBlog (Ok ()) ->
            ( { model
                | saveRequest = NotSaving
                , blog = MaybeSaved.setSaved savedBlog model.blog
              }
            , Cmd.none
            )

        -- We tried to save the blog post, but it failed :-(.
        ReceivedSaveResponse _ (Err e) ->
            ( { model | saveRequest = SavingFailed e }
            , Cmd.none
            )

Are we done?

To wrap up, let's make another pass through our requirements to see how we did.

If any unsaved changes exist, a 'Save' button will appear.

We can use MaybeSaved.hasUnsavedChanges in our view function to check for changes, and render a button if one exists.

Clicking the 'Save' button will send an HTTP request with the current contents of the post.

Check! The button can send a Save message. We wrote logic in our update function to send the request.

The 'Save' button should be replaced with a spinner while the request is underway.

The view logic can case on the saveRequest property. If it has the value Saving a request is underway.

If the request fails an alert should be displayed.

The view logic can case on the saveRequest property and check for an error. Maybe you'll want to add some logic to make the error disappear after a certain time, or when dismissed by the user.

The user can continue editing the post while it is being saved.

Yep! The save functionality does not get in the way of continued editing. If the user makes changes while a save request is pending, those will be marked as 'unsaved changes' after the save succeeds.

Nice, full marks! That's all!

Let me know what you think of this approach, and other solutions to the problem you know. I'd love to hear about them!