Introduction to Elm, v2

Talking to Servers Exercise

Richard Feldman

Richard Feldman

Vendr, Inc.
Introduction to Elm, v2

Check out a free preview of the full Introduction to Elm, v2 course

The "Talking to Servers Exercise" Lesson is part of the full, Introduction to Elm, v2 course featured in this preview video. Here's what you'd learn in this lesson:

Students fix a problem where the Sign Up page is not sending a HTTP request when the user submits the form. Debug.todo is also introduced as a useful tool.


Transcript from the "Talking to Servers Exercise" Lesson

>> Richard Feldman: That brings us to the exercise for part 8. So same build command as before. In this case, we have a login not working. So we need to make login work. Currently it doesn't actually send an HTTP request to the server. Sorry, not login, sign up. So we're gonna go do page, register and resolve the to dos in here, okay.

So here we can see a number of ingredients that we just talked about in the slides. So one is requests body, sorry, that's actually new one. We can see response decoder which is a Decoder Viewer. Viewer is the term for the currently logged in user in this application.

So, things like the current user. This could have also been CurrentUser, but the name I chose to go with was Viewer. So, this is a decoder, the Http.Body is something that Http.Post requires. We don't need to learn about how that's put together. It's essentially the same thing as GET except that it requires that HTTP body, which we've already put together in this example.

So our job here is to create an HTTP request value that represents a POST to API/users. Here's the documentation for HTTP POST, at this point we've learned enough about Elm that we can just go read this documentation and actually learn how this function works. What we need to pass it, and how to get it working without actually having been taught it explicitly.

This is going to become an increasingly important skill to use as you're working through Elm, because quite often the solution to the problem is to visit the package website for whatever it is you're working with. And learn how these things work by just reading the documentation about them.

And the types are quite often the most important thing in that because they tell you essentially, what is going to be necessary to pass this thing to get it to work properly. Quite often in Elm, if you successfully get the types to work out, in other words you get the compilers satisfied, it just works the first time you try it, and I think that's likely to be the case here.

>> Richard Feldman: Okay, there's also thing here that we have not seen before called Debug.todo. So what does that thing do? So Debug.todo is a function that has a very unusual type, in fact, it's the only place in Elm with this type appears in any of the standard libraries. And basically Debug.todo will type check with anything, and if you ever execute this, it will crash.

So you might be wondering, how can we have a function an Elm that crashes when Elm's whole thing is no run time exceptions. What's the deal with that? And the name gives you a clue, this is intended for debugging and it's sort of like a todo. When you get to a point where you're like, I want to come back to this later.

Just work compile for now, I will fix this later, don't worry about it, and I'll circle back to it later. Important feature of this is that when you're building for production mode and you give Elm-make the --optimize flag, which is to say actually compact your assets and give me those small assets that I wanna deploy in production.

It will refuse to compile if you left any of these in your code. That's why I say no production run time exceptions. Also, that feature didn't always exist in Elm back in the day, it was the case that you could leave these in and the compiler would not yell at you when you were building for production.

That's the source of the only run time exceptions we ever got. We left some of these in our code and accidentally hit them in production. But portionally now if I try to build with optimized, while I still have this todo in there, it's not going to work. So as an example of that, if I compile these, that will work just fine and we can be unblocked and continue working on this.

Since I add --optimize, oops, did I not spell that right? I put it on after a new line. [LAUGH] Okay, DEBUG REMNANTS, they're used as a debug module in the following modules. The optimize flag only works if all of them are removed. So this is something that is safe to use for development when we want to sort of say, yo know what?

I want to circle back to this later. I don't want to resolve these compiler errors yet, but it's not something that's gonna bite you in production as long as using the optimized flag in production. Which of course is always what you wanna be using anyway, because who wouldn't want smaller assets.

All right, so that's our request and then finally, we have this command. So the command is what's going to actually get returned from update in addition to our model. And to build this command using the request, the ingredients that we're going to use are this thing. As well as, we're going to need to specify the message variant that's going to handle those two possibilities of either it succeeded or it failed.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now