> These functions almost inevitably end up needing something from the top-level application-wide state, so you’ll often see some type signature like this:

    > updatePersonalInformation
    >    : Model
    >   -> (PersonalInformationModel, Cmd PersonalInformationMsg)
    >   -> (Model, Cmd Msg)

> This is way too complex already, and this approach doesn’t even actually buy you anything.

Is this accurate? I feel like this may not be what the author intended to write, since the update function isn't given any kind of message.

The author's approach has data for every page of your app stored in the model at once, and available to every other page. Also, any page can edit the data for any other page and send messages to any other page. That makes me nervous.

We went with having a small amount of global state that was visible to every page, and that every page could update (returning (Model, GlobalState, Cmd Msg)). That seems... basically fine? It's still a bunch of boilerplate, but not that much, and I don't think we've had significant problems with it. We need Cmd.map and Html.map but I don't know why the author thinks this is bad.

(The boilerplate is mostly turning `(model, cmd)` into `(model, globalState, cmd)`. On the other hand, we don't need to wrap each of our messages with `ThisPageMsg`. Most pages don't need global state, and we let them use a regular Msg -> Model -> (Model, Cmd Msg) update function.)

(Oh, I think very occasionally we do need to send a message up to the top-level as well. I don't remember exactly how we do that. It might be something like... those pages' update functions take a `PageMsg` and return a type `PageMsg PageMsg | GlobalMsg GlobalMsg`, and the top-level update function interprets `ThisPageMsg (GlobalMsg ...)` and passes through `ThisPageMsg (PageMsg ...)`. Again, boilerplate, but not significantly problematic, and only on pages that need it.)