Add a 404 page

[BrandonLMorris]

Add a catch-all Angular route that will redirect to the 404 page.

I resisted adding a similar redirect to the API. The reason being that most of our interactions with the API are to get data, not actual pages. However, that does mean that unless the user attempts to go to an incorrect URL that starts with /#/, they won't see our fancy new page.

[DaveShuckerow]

not bad

[WilliamHester]

You mentioned that the 404 page only works if the user tries to go to a URL that starts with /#. There's actually a way we can fix that. This article talks about enabling "HTML5 mode," which drops that part of the URL.

[BrandonLMorris]

That would require fixing all the links in the rest of the client, right? I like the idea, though it's perhaps out of the scope of this PR.

Now that I think about it, you can set Flask to capture 404s, and I can set that to redirect to #/404. I can also set a catch-all /api/<path:path> for bad API requests that will just send back a 404 (to keep the API client-agnostic). I'll do that when I get a chance

[WilliamHester]

Yeah, I guess it's kind of out of scope for this pull.

I like your idea about the redirects. Can you do that for this pull?

[BrandonLMorris]

Sure deal. I'll try to get it in tonight-ish. I know Dave is excited to get this live

[BrandonLMorris]

Ok I was thinking about it again and changed my mind about having Flask redirect to /#/404 because I felt that it was too closely coupling the server code and the API code. So here's the balance I struck: I moved the 404.html to be a Flask template.

• If the user attempts a bad Angular route (i.e. /#/not-real): They'll see the pretty 404 page, just like normal (all via Angular).
• If the user visits a bad API route (i.e. /api/not-real): They see a text response with a 404 code.
• If the user visits anything else bad (i.e. /purple-munchkins): They see the Dave-ified 404 (rendered by Flask). The thing here is that it doesn't have the nav bar at the top because it's not inside the Angular app whatsoever.

Reasoning Like I mentioned, I really want to keep the server code away from the client code (point number 3). While this isn't perfect, I think it strikes a nice medium. The client handles its own bad routes with the full knowledge of Angular and the rest of the client app. The server side, agnostic to the client, does it's best to handle bad routes without depending on any implementation details of the client.

Probably the ideal solution would be to chop off the # prefix and let Angular handle all bad routes (though that may complicate things with our /api prefix), but this is what I came up with. Under this system, you could theoretically remove the client app entirely and replace it with something else, which is good, right?

tl;dr api design is hard.