Check out a free preview of the full Advanced Elm course

The "Pages" Lesson is part of the full, Advanced Elm course featured in this preview video. Here's what you'd learn in this lesson:

Despite the name, Single-Page Apps have multiple logical "Pages" in them. Richard demonstrates how to model these in Elm. - Maybe 0:00-1:40 ? Cliffhanger??


Transcript from the "Pages" Lesson

>> Richard Feldman: So that's the notion of a route, and then separately we have a notion of a page. So when I say page, I actually mean two different things, and both of them have to do with the page module. So inside the page module, we do have a completely exposed, which is to say non-opaque, custom type.

And it looks like a little bit of a shortened version of the route. Notice that these things right here don't necessarily have to do with URLs. They have to do with displays. In other words, this is something that we're going to display to the end user. What this type is used for is, oops, is determining which if any of these menu bar items to highlight.

So notice, I can tell I'm on the Settings page in part because this thing right here under Settings is highlighted. That's because the current page is set to Settings right here. If I had said move to Home, it's going to be this, which is how the nav bar knows that Home should be highlighted.

Now the reason we need this in separate module, is that each of these pages separately calls the view function that renders this header bar up here. So we need some shared notion of what the other pages are, so that each page doesn't have to go around importing all the other pages to figure out wait, are we on this page, or we are on that page, or we are etc.?

Instead, we just have this one single source of truth for the different ones that actually represent potential highlighted things, followed by other in case you're on a page which doesn't have any particular special highlighting. So that's Page the custom type, but that's not all that's in this module.

There's also view, and viewErrors. Let's take a look at those. So viewErrors is actually the simpler of the two. Its job is to essentially just to display a error message. And this is something that is used on pretty much all the pages, because errors of all shapes and sizes can happen, usually HTTP errors.

But any number of errors could happen. And if that happens, we want to show something interesting to the user, not just plain, old unstyled text. So this is a helper that exists purely for the purpose of rendering some text and also having a message for how to dismiss that, in other words, to close the errors if you want to.

So all it does is it renders a div and maps over the errors and lists them all out. So we use this in a bunch of different places, okay, so that's one. The other one is view. Now view is more complicated, despite the fact that it is much shorter.

So what this is doing is it's actually translating between what the caller is going to give it, which is to say maybe Viewer. Actually, let me put these on multiple lines. So maybe Viewer, which is to say we may or may not be logged in. If we are logged in, we want to take that user, and that's going to be used by this viewHeader function that we're delegating to, to either render this right here or not.

Then we take the page, which is to say, one of these things, and again, that's also going to be used by viewHeader. And then we take the title and the content of this thing. So title is going to go into document here, which is what tells the single page app what to render up here.

So we actually have potentially different titles. So when I switch to here, the title changes to New Article, when I'm on here it changes to Settings, etc., that's what's set in here. This is essentially, I'm using this as named arguments, not because I want to disambiguate between those two, cuz they're different types, so that's not really a concern.

But rather, because each of the pages I already know is going to return something that looks like this anyway. So I'd just rather accept that as an argument than ask them to sort of pull it out of the record that they've already got. Okay, and then the rest of the work is done by viewHeader itself, which renders all this stuff, and including the logic for showing which thing is highlighted, and which is not.

So essentially, Page's job is to do three things. One is to expose the notion of a page, which is what you're potentially on. And the other is to have common helpers that pretty much all pages are going to use. The reuseable errors as well as the Page.view, which renders sort of the frame around the page, the header, and the footer.

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