Closed amiller-gh closed 9 years ago
e.g. offline page? or 404?
Hey Ben, sorry, was away on vacation for the past couple weeks. This would be for a 404 error. The router tries to load the package by convention defined in the Rebound config (eg: domain.com/foobar tries to load from public/pages/foobar.js, or whatever root you define) if the request fails, it should try to load a custom 404 page from the backend from a configurable ERROR_ROUTE_NAME
variable (currently defined at the top of rebound-router).
This is almost completely implemented, except for one little hitch in the way routable components handle their routes. At the moment, a routes: {}
object is required as a property of any routable component. This defines the routes can be handled by the component being loaded. At the moment, if a component does not have the route that requested it defined, the router assumes that the component it loaded can't handle the new route and tries to load the error route, defaulting to a hard coded error page if a custom one isn't defined and can't be fetched from the server. Here are two example:
about
page is loaded via the route /about
. The router looks in the component's routes hash for a route that matches /about
. It is the only one declared on the about page component. The callback provided is called. If the browser roures to any other route (ex: /about/foobar
) the router realize that the current page component can't handle the path and will try to route to the ERROR_ROUTE_NAME
route, loading a custom 404 page. This tries to load a routable component from /ERROR_ROUTE_NAME
. If it succeeds, the custom error route page is loaded. If it fail, it falls back to the default error page. The error page can be loaded at any route name, so it is not feasible to actually declare a callback for every possible erroneous route., so: When the error page is loaded, the router will not check for its routes hash and any time the current URL changes it will try and load the respective component.profile/:uid
, profile/:uid/info
and profile/:uid/feed
. The profile component is loaded as the active page whenever /profile
is seen as the current top level route. If the application navigates to /profile
the profile component will be pulled down. The router will then check if the profile component can handle the route /profile
. Because the profile component only defined profile/:uid
, profile/:uid/info
and profile/:uid/feed
, it is determined that the profile component cannot handle /profile
. Now the router will try to route to the /ERROR_ROUTE_NAME
route, loading a custom 404 page. This tries to load a routable component from /ERROR_ROUTE_NAME
. If it succeeds, the custom error route page is loaded. If it fail, it falls back to the default error page. The error page can be loaded at any route name, so it is not feasible to actually declare a callback for every possible erroneous route., so: When the error page is loaded, the router will not check for its routes hash and any time the current URL changes it will try and load the respective component.The part in bold isn't implemented yet. When the router loads /ERROR_ROUTE_NAME
, it looks for the handler of current route on the custom error component, just like any other routable component. Because we can't define every possible erroneous route in the error component's routes hash, and because specifying a catch all route here would mean we could never load another page (because the error route would handle every possible url change), the application sees that the /ERROR_ROUTE_NAME
isn't handled and tries to load /ERROR_ROUTE_NAME
again.
What needs to happen to fix this: The router needs to know when we are in an error state and not check the error component's routes hash before rendering. Any time the window location changes, the router needs to try and re-load the component specified.
Resolved in https://github.com/reboundjs/rebound/pull/59
There are a couple other router bugs detailed in other issues, but this PR resolved the error page loading features.
The Rebound router needs to have a default error templates, and provide the user the option to override these defaults with their own custom templates.