You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My original goal was to get a custom 404 page to work. I have found a partial solution for now (edit the netlify build command to copy a static public/404.html to dist after elm-pages build), but I have found a bunch of unexpected behaviors related to 404 handling, which I wanted to document here.
Depending on "how" a 404 error is produced, different things will happen in elm-pages v3.
If a request is made to the dev server, a 404 error with this message shown (from Pages.Internal.NotFoundReason): "No route found for /asdf Did you mean to go to one of these routes:"
In production, this always changes to "No route found for /____elm-pages-internal____/404 Did you mean to go to one of these routes:" in the generated 404.html file.
Using Netlify redirect rules for example, you can load an elm-pages app with a url unknown to elm-pages. In that case, you will get the following error, originating from the generated Main.elm: "This page could not be found."
Next, I tried to use a top-level SPLAT_.elm. This fails with a compiler error in the generated Route.elm: "The nth pattern is reduntant: Any value with this shape will be handled by a previous pattern, so it should be removed." (see Issue with only catch-all routing #397)
a public/404.html file will be overridden by elm-pages build.
Additionally, we now have an ErrorPage.elm module in v3, which would be another way of rendering a 404! Unfortunately, using a server-rendered page that just 404s for everything also does not work because of the SPLAT error.
What I think should happen
Since we now have this ErrorPage.elm module, I think it should be used not only for server-rendered pages, but for all errors in general. Errors in pre-rendered pages are caught at build-time. 404s can always happen though!
The ErrorPage module is already required to expose a notFound constructor. In all cases where there is currently a error built-in from elm-pages shown, it should instead use this constructor and switch to the error page.
In the generated 404.html page, this module should also be used.
The text was updated successfully, but these errors were encountered:
Hi!
My original goal was to get a custom 404 page to work. I have found a partial solution for now (edit the netlify build command to copy a static
public/404.html
todist
afterelm-pages build
), but I have found a bunch of unexpected behaviors related to 404 handling, which I wanted to document here.Depending on "how" a 404 error is produced, different things will happen in elm-pages v3.
Pages.Internal.NotFoundReason
): "No route found for/asdf
Did you mean to go to one of these routes:"/____elm-pages-internal____/404
Did you mean to go to one of these routes:" in the generated404.html
file.Main.elm
: "This page could not be found."SPLAT_.elm
. This fails with a compiler error in the generatedRoute.elm
: "The nth pattern is reduntant: Any value with this shape will be handled by a previous pattern, so it should be removed." (see Issue with only catch-all routing #397)public/404.html
file will be overridden byelm-pages build
.Additionally, we now have an
ErrorPage.elm
module in v3, which would be another way of rendering a 404! Unfortunately, using a server-rendered page that just 404s for everything also does not work because of the SPLAT error.What I think should happen
Since we now have this
ErrorPage.elm
module, I think it should be used not only for server-rendered pages, but for all errors in general. Errors in pre-rendered pages are caught at build-time. 404s can always happen though!The
ErrorPage
module is already required to expose anotFound
constructor. In all cases where there is currently a error built-in from elm-pages shown, it should instead use this constructor and switch to the error page.In the generated
404.html
page, this module should also be used.The text was updated successfully, but these errors were encountered: