Http.get

[00:00:00]
>> Richard Feldman: Now, what we really want though is not so much this string because our feed is not a feed of string, it's a feed of articles. So what we actually want is we want something that will end up with satisfying this variant type. We want completed load feed to be, yeah we want to be a result, cuz loading the feed could fail.

[00:00:21]
It's gonna have an HTTP error as it's error type, that still the same. But instead of a string here, what we want is a list of articles. So if it's succeeds, we want it to immediately gives us back, here's our list of articles, so you can go and render them right away.

[00:00:34]
So Http.getString takes url, but on success only gives us raw string, which is not quite we want. Http.get is the more flexible version. It takes an extra argument which is a decoder, a JSON decoder. And we do that, success gives us back whatever that decoder's type parameter is.

[00:00:54]
So in this case we have articlesDecoder, which is a decoder of lists or articles. And so on success, that's exactly what we're gonna get back. A list of articles. Everything else about it is the same. One of the things that can happen in this error case, is we get what's known as a bad payload error, which is to say, Http.get gave it a decoder and decoding failed.

[00:01:17]
So that's one of the possible errors that we will have to handle when we're dealing with this. GetString never actually produces that error because that's always like, wow, the payload is the string, I think it's fine. Looks good. Worth noting by the way, that you can implement get in terms of GetString.

[00:01:33]
Because essentially GetString's purpose is to go get a string and then take that string and then run the given JSON decoder on it. And then translate that into one of these error types. So, even though this is a little bit more convenient to use, it really is just ultimately a convenience on top of GetString.