Html Msg

[00:00:00]
>> Richard Feldman: We can also write a type alias for our message. So we could say, when we've got our view that's taking a model and then returning some HTML. Which includes an onClick that has one of these messages, we can use messages to refer to that. So if we have, for example, a slightly different UI that's got something like a button that you can press to clear everything.

[00:00:22]
So you can click it, it's going to say onClick, description = ClickedClear. Data = ALL, so it's like clear all button and then the text is just an X. If I were to click that, then it would send that message to model, now if I wanted to I could also say, you know what?

[00:00:38]
We don't need this data field here, I mean, there's only one sort of way that you can like clear this thing, which is to clear all of them. We don't actually need to have this redundant field, I'm just going to make my message type be a string. I'm not going to have it be a record at all, I'm just going to say onClick ClickedClear, that string.

[00:00:57]
That's totally allowed if you want, Elm does not enforce a particular format for your message type. It says you can choose whatever type you want for your message. What it doesn't force is that you have to be consistent. Whatever format you pick for your message, you have to use that throughout your program.

[00:01:15]
And the reason for that is that view and update have to communicate. Whatever message type that view is producing, that's the same message type that update has to consume. Because it's going to get past that by the runtimes, so those have to agree. Whatever format you choose has to be consistent between view and update.

[00:01:32]
Because of that, HTML is actually a parameterized type, and it's parameterized on the type of the message. So view is annotated as Model, and it takes a model as its argument, and then it returns Html String. Which basically means a virtual dom node, which produces string of messages.

[00:01:55]
And the reason that this produces string of messages is because that's what we've defined as our message type. By virtue of the fact that we put a string here and passed it to onClick.
>> Richard Feldman: And correspondingly, this one up here is view that takes the Model and returns Html Msg.

[00:02:12]
Where Msg is that type alias of the record that we've defined previously.
>> Richard Feldman: Now if we want, we could do a third type, we could say, like, this one is Html Msg, which has the record. This one's Html String, which has the string for onClick, right here in the middle, sure, we could have Html Float if we want.

[00:02:30]
That's totally allowed, again, you can pick whatever format you want, but you have to be consistent. So if this is what we're doing for view, that means our update function is going to take a float as its first argument. Here, update's going to take a string as its first argument.

[00:02:44]
And here, update's going to have to take a message as its first argument. And if those disagree, if the parameterized type. Or sorry, the type parameter on Html doesn't agree with the first argumentative update. The program won't compile, Elm will insist on those being consistent. Any questions about the relationship between the Html type parameter view and update?

[00:03:05]
>> Speaker 2: Then we're doing the update function and we were doing the middle case with the float. Then we pass in like float for that first argument?
>> Richard Feldman: Exactly.
>> Speaker 2: Or update?
>> Richard Feldman: Yeah.
>> Speaker 2: Okay.