Helpful dev server 404 page feedback

[dillonkearns]

I'm thinking about some ways that the 404 not found page in the dev server could give feedback to make it more clear why the page isn't found to make it easier to debug why your route isn't working, or ease the learning curve for newcomers. If the page simply says "Page not found" without a reason why, that it leaves users wondering whether the dev server picked up their changes, or confused about what step to take to see the route they're looking at.

So this could be a great opportunity to give great feedback like Elm is known for!

Some scenarios

Here are some ideas about different scenarios and possible 404 page messages. Let's say we have these Page Modules:

• src/
  • Page/
    • Index.elm
    • About.elm
    • Blog.elm
    • Blog/
      • Slug_.elm
    • Project/
      • Name_.elm

Scenario 1 - No Matching Route

• Navigate to /author/jane

404 page message:

No route found for /author/jane. Did you mean to go to one of these routes:
/
/about
/blog
/blog/:slug

Or maybe you want to add a Page module for a new route? You can add one with a command like elm-pages add Author.Jane, or Author.Param1_

Scenario 2 - Matched Route, Zero Pages for Route

• Navigate to /blog/new-post - Matches Route Blog.Slug_, but routes = DataSource.succeed [] (empty) - Similar to elm-test "Let's add some!" message.

I found a Page module for this Route, but its routes is giving me an empty list. Try adjusting your routes DataSource in src/Pages/Blog/Slug_.elm!

Scenario 3 - Matched Route, At Least One Page for Route

• Navigate to /blog/post2 - Matches Route Blog.Slug_, but routes = DataSource.succeed [ { slug = "post1" } ]

I found a Page module for this Route, but its routes did not include { slug = "post2" }. Try adjusting your routes DataSource in src/Pages/Blog/Slug_.elm!

The routes I found are:

• { slug = "post1" }

Scenario 4 - Matched Pre-Render with Fallback Route, Not Handled

• Navigate to /project/some-project

I matched a Route, but handleRoute was False for the RouteParams argument { name = "some-project" }.

The following pages are pre-rendered for this route:

• { name = "elm-pages" }
• { name = "elm-markdown" }

Try updating src/Page/Project/Name_.elm to either include { name = "some-project" } in routes, or handle it in handleFallback.

Scenario 5 - Matched Server-Rendered Route, Not Handled

• Navigate to /project/some-project
  I matched a Route, but handleRoute was False for the RouteParams argument { name = "some-project" }.

Try changing src/Page/Project/Name_.elm to handle these RouteParams in handleRoute.

Feedback

I'd love to hear thoughts! It would be great to make elm-pages stand out for extremely helpful feedback all around.

[dillonkearns]

Making good progress!

With pre-rendered routes

With no pre-rendered routes

Here's a video demo:

https://p32.p1.n0.cdn.getcloudapp.com/items/Kou4Bdjz/6c105714-9e10-4c4e-9bbd-588b42ad8b75.gif?v=91db0c7a3e4682ece75e18d241ad0755

[GaryBozek]

I guess my question would be: Who is this page intended for?

This is a great page of information for software engineers - so it is very useful for a developer building up the site.

Putting on the "user" hat, the average web surfer will not know what a route is. A website visitor doesn't care about the routes, they are trying to get the information that they want from a web site (they click buttons and links and enter URLs). Even if a user was presented with that page of information, it still doesn't help the user (or a developer for that matter) figure out what a valid route is to enter in the URL as the next step....

What would be useful for a user is being provided a page with actual valid links that they can click on to continue with their surfing of the website. That provides real value to the end user's surfing experience.

Given how elm-pages can index all the valid pages, if there was a way for a developer to hook into NotFoundReason.elm and provide a customized Not Found page with valid link suggestions, that would provide an excellent surfing experience.

So I see two scenarios:

1. The developer doesn't extend the NotFoundReason.elm, in which case, when a bad route is found it displays a simple "Not Found" page and provides a link back to the home page.

2. The developer extends NotFoundReason.elm, and, using:

   1. the bad route that was entered,
   2. the NotFoundReason,
   3. the catalog of pages (custom built by the developer, or potentially generated by elm-pages),

   the developer can apply logic to build a custom Not Found page that suggests a few links to assist the user on their surfing journey.

[dillonkearns]

Hey! Thanks for sharing your thoughts.

This page is just for devs when running the dev server.

I'm still figuring out what the workflow might look like for defining a user-facing 404 page. Because elm-pages statically generates all the routes it needs, often the CDN service, like Netlify, will be the one presenting a 404 page. That does change if there are serverless catch all routes (that part is still a little bit in the alpha stages).

So there are two main paths to the user seeing a 404 page - the CDN routing to a specific pre-rendered page when a route isn't statically generated, or returning a 404 in the server-side rendered response. What I have in mind for both of these is some sort of customizable 404 page that the user can define. Then elm-pages would wire that in for production builds.

I like your idea of providing some useful context that the developer can use for their custom 404 page! I hadn't considered that, but I think that would be a really nice feature!

[GaryBozek]

Dillon,

The developer messages are great - they were very helpful when I was wiring up my pages to debug the Globbing construction.

A potential architecture:

1. NotFound.elm page - this would be a protected page (like Index.elm). When a bad route is detected/intercepted by NotFoundReason.elm, then NotFound.elm page is displayed.
2. The NotFound.elm page would allow the developer to toggle between displaying the developer messages [during development] or user messages [when preparing for deployment] (whether it is a hardcoded switch or Environment Secret, or ...?):

• developer messages - would display the messages that exist currently
• user messages - by default would display these options for the user:
  • go home ("/" route)
  • go back (the browser back function)
  • ????

3. At some point, the developer can extend the user messages functionality by overriding the default code. By this, I mean adding site styling, context sensitive suggestions (based on what NotFoundReason.elm is detecting/returning and the developer's knowledge of the existing valid routes), or whatever custom messaging is desired for the website.

If the NotFound.elm View msg is treated like other page's View msg by Shared.elm, then whatever site design already exists (NavBar, Footer, etc..) is preserved, which also provides the user with another way to get back on track.