Having trouble grokking Signal.forwardTo

[Wil C]

I'm been going through the elm architecture tutorials, and building my own stuff. However, I'm having some trouble wrapping my head around forwardTo, as much as I try. Usually, it's probably because of some misconception I have. What's a good way to think about forwardTo conceptually so that it makes sense?

Conceptually, I'm guessing I'm to think of forwardTo as taking the current passed in address and creating another address that can be used by the subcomponent. To do so, I pass in a second argument that's usually a type alias of the current component's Actions to result in a subcomponent's Actions.

An example is:

type Action
= Insert
  | Remove
  | Modify ID Counter.Action

viewCounter : Signal.Address Action -> (ID, Counter.Model) -> Html
viewCounter address (id, model) =
  Counter.view (Signal.forwardTo address (Modify id)) model

It looks like in order to get Counter.view called correctly with the right address, I'm using (Modify id) to change it to an address with Counter.Action in the address, so that when it's passed into Counter, the actions are of the correct type?

Is that right, or is there another way to think about it?

Wil

[Max Goldstein]

Hi Wil,

You're not alone. Signal.forwardTo is, in my opinion, the hardest function to understand in the entire standard library. I've written an essay on mailboxes that touches on how forwardTo works and why you'd want to use it.

Hi elm-discuss,

I don't like grandstanding, but I see this as further support for my proposal which exposes forwardTo as the function composition it really is. I am not advocating for a 0.16 release; I know Evan is trying to get it out the door. But sometime before 1.0, please, please we need to make this happen. It will dramatically simplify this confusing part of the language, as we've seen demonstrated by many such requests for help.

[Peter Damoc]

A good way to think about forwardTo is to view it as a type transformation assistant. 

Counter has an Action type, let's call it TypeA
CounterList has an Action type, let's call it TypeB

Now, in CounterList.update, if a TypeB action arrives, the function knows about TypeB, knows about TypeA, it knows what needs to be done. It knows how to take a TypeB Action and convert it to a TypeA action

In Counter.view however, the counter sends its TypeA actions to an address of TypeA. The entire module knows nothing about TypeB. 
A mechanism is need it to do the following two things:
1. give Counter.view a TypeA address

2. convert all the actions sent to that TypeA address into Type B actions that can be understood by CounterList.update. 

Signal.forwardTo does that. It takes a TypeB address and a way to turn TypeA into Type B and produces a Type A address that can receive TypeA actions. All the actions of that TypeA address go through the (TypeA-> TypeB) function and are sent to the TypeB address. 

In your concrete example (Modify id) is that (TypeA -> TypeB) function that takes an `Counter.Action` (before mentioned TypeA) and turns it into a `Modify ID Counter Action` (before mentioned TypeB) 

--
You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

There is NO FATE, we are the creators.
blog: http://damoc.ro/

[Wil C]

Hello all,

Thanks for the help (belated). Max, I've been able to go through the message and mailbox thing, and it makes a little more sense now. For now, forwardTo is still a little confusing, so I'm sticking to patterns I know that work for now.

And Peter, it sounds like forwardTo is a function generator, where it allows Type A addresses to be converted into Type B addresses to be passed up?

Wil

[Peter Damoc]

Yes, kinda like that. 

Another way to view the situation is like a dispatch mechanism. 

Kinda like tech support. You call a local number but instead of a local person answering you, a dispatch system routes your call to India and the tech support there answers your call. 
To you, all this is transparent. You don't care how things are handled as long as they are handled properly. You just call the local number and you have your issue fixed.