Using Mithril’s m.request for Simple Data Fetching in SPAs

Problem: keeping the view in sync after an HTTP call

In a single‑page application built with Mithril, a common task is to load data from a REST endpoint and display it. If you use the low‑level fetch API directly, you must remember to call m.redraw() after the promise resolves or rejects; otherwise the UI shows stale data. Forgetting this step leads to inconsistent views and extra boilerplate.

Thesis: m.request bundles the request, automatic redraw, and error handling

Mithril’s m.request utility wraps fetch (or an XHR polyfill for older browsers) and returns a native promise. When that promise settles, Mithril automatically triggers a redraw, so the view updates without any manual m.redraw() call. The same mechanism also propagates rejection reasons to the component’s onerror handler, giving you a single place to handle HTTP errors.

How it works

Promise‑driven auto‑redraw

When you invoke m.request(options), Mithril:

1. Creates a promise that resolves with the parsed response body (or rejects on network/HTTP errors).
2. Attaches a .then handler that calls m.redraw() on settlement.
3. Returns the original promise so you can still chain .then or .catch if you need custom logic.

Because the redraw is tied to the promise settlement, you never have to remember to call m.redraw() yourself.

Configurable options

The options object mirrors the familiar fetch arguments but adds a few Mithril‑specific keys:

• method – HTTP verb (default: GET).
• url – endpoint.
• headers – object of request headers.
• data – body payload; automatically serialized unless you provide a custom serialize function.
• deserialize – function to transform the raw response text (default: JSON.parse).
• background – if true, suppresses the automatic redraw; you must call m.redraw() manually.
• initialValue – value shown in the view while the request is pending.

Unified error handling

If the promise rejects, the error propagates to the nearest component’s onerror handler. You can also catch it with .catch on the returned promise. This lets you display a generic error banner or fallback UI without scattering try/catch blocks throughout your code.

Worked example: fetching a list of users

The following component demonstrates the typical usage. Place this code in a file like users.js and mount it with m.mount.

const Users = {
  oninit: function(vnode) {
    // start with an empty array while loading
    vnode.state.users = [];
    vnode.state.error = null;

    // fetch users; m.request returns a promise
    m.request({
      method: 'GET',
      url: 'https://api.example.com/users',
      // optional: customize headers
      headers: { 'Accept': 'application/json' },
    })
    .then(function(result) {
      // on success, store the data
      vnode.state.users = result;
    })
    .catch(function(err) {
      // on any network or HTTP error, capture it
      vnode.state.error = err;
    });
  },
  view: function(vnode) {
    if (vnode.state.error) {
      return m('.error', 'Failed to load users: ' + vnode.state.error.message);
    }
    return [
      m('h2', 'User List'),
      m('ul', vnode.state.users.map(function(user) {
        return m('li', user.name);
      }))
    ];
  }
};

What happens:

1. During oninit, the component sets an empty users array and calls m.request.
2. Mithril sends the GET request using the native fetch API (or XHR polyfill).
3. When the promise settles, Mithril automatically calls m.redraw(), causing the view to re‑run.
4. If the request succeeds, the view renders the list; if it fails, the error message is shown.
5. No explicit m.redraw() is needed.

Trade‑offs and limitations

Background requests

Setting background: true disables the automatic redraw. This is useful when you want to fire a request that does not affect the current UI (e.g., prefetching data for a future route). Remember: you must call m.redraw() yourself after the promise settles, otherwise the view will stay stale.

Large payloads and streaming

m.request buffers the entire response body before invoking deserialize. For very large JSON payloads, binary file uploads, or when you need progress events, consider using the lower‑level fetch or XMLHttpRequest directly, or supply custom serialize/deserialize functions that work with streams.

Actionable closing

If you are building a Mithril SPA and need to fetch data, start with m.request. It gives you a promise‑based API, automatic view updates, and centralized error handling with minimal code. Only opt out of the automatic redraw (via background) or drop to the raw fetch API when you have specific streaming or progress‑reporting requirements.