Error pages

Error pages are applications without a route, meaning that they will be mounted when something goes wrong fetching the required application assets, when the requested application is not available or configured, or in response to internal server errors.

Default error pages

micro-lc provides three default error pages matching errors 401, 404, and 500. It displays 404 when the required route does not match a configured application, while 401 and 500 are triggered on assets fetch errors corresponding to Unauthorized and Internal Server Error respectively.

Important Takeaway

Unauthorized status must be fully managed by your Backend interface.

tip

Default error pages primary color can be set by the --micro-lc-primary-color global variable.

Custom error pages

To override default error pages, a dedicated section of micro-lc configuration is available. Under settings, errors are divided into client errors (key 4xx) and server errors (key 5xx).

Error pages are then just regular applications without route, meaning that you can have parcels, composed applications, and even iFrames rendered in response to errors.

tip

Displaying error pages can be triggered by micro-lc API.

YAML

micro-lc.config.yaml

settings:
  4xx:
    401:
      integrationMode: parcel
      entry: https://my-static-server/custom-401-error-page.html
    404:
      integrationMode: iframe
      src: https://my-website.com/
  
  5xx:
    500:
      integrationMode: compose
      config:
        tag: div
        content: Ops, an error occurred!

JSON

micro-lc.config.json

{
  "settings": {
    "4xx": {
      "401": {
        "integrationMode": "parcel",
        "entry": "https://my-static-server/custom-401-error-page.html"
      },
      "404": {
        "integrationMode": "iframe",
        "src": "https://my-website.com/"
      }
    },
    "5xx": {
      "500": {
        "integrationMode": "compose",
        "config": {
          "tag": "div",
          "content": "Ops, an error occurred!"
        }
      }
    }
  }
}

Lifecycle

When error pages are parcel applications, they have access to a slightly different version of parcels lifecycle methods.

bootstrap, mount, and unmount methods have arguments implementing the following interface.

interface ErrorPageLifecycleProps extends LifecycleProps {
  message?: string
  reason?: string
}

Where message is the primary error message, and reason is the cause of the error.

tip

You can use those extra properties for user feedback.

On top of that, error pages have an extra update method, which is called when the page is already mounted but properties have changed.

function update(props: { message?: string; reason?: string }): Promise<null> {
  /* This is where you do updates */
}