Choosing Between f7.request and fetch in Framework7

The decision and constraints

You need to fetch JSON from an API inside a Framework7 application. Framework7 provides a built-in helper, f7.request, but the browser also offers fetch. Choosing the wrong one means either writing extra boilerplate to show and hide loading indicators, or pulling in an abstraction your target browsers do not need.

Useful takeaway: choose f7.request when you want Framework7 to manage the preloader and JSON parsing automatically, especially if you support older browsers. Choose native fetch when you target modern browsers only, prefer async/await, or need response streaming.

Supported options compared

Feature	f7.request	Native fetch
Browser support	Graceful degradation; behavior varies by Framework7 version	Modern browsers only; older browsers need a polyfill
JSON parsing	Automatic in many configurations	Manual: call response.json()
Loading indicator	Can tie into Framework7's preloader	Manual: call f7.preloader.show() and hide()
Cancellation	Version-dependent; check your release's API	AbortController
Syntax style	Callbacks or promises depending on version	Promise-based; fits async/await
Streaming	Limited	Supported via response.body readers
Bundle impact	Part of Framework7; small abstraction layer	No extra dependency

Trade-offs by scenario

Legacy or mixed browser support

If your users run older WebViews or browsers without fetch, f7.request can reduce the need for separate polyfills because Framework7 handles the underlying transport. Confirm this in your installed Framework7 version's documentation, because the helper's internals can change between releases.

Modern single-page application

If you target evergreen browsers, native fetch avoids an extra abstraction. You must, however, manually wire Framework7's preloader to the request lifecycle and check response.ok, because fetch only rejects on network errors, not HTTP error statuses such as 404 or 500.

Cancellation and cleanup

fetch works with AbortController, a standard web API for cancelling in-flight requests. With f7.request, cancellation support depends on the Framework7 version, so test the abort path before relying on it in production.

Implementation: f7.request with automatic preloader

This snippet shows the general pattern. Adapt argument names to your Framework7 version.

import { f7 } from 'framework7';

async function fetchWithF7Request(url) {
  f7.preloader.show();

  try {
    // Verify exact signature in your Framework7 docs; this is illustrative.
    const response = await f7.request.get(url, { dataType: 'json' });
    return response;
  } catch (error) {
    f7.dialog.alert('Request failed');
    throw error;
  } finally {
    f7.preloader.hide();
  }
}

Where to run: in your Framework7 project's source directory, inside a component or service module. Required permissions: none beyond normal file access. Expected check: the preloader appears before the network call and disappears in the finally block. Risk: omitting finally leaves the preloader stuck on screen.

Implementation: fetch with manual preloader and cancellation

import { f7 } from 'framework7';

let controller;

async function fetchWithNativeFetch(url) {
  f7.preloader.show();
  controller = new AbortController();

  try {
    const response = await fetch(url, {
      signal: controller.signal,
    });

    if (!response.ok) {
      throw new Error(`HTTP ${response.status}`);
    }

    // Manual JSON parsing is required.
    const data = await response.json();
    return data;
  } catch (error) {
    if (error.name === 'AbortError') {
      console.log('Request was cancelled');
    } else {
      f7.dialog.alert('Request failed');
    }
    throw error;
  } finally {
    f7.preloader.hide();
    controller = null;
  }
}

function cancelRequest() {
  if (controller) {
    controller.abort();
  }
}

Where to run: same project source directory as above. Required permissions: none. Expected check: opening Chrome DevTools → Network shows the request; calling cancelRequest() marks it as cancelled. Risk: forgetting response.ok lets error statuses pass as successful responses.

Validation steps

1. Open your app in a browser and open DevTools → Network.
2. Trigger the request using each implementation separately.
3. Confirm the Framework7 preloader appears before the request starts and hides after it settles.
4. Inspect the response: with fetch, verify you called response.json(); with f7.request, verify the parsed object is available according to your version's docs.
5. Invoke the cancellation path and confirm the Network panel shows a cancelled request and the error handler runs.

If the preloader stays visible after a failed request, check that hide() is inside finally or both success and error branches.

Limitations and version assumptions

• This guide assumes Framework7 v7 or later with a module bundler such as Vite or Webpack. Older releases may expose f7.request differently.
• f7.request behavior, including whether it uses fetch or XMLHttpRequest internally, can change between Framework7 versions. Check your installed release's changelog.
• Native fetch is not available in Internet Explorer or very old WebViews without a polyfill.
• This is a code-level decision, so there is no database rollback. Revert the import or helper calls if the chosen client causes regressions.