This is an alternative site for discovering Elm packages. You may be looking for the official Elm package site instead.
An experimental library for representing mutable values
version 3.3.0
license BSD3
native-modules False
elm-version 0.15.0 <= v < 0.16.0
Tag 3.3.0
Committed At 2015-05-12 01:20:02 UTC
elm-lang/core 2.0.1 <= v < 3.0.0 2.1.0


A Ref represents a "mutable" piece of data that might exist inside a larger data structure. It exposes the current value of that data and encapsulates the information needed to update it.

Refs can simplify building modular UI components that know how to update themselves. A typical module might look like this:

type alias Model =
    { foo: String,
    , widget: Widget.Model,
    , bloops: Array Bloop.Model

-- an model-updating function
multiplyFoo : Int -> Model -> Model
multiplyFoo n model = {model | foo <- String.repeat n}

-- create Focus objects that represent fields of our Model type.
widgetField = Ref.focus .widget (\x m -> {m | widget <- x})
bloopsField = Ref.focus .bloops (\x m -> {m | bloops <- x})

view : Ref Model -> Html
view model =
        -- create Refs to fields of our model record
        widget = widgetField model
        bloops = bloopsField model
        div [] [
            -- model.value is our Model

            -- on click, perform an update
            button [onClick (transform model) (multiplyFoo 2)] [text "double it"],

            -- pass a nested component's model "by reference" to its module's view function 
            Widget.view widget,

            -- map over an array, passing elements "by reference" to a view function
            span [] ( Bloop.view bloops)

            -- another update
            button [onClick (transform bloops) (Array.push (Bloop.init 55))] [text "new bloop"],

main : Signal Html
main = view ( initialModel)

Full examples

Ref-based versions of Counter, CounterPair, and CounterList in the style of the Elm Architecture tutorial are here.

Note on model-view separation

In this pattern, an Action type (as described in the Elm Architecture) is not part of a typical module's public API. However, it's still good practice to keep model-manipulating code separate from view logic, and you can still use an Action type to help with this. Just partially-apply your update function when constructing event handlers:

onClick (transform model) (update MyAction)