sharing actions

main.elm

module ColorPicker where

import Model exposing (initialModel)
import Action exposing (update)
import View exposing (view)

type Action =
    InitialsSaved Bool
  | Noop
    
app =
  StartApp.start {
    init = (initialModel, Effects.none),
    view = view,
    update = update,
    inputs = [incomingGameObject]
  }

model.elm

module Model (Model)

-- Top/App Level model

type alias Model =
  { initialsSaved : Bool
  }
  
  
initialModel : Model
initialModel =
  { initialsSaved = False
  }

update.elm

-- I am not sure if Action(..) is correct. 
-- I know that to import possible values for a type this works but I tend to expose everything in my app
module Action (Action(..), type) where

-- Top/App Level update

-- I like to define my action type at the same place I have my update function
type Action =
    InitialsSaved Bool
  | Noop

-- Update: Something happened --> Update the model to contain the changes
update :: Action -> Model -> (Model, Effects Action)
update action model = 
  case action of 
    Noop ->
      -- Nothing happened. This action isn't necessary
      -- I need it mostly if I have a Task which's result I want to ignore
      (model, Effects.none)
    InitialsSaved initialsSaved ->
      -- Save into model
      ({model | initialsSaved = initialsSaved}, Effects.none)

view.elm

module View (view) where

import Action exposing (Action)
import Model exposing (Model)

-- Top/App Level view

-- View: give me a model and  *one* address where I can send actions/events to
-- Elm Architecture example 4 used an additional signal for removal because the update function
-- This signal was handled in was in a level "above" the view.
-- The single Counter shouldn't know about the CounterList

view :: Signal.Address Action -> Model -> Model
view address model =
  button
    -- Messages to this address wind up in the update function. There we do the case of match
    -- The reason I changed this from the Signal.forwardTo is because I assume that the 
    -- update.elm file that InitialsSaved is handled in is on the same level as this view.elm file
    -- It is okay for this view.elm file to know about the details of update.elm
    
    -- In the example 4 an additional Address is used because a single Counter shouldn't need to know where it is embedded. 
    -- It knows though that is (logically) has to be embedded somewhere. And to allow his parent to remove him 
    -- An additional address is needed. I think I want to explain this in an additional revision of this gist
    [onClick address (Action.InitialsSaved True)]
    [text "Play!"]