Proposal: Mailbox Revamp

[mgold]

This proposal attempts to codify the ideas from this thread. This would be a breaking change to core, but no change to the language itself.

Motivation

As is clear from reading the thread, "mailbox" is has failed as a metaphor. This part of the language is, empirically, one of the hardest for newcomers to understand. A few other issues with the API:

• The Address type is completely opaque, and hard to gain intuition about. However, it's really the only thing tying the API together.
• That is, there's message to create a Message, and send to create a Task, but neither of these seem to fit very well.
• forwardTo : Address b -> (a -> b) -> Address a is really confusing. It took me several tries to get my head around it. The average JS or Ruby dev is not comfortable with the phrase "contravariant functor".

Proposed Change

I'm not 100% on the names yet; please focus on the types.

type alias Dispatcher a = 
    { dispatch : a -> Message -- the big change
    , signal : Signal a 
    }

dispatcher : a -> Dispatcher a -- just renamed mailbox
send : Message -> Task x ()

Let's start by what's not in the API. There's no explicit message function aside from dispatch itself. This encourages people to use messages, which are safer (they can't perform arbitrary actions e.g. Http). And forwardTo drops out entirely, replaced by dirt standard function composition.

Finally, send takes a Message. Currently, send and message are both Address a -> a -> ..., implying parity. Now, it's clearly extra work to use a task. This implies (correctly) that a message is the primary type at play here. The exposed function plays very well with Graphics.Input, every function in which takes either a Message or an (a -> Message).

Next Steps

This proposal had support from both newcomers and regulars on the thread, though you're welcome to oppose here. As mentioned above, I think the biggest remaining hurdle is to find the right names. I think implementation will be fairly straightforward, although it's important to get the docs right.

[rtfeldman]

Yeah this just looks flat-out incredible. I really hope I'm not missing something, because I've read this a couple times and just love it. 😻

[evancz]

I believe this is a more unwrapped version of the definition of Address. I initially decided to wrap it up because you need to pass it around everywhere. My feeling was that it'd feel nicer to hold a thing instead of a function.

So as always, you gotta show code examples!!!!!!!! So here is the basic change to the Elm Architecture pattern:

-- current way
view : Address Action -> Model -> Html

-- proposed way
view : (Action -> Message) -> Model -> Html

Is that simpler? Maybe experienced users would want to wrap things up as an Address to make the types look nicer? I have lost perspective here.

With the effect routing stuff, you get this:

update : (Action -> Message) -> Action -> Model -> (Model, Effects)

I'll play with this idea as I continue exploring with the-social-network. Anyway, seems like it has potential, nice proposal!

[rtfeldman]

Some Dreamwriter code cleaned up and rewritten in this style: (before), (after)

(Action -> Message) is 5 characters longer than Address Action, but I really appreciate the simplicity and clarity of "I know what an Action is because I defined it, I know what a Message is, because that's an extremely familiar term, and I know what a function is because I use those all the time." I also love the way onClick dispatch (SetFullscreenMode targetMode) reads.

Even as an advanced user who knows what Address is, the (Action -> Message) signature feels comforting to me and worth the extra 5 characters. I expect I would keep writing it that way even if there were an alias available!

[mgold]

Thanks guys.

Maybe it's a matter of style, but I typically don't parametrize my update or view over the address/dispatcher. I'd just have the dispatch or the mailbox at the top level. More like:

update : Action -> Model -> Model
view : Model -> Html -- or Element
reaction : {- Action -> -} Model -> Effects

If you choose to parameterize, that's not a big problem. The type signature for view becomes slightly more complex, but also more explicit. It's just a higher order function, hardly unprecedented. [EDIT: Richard makes a case for this in the preceding comment.]

But let's look at the call site. In my Socket.io chat app, written before this proposal, I unwrapp the address immediately:

stateMB : Signal.Mailbox (State -> State)
stateMB = Signal.mailbox identity
sendState : (State -> State) -> Signal.Message
sendState = Signal.message stateMB.address

Notice that sendState has the same type of dispatch that this proposal would give me out of the box. Another use:

submitMB = Signal.mailbox ()
submitButton = Graphics.Input.button (Signal.message submitMB.address ()) "Submit"

With the proposal in place, the parenthesized expression becomes submitMB.dispatch ().

Let's look at a standard text field:

--reminder:
Field.field : Style -> (Content -> Message) -> String -> Content -> Element

type alias State = {content : Field.Content, submit : String}
field : Signal Element
field =
    let base = Field.field Field.defaultStyle
                   (\fc -> Signal.message stateMB.address (State fc "")) ""
    in Signal.map (.content>>base) stateMB.signal

The second argument to Field.field becomes

(\fc -> stateMB.dispatch (State fc ""))

If State only took one argument:

(stateMB.dispatch>>State)

For checkboxes, one might have

type alias ParamID = Int
type Action = Checked ParamID Bool | NoOp | ...
actions = mailbox NoOp
-- later
myCheckbox2 = Input.checkbox (actions.dispatch>>(Checked 2))

That is, by carefully choosing the order of arguments to tags, and by treating tags as curried functions, you can make it really pretty. (And I don't think that's a particularly advanced language feature; it's similar to record constructors.)

[Apanatshka]

👍 LGTM

[mgold]

One more code example, this time from the SocketIO library itself:

connected : Address Bool -> Socket -> Task x ()
connected : (Bool -> Message) -> Socket -> Task x ()

I think it's clearer from the second signature that the function will obtain a boolean using the socket, and then send it as part of the task.

[TheSeamau5]

I don't really have a strong opinion on this one because I got really used to the ideas of addresses and I like the concision in the type annotation it offers. When it comes to container components (whose type annotations can get super hairy at times), the change would look as follows:

view : (ChildContext -> (childAction -> Message) -> childState -> Html) 
     -> Context -> (Action childAction -> Message) -> State childState -> Html

as opposed to

view : (ChildContext -> Address childAction -> childState -> Html) 
     -> Context -> Address (Action childAction) -> State childState -> Html

The really weird part about this is that, in the proposed version, view takes a function which itself takes a function. This could very easily get weird from an API design perspective. (by the way, I have way uglier type signatures for container components if you're interested).

[mgold]

You could always add you own type alias. Better still might be to rework things. I would partially apply view's first argument, rearranging its arguments if necessary, and use function composition so it already has the dispatcher in its closure. So you might have

render : ChildContext -> (childAction -> Message) -> childState -> Html
view : (childState -> Html) -> Context -> State childState -> Html

Where render is a general purpose template, view is part of the component framework, and you're expected to apply render down to the first argument of view.

[TheSeamau5]

Ok, fair enough. But then how do you deal with actions that are not necessarily destined to the children?

Consider the following example

type alias State childState = 
  { children : List childState 
  , ... -- some bells and whistles here 
  }

type Action childAction
  = ChildAction Int childAction 
  | Resize (Int, Int)
  | ... -- other container specific actions


update : (childAction -> childState -> childState) 
      -> Action childAction -> State childState -> State childState 


view : (ChildContext -> Address childAction -> childState -> Html) 
    -> Context -> Address (Action childAction) -> State childState -> Html

What I'm trying understand is how do you get both the children and the parent to send events (of type Action childAction) which is normally done via Signal.forwardTo. As in, could you please provide some example code to see how it would look like. You can use my grid component from my tutorial if you want. (it only reroutes actions to its children but you can imagine adding a dummy action like NoOp that is sent via onClick just for the sake of discussion)

[mgold]

Whenever you used to do

newAddress = Signal.forwardTo f mailbox.address

you can now do

newDispatch = f>>mailbox.dispatch

For example - the Int in ChildAction is an identifier, right? -

makeChild : childState -> (childAction -> Message) -> Child

actions : Signal.Mailbox (Action childAction)
actions = Signal.mailbox NoOp

myChild = makeChild someState ((ChildAction 4)>>actions.dispatch)

This means that the children don't track their own identifiers; they are instead placed into the closure of the child's dispatch function by the parent.

[texastoland]

Thanks for this! So much more clarity than the original thread. Part of this conversation would be great feedback on Evan's new component architecture with effects. I'm especially curious about @mgold's dispatcher-less function signatures. I'm planning to fork and and experiment with doing that in update. Love to see you and @TheSeamau5 weigh in!

[mgold]

Go for it! Implementation shouldn't be too hard, we're basically exposing an opaque type.

[texastoland]

Do you have examples of your dispatcher-less signatures somewhere? Does it okay nice with nested components?