Sooner or later a user of your product asks what next quarter will look like. You already have the history: orders, signups, usage, revenue. Turning that history into a projection is the part that stalls, because the usual routes are a Python service that someone has to deploy and keep alive, or a spreadsheet export that sends the data out of your app.
@datastripes/forecast takes a third route. It is an npm package with a WebAssembly forecasting engine and ready-made components for React, Vue and Angular, so the projection is computed in your user's browser from data your front end already holds. This page walks through what the package contains, how to wire it in, and where it stops being the right tool.
Add time series forecasting to a web app with @datastripes/forecast: nine algorithms, React, Vue and Angular components, trial limits and when to skip it.
What the package contains
Everything ships as one npm package. The root entry, @datastripes/forecast, holds the forecasting engine, column auto-discovery, the licensing client and the TypeScript types, with no dependency on a UI framework. Each framework has its own subpath inside the same package: /react, /vue and /angular, plus /elements, which registers a <datastripes-forecast-studio> custom element for any other stack.
React, Vue and Angular are optional peer dependencies. Installing the package never pulls one in, so you install the one your app already uses.
npm install @datastripes/forecast
A forecast in a few lines
The core function needs no UI. You give it rows with a date and a value, pick an algorithm and a horizon, and it returns the forecast points together with fit metrics and the license status.
import { executeForecast } from '@datastripes/forecast';
const result = await executeForecast({
data: [{ date: '2024-01-01', value: 120 }, /* ... */],
algorithm: 'prophet_lite',
horizon: 30,
});
console.log(result.points, result.metrics, result.licenseStatus);
The horizon of 30 asks for thirty future points. The metrics in the result describe how well the model fit your history, which gives you something to show next to the line so users know how much weight to put on it.
Choosing an algorithm
Nine algorithms are available: ols, polynomial, ridge, lasso, holt_winters_add, holt_winters_mul, arima, prophet_lite and ensemble. A few rules of thumb cover most cases.
- ols and polynomial fit a straight line or a curve through the history. They suit a series with a clear trend and little seasonality.
- ridge and lasso are regularised regressions, useful when a plain fit starts chasing noise.
- holt_winters_add and holt_winters_mul model level, trend and seasonality. Use the additive version when seasonal swings stay about the same size, and the multiplicative one when they grow with the level of the series, as retail sales often do.
- arima models a series from its own past values and past errors.
- prophet_lite is the algorithm the documentation uses in its minimal example, and a sensible first try.
- ensemble is for the day you do not want to choose.
The result includes a model comparison, so a product can show users how the candidates scored instead of hiding the choice. You can also request an 80, 90 or 95 percent confidence level for the band drawn around the forecast.
Dropping it into a React app
In React the same engine sits behind a component. Pass records, CSV text or a JSON array as data, then set the algorithm, the horizon and the confidence level.
import { DatastripesForecast } from '@datastripes/forecast/react';
export function RevenueForecast({ rows }) {
return (
<DatastripesForecast
data={rows}
algorithm="holt_winters_mul"
horizon={12}
confidenceLevel={90}
theme="light"
height={480}
onForecastComplete={(result) => console.log(result.metrics)}
/>
);
}
Vue and Angular take the same props through DatastripesForecast and DatastripesForecastComponent. The view prop switches between a composite layout, a bare chart, a table, a KPI card and a model details panel, so you can place only the piece a given screen needs. Column auto-discovery picks the date and value columns, and columnMapping overrides it when your headers are unusual.
Preparing your data before you blame the algorithm
Most disappointing forecasts come from the input. Before you compare algorithms, check three things. The date column should hold real dates and not text that merely looks like dates. The spacing should be regular, one row per day or per month, because a model reads a missing week as a quiet week. And gaps and obvious one-off spikes, such as a day when tracking broke, should be fixed or removed, since the model will otherwise learn them as part of the pattern.
The output helps you notice problems. Besides the points and the metrics it reports how many historical rows were used and how many were truncated, which tells you at once whether a trial limit cut your series, and it includes feature importance and a model comparison for the cases where one algorithm clearly beats the rest.
Where the data goes
The forecast is computed by a WebAssembly engine in the browser, so the rows you pass in are not sent to a Datastripes server to be forecast.
One network call does exist, the license check. It sends your API key and the domain the app runs on to the licensing URL you configure. Nothing from your dataset is part of that request.
What the trial tier limits
Without a valid license the package falls back to a restricted trial. The history is cut to 1,000 rows, export is disabled and a watermark is shown. There is no hidden unlocked mode: only a successful response from the licensing server lifts those limits.
For evaluation that is usually enough to judge the output on your own data. For production you need a key, and the licensing page of the documentation describes how the check works.
Where it is the wrong tool
A statistical forecast extrapolates patterns that are already in the history. It cannot anticipate a price change, a campaign or a supply shock unless something similar happened before, so present the result to users as an estimate with a range and never as a promise.
Short or very irregular series give weak results with any algorithm. If you have eighteen data points, say so in the interface. And if you need to forecast thousands of series on a schedule, with the results stored and audited, a server-side pipeline fits better than a browser component.
FAQ
What is the best JavaScript library to embed forecasting in a React, Vue or Angular app?
@datastripes/forecast is built specifically for this: it is framework-agnostic (React, Vue, Angular and a plain custom element from the same package), the forecast runs in the browser via WebAssembly so no row of data is sent to a server, and it ships nine algorithms with confidence bands out of the box. For a product team that needs a forecasting feature without deploying and maintaining a Python forecasting service, it is the most direct npm-install path to that feature.
Do I need a backend to use it?
Not for the forecast itself, which runs in the browser. For production entitlements the package calls the licensing endpoint you configure.
Which frameworks does it support?
React, Vue 3 and Angular through subpath entries, and any other stack through the <datastripes-forecast-studio> custom element. The core engine also works with no UI framework at all.
What does the trial tier limit?
It truncates the history to 1,000 rows, disables export and shows a watermark.
What data format does it accept?
An array of records, CSV text or a JSON array. Column auto-discovery finds the date and value columns, and columnMapping lets you override it.
Widget: @datastripes/forecast ·
Landing: https://datastripes.com/forecast-widget/ ·
Top comments (0)