The JavaScript Ecosystem

[00:00:00]
>> Richard Feldman: Remember from our previous section, we talked about some of these function guarantees. All right, so same arguments, same return value, no side effects. In other words, all Elm functions are pure. This is not quite true in JavaScript. It's not quite the case that all JavaScript functions are pure.

[00:00:16]
In fact, there's really no guarantees around what are pure functions in JavaScript. Then which is why in a lot of JavaScript libraries, you have things that say like in react like hey, your render function should be pure. Please make sure you don't side effects in your render functions or your Redux producers.

[00:00:32]
Please make sure they are pure, it's really important that it's purr. Because otherwise, bad things are gonna happen. In Elm, you don't have to worry about that, because all Elm functions are guaranteed to be pure. However, this is a section about talking to JavaScript which means that we have to deal with the fact that while Elm functions are pure and we want to we able to rely on that and put it out of our minds and not have to think about these things, not have to have these worries, we also want to interoperate with a language where those guarantees are not in effect.

[00:00:57]
So how can we do that? All right, how can we deal with a world where we have stuff like math.random or setting stuff in local storage directly? In other words, how can we access the enormous JavaScript ecosystem? The largest in the world with all these millions, it's not millions, but it's a large, large number of packages while maintaining all the guarantees that let us code in Elm without worrying about all those things.

[00:01:22]
So the answer is that the way that Elm talks to JavaScript is essentially using the metaphor of client/server communication. It's message passing. It's sending immutable data from Elm to JavaScript and the receiving immutable data from JavaScript to Elm. And fortunately, as we just saw in the previous section, we can do that in Elm without losing any of our guarantees.

[00:01:44]
We just did in the last exercise, HTTP which is sending data from Elm to a server written in a completely different language. We have no idea what language it is. It could be JavaScript. It could be PHP. It could be Python, Pearl, Ruby Assembly, anything. We have no idea what the guarantees, but we don't care.

[00:02:02]
Because all we're doing is sending immunity data into it like an HTTP post or a get and there were receiving immutable data back from it, which we then decoded into our application. And at no point, do we ever have to worry about sacrificing any of these guarantees, any function period, anything like that?

[00:02:17]
Now we're not literally doing client/server communication to talk to JavaScript, because that would require going over the network to go out to the network and then come back to the browser which will be way too much overhead. But metaphorically, that's what we're doing here. The API is designed to have the same characteristics as client/server communication, so that we can freely communicate to JavaScript without sacrificing any of these guarantees that we've had throughout the course of the entire workshop.

[00:02:41]
So basically, Elm sends data to JS and then JS can send data to Elm and that's how they communicate. There's no direct function calls at any point in this. So you cannot in the middle of an Elm function say, hey, call math.random. I can't do it. Instead, we're gonna use commands and subscriptions exclusively to communicate with JavaScript.

[00:03:03]
So there sort of like two ways that this goes. So when you send a command from the Elm side, that's going to result in a callback being fired on the JavaScript side. So here's our command that we're sending. It's not quite going to be a command with a capital M like what we had before.

[00:03:19]
It's going to actually result in a command with a lower case M. So we're gonna go on a brief tangent and explain what that means when you have a command with a type variable that is unbound which is to say a command where the type variable has a lower case m, but there's no message anywhere else in this function.

[00:03:37]
Up to this point, every time we've seen a type variable, there have been two of them. All right, we had list out reverse had list elem to list elem. This is just command message, lower case m, but there is no other message anywhere. It's like not corresponding to anything.

[00:03:51]
What does that actually mean? Okay, so at this point, all of our type variables have come in pairs, but list.length is one that we sort of intuitively know how it works. But it doesn't come in a pair, right? List.length says, you can give me a list of anything and I can tell you what the result is, it's an Int.

[00:04:12]
No matter what type of list you give me. You can give me a list of strings, a list of integers, a list of floats, anything and I'll tell you what the length is. So kind of intuitively we can figure out, well, all right, that makes sense. I guess it's saying, it's a type variable, because what it means is.

[00:04:26]
This is flexible. We can give it any list we want and it will be able to give us back an ent.