Hardcore Functional Programming in JavaScript Demo Part 3

Transcript from the "Demo Part 3" Lesson

[00:00:00]
>> [MUSIC]

[00:00:04]
>> Brian Lonsdorf: Okay, we're almost ready for the magic, now we're gonna want some kind of, let's see, it would be a future in there, because I was thinking of me and IO to make the call, but other, it had to be an IO of either, or maybe, which is kind of a pain, and that's a future supposed to wrap up I think.

[00:00:22] Okay, we'll call this one search. Search takes a URL and gives back, I don't know if I call them videos or something. But they're not really. They're just the meditative for it. What should we call it? Here's a little, actually, that we can like check out what this kind of looks like to get a feel for like what is going on.

[00:00:45] What is our code need to do?
>> Speaker 2: You're gonna log the URLs? I just want to point out, there's a question on why is this better, right? And it's because you can compose things, really? I mean, that's the bottom line. If you see the power of composition, of composing behaviors, composing functions, composing these things into bigger things.

[00:01:09] And you get laws and properties, and you're totally working against an interface, so they're swappable, substitutable, everything turns out to be monad. So, if I make my own library that's been strings, I can implement this interface, and you can swap [INAUDIBLE] for it, and your app doesn't change.

[00:01:25] There's a ton of benefit.
>> Brian Lonsdorf: What's also [INAUDIBLE]. I mean, we have, we're going to see, at the end of our app here, we happen to kick stuff off, we do the stuff, rather than actually making the program happen. We could have sent back the pure stuff, and then whoever's consuming our app could be, I like your YouTube thing, but I'm a YouTube thing that I don't like filters out, bad results, or some, whatever, I don't know, it's getting on top of our app that's composing with it, rather than running it.

[00:01:54] At each stage, you're either something pure that someone can mess with, or you can be run. Maybe that's an oversimplification, but that's my intuition of it.
>> Speaker 2: Yeah, being able to just keep building upon smaller things and keep expanding it.
>> Brian Lonsdorf: Okay, search goes from URL to IO, so what does this look like?

[00:02:14] Whatever each of these are called, there's a feed that has, that's a weird API.
>> Speaker 2: An interesting settings, sorry.
>> Brian Lonsdorf: Go ahead.
>> Speaker 2: Everything in the pure part has the benefits of the pure stuff you're talking about, portability we use. They're always on memorization and all that stuff.

[00:02:36]
>> Brian Lonsdorf: Okay, so entry. Does entry live inside of anything? It lives inside the feed. Okay, cool, cool. You know what I could do? I could do say search and review all the results, just so we can do the API call. In fact, it all should be a future of results.

[00:02:55] The future JSON, we say that. Okay.
>> Brian Lonsdorf: I may not need to do the function.
>> Speaker 2: So, what are we gonna do? We're going call-
>> Brian Lonsdorf: HTTP GET.
>> Speaker 2: HTTP GET JSON. Yeah.
>> Brian Lonsdorf: Do we have that? Yeah, we put it http, or did we? No, we didn't.

[00:03:16]
>> Speaker 2: No, we didn't. [INAUDIBLE] HTTP call.
>> Brian Lonsdorf: The reason I can grab these things.
>> Speaker 2: [INAUDIBLE], No you don't, sorry.
>> Brian Lonsdorf: Yeah, that's all weird style.
>> Speaker 3: Hey, Brian, Raymond W is wondering, search shouldn't really be considered memorizable, should it?
>> Speaker 2: It's all pure, if it gets a different input the next time, if search is a different element the next time, it's all just going to be for this input, I'll give you that output.

[00:03:46] So- Since you're going to an external URL to get your output, that body can change, right?
>> Speaker 3: But we're not though. We're just getting a future of a possible thing that will happen.
>> Brian Lonsdorf: Right. When you call here in the call search, it doesn't do anything, it's just is here's the thing.

[00:04:04] It's the thing I always give you, and when you call that thing, you get different results.
>> Speaker 2: Yeah.
>> Brian Lonsdorf: But this function always gives you the same little thing that it's, here's some of the fuse when you light it. It's all yours, it's always the same, though.
>> Speaker 2: [LAUGH] Exactly.

[00:04:19] But yeah, you'll just get a future of this particular API.
>> Brian Lonsdorf: Yeah.
>> Speaker 2: And so, as you type different things in there, that pure stream, the input pure part returns a new function, cuz this new input will return a new future of a different URL.
>> Brian Lonsdorf: All right.

[00:04:36] So, we have [INAUDIBLE] API, got it, that's right, it's kind of weird to do that, we have to compose.
>> Speaker 3: That's where you're saying there has some cache played stuff, where you sound the same thing twice? That cache is the result.
>> Speaker 2: Yeah.
>> Speaker 3: That's the return?
>> Speaker 2: Minimalization, yeah, it'll just, it can trade speed for memory and get played by taking the same search results that should get the same exact future and the same.

[00:05:04]
>> Brian Lonsdorf: This thing isn't much to memorize, it doesn't have to do very much, but if it was some kind of miracle function, something of a core science.
>> Speaker 2: Yeah. Yes, returning the same future every time [LAUGH] there's a huge game, yeah. You expect her.
>> Brian Lonsdorf: So, I actually changed it from the URL, because if all it took was the URL, it would be identical with HTTP go, so I had to first, it's going to take a term, it runs it through term URL, so cool.

[00:05:31] I wonder what happened if we just logged that, so we say.
>> Speaker 2: We'll have a future, but nothing will happen, we'll see a future there.
>> Brian Lonsdorf: We could do a search string. The search stream.
>> Speaker 3: When do we fork and log the results? I'm not on value log, now our value's going to get a future, right?

[00:05:49]
>> Speaker 2: I know we're going to change URL streams search.
>> Brian Lonsdorf: Or we could try to make a whole new name stream, and not to search with URLs.
>> Speaker 3: It looks like search takes a term URL.
>> Brian Lonsdorf: You're right.
>> Speaker 2: Wait, I think it should be a URL stream, right?

[00:06:06] Wait a minute, if we're already getting URLs, yeah. I already used, hang on.
>> Speaker 3: Shouldn't it be URL stream instead at the other?
>> Speaker 2: Yeah let's change term URL to URL stream.
>> Brian Lonsdorf: Yeah, this guy.
>> Speaker 2: [INAUDIBLE] Stream of URLs going in there.
>> Brian Lonsdorf: Let's call it search stream then.

[00:06:25] I didn't even know what this is for, okay.
>> Speaker 2: So yeah, now we have to map, should we get over that stream? That's right.
>> Brian Lonsdorf: Now we have to map, okay All right, because we are doing on this chaining line.
>> Speaker 2: No, no, I'm sorry, up in your search stream where you can pose HTTP.

[00:06:46] Should be good, that URL streams are strange, you have to map they should get over it.
>> Brian Lonsdorf: Right, right, right.
>> Speaker 2: And we should be logging futures right now, but we might as well just go one step further and just do fork log log.
>> Brian Lonsdorf: Let's see if it's not.

[00:07:06] Just a quick check. Yeah.
>> Speaker 3: What are we getting on this one?
>> Speaker 2: It's get, capital JSON, after get on HTTP for the JSON future.
>> Brian Lonsdorf: Hey.
>> Speaker 2: So that on value where we log it, we need to fork, or at least have to call on value.
>> Brian Lonsdorf: There's-

[00:07:41]
>> Speaker 2: Cuz that'll subscribe to the event stream that comes out of the IO. And this is getting a little crazy. This is where you're, I have to deconstruct all these peer types to get the values out. And that's, in my opinion worth it, but it's definitely back to that discipline thing.

[00:07:58] For the all the peer stuff in your app, being so nice and easy to work with, and you have to worry about your call backs and everything poses, whatever. Down to the bottom you're, I have to get it out. [LAUGH]. And that's fine. It's one line because that's, it always ends up as one line.

[00:08:14] There's only going to be one thing. I don't think you beyond value returns anything. So you can't change fork it. Yeah.
>> Speaker 2: And fork takes a lot of one argument, because the other log is already. I shouldn't have done it that way
>> Brian Lonsdorf: But what's the failure?
>> Speaker 2: I just bake logged as a failure.

[00:08:38] It should have taken two and a future, but a big login is the failure.
>> Brian Lonsdorf: Where does this come from? Does it come from one of your point three-
>> Speaker 2: It's right there on 19.
>> Brian Lonsdorf: Not on fork-
>> Speaker 2: Yeah, I would change 19 to error success and future, and then just future, fork, error success.

[00:08:58] It's so much nicer.
>> Brian Lonsdorf: Wait, change it to what? Change it to success-
>> Speaker 2: E-R-R-S-U-C.
>> Brian Lonsdorf: Error first?
>> Speaker 2: Yeah.
>> Brian Lonsdorf: Cuz left and right, okay.
>> Speaker 2: Yeah, and then just insides. It's error, then success.
>> Brian Lonsdorf: Yeah, yeah, I always want to do it the other way, okay.

[00:09:18] And you need a comma in between suck in the future. The future sucks.
>> Speaker 2: Yeah, it does, doesn't it?
>> Brian Lonsdorf: [LAUGH]
>> Speaker 2: Without a comma, it does, okay.
>> Brian Lonsdorf: So now log log at the bottom. Sweet. See some URLs, or some results.
>> Speaker 3: People are asking if it's, if there's an easier way to test along the way.

[00:09:42]
>> Brian Lonsdorf: There is. It's called a strong type system.
>> Speaker 2: [LAUGH] I mean, I gotta tell you, so there's the results of the YouTube call, which is really cool. But typically, your app above is all returning pure stuff. So, makes it dead simple. Everything takes an input and returns an output.

[00:10:01] Have you ever had a test like a peer function, you're like whatever, this is so much easier than mocking a thousand things. So, if you decide to test out of pure stuff Boyer going on. It's going to be so much easier than setting up objects all to be in the right state now or in your test.

[00:10:18] That bottom thing is your kick offline that actually opens up values and that stuff, but.
>> Brian Lonsdorf: All right, this is crazy, but each of these could be tested individually easily and reproducible.
>> Speaker 2: Exactly, if you're saying the search streams to, all these things were pushed out, so you get the stuff out of the times.

[00:10:36] [LAUGH] So, we're good.
>> Brian Lonsdorf: Cool, so we're getting all the stuff there.