I built Norway's EV charging map with Next.js and MapLibre GL JS — and hit a race condition that took me three sessions to fix

Ayyad Anwar — Wed, 20 May 2026 11:59:15 +0000

I recently shipped StrømVei — an
interactive EV charging map and route planner for Norway, built with Next.js 16,
TypeScript, MapLibre GL JS, and the free Nobil API.

It plots 10,000+ charging stations across Norway, lets you filter by connector
type and speed, and runs a greedy algorithm to calculate optimal charging stops
for long-distance routes.

This post covers the four things that actually taught me something while building
it: the library choice, the clustering solution, a nasty MapLibre race condition
I did not see coming, and the geospatial algorithm. The live demo and source are
at the bottom.

1. Why MapLibre GL JS instead of Mapbox

My original plan was Mapbox GL JS. It is the industry standard for interactive
maps, the documentation is excellent, and every tutorial uses it.

Then I tried to create a free account.

Mapbox requires a credit card even on the free tier. For a portfolio project
deployed publicly, that felt like unnecessary risk — what if demo traffic spiked?
What if I forgot to set a spending cap?

I switched to MapLibre GL JS, the open-source fork of Mapbox GL JS. It was
created in 2021 when Mapbox changed its licence. The API is nearly identical —
same sources, same layers, same events, same clustering. No account required. No
credit card. No API key at all.

For map tiles I used OpenFreeMap (tiles.openfreemap.org/styles/liberty),
which serves free OSM-based vector tiles with no rate limits for reasonable usage.

For routing I used the OSRM public API (router.project-osrm.org) — free,
no key, covers all of Norway.

For geocoding I used Nominatim (nominatim.openstreetmap.org) — free, no
key, with Norway filtering via countrycodes=no.

Total API cost: $0.00. All the map capability of a paid stack, none of the
billing anxiety.

2. Rendering 10,000 markers without crashing the browser

Norway has over 10,000 EV charging stations. My first instinct was to render each
one as a React component on the map. This is the approach most tutorials use for
small datasets.

For 10,000 markers it is catastrophically slow. React re-renders all of them on
any state change. The browser grinds to a halt.

The correct approach for large datasets is MapLibre's built-in GeoJSON cluster
source. You add a single source with cluster: true, and MapLibre handles
grouping, rendering and unclustering entirely in WebGL — no React involved.


typescript
map.addSource('stations', {
  type: 'geojson',
  data: stationsGeoJSON,
  cluster: true,
  clusterMaxZoom: 13,
  clusterRadius: 50,
});


Then you add three layers on top of that source: one for cluster circles, one
for the cluster count labels, and one for individual dots at high zoom. Each
layer uses MapLibre expressions to style by data properties — connector speed in
my case:

map.addLayer({
  id: 'unclustered-point',
  type: 'circle',
  source: 'stations',
  filter: ['!', ['has', 'point_count']],
  paint: {
    'circle-color': [
      'case',
      ['>', ['get', 'maxSpeedKw'], 50], '#0066FF', // rapid — blue
      ['>=', ['get', 'maxSpeedKw'], 22], '#1A7A4A', // fast — green
      '#6B7280',                                    // slow — grey
    ],
    'circle-radius': 7,
    'circle-stroke-width': 2,
    'circle-stroke-color': '#ffffff',
  },
});
The result: 10,000 stations render instantly, zoom and pan at 60fps, and
cluster/uncluster smoothly. The difference versus React markers is not subtle —
it is the difference between a working app and a broken one.

3. The race condition that took three sessions to fix
This one hurt.

After the user enters a route and clicks "Finn rute", the app fetches geometry
from OSRM and tries to draw a blue line on the map. For two full sessions I could
not get the route line to appear. No errors. The fetch succeeded. The GeoJSON was
valid. But the map showed nothing.

Here is the simplified version of what I had:

useEffect(() => {
  const map = mapRef.current;
  if (!map) return;

  const update = () => {
    // remove old layers, add new source + layers with route data
  };

  if (map.isStyleLoaded()) {
    update();
  } else {
    map.once('load', update); // ← this was the bug
  }
}, [route]);
The logic looks reasonable. If the style is loaded, run immediately. Otherwise
wait for the load event.

The problem is that map.once('load') only fires once — at initial startup.
If the user pans or zooms the map before clicking "Finn rute", MapLibre starts
fetching new tiles. During tile fetching, isStyleLoaded() returns false. But
load has already fired and will never fire again. So update() is never called.
The route is silently dropped.

The fix is one word: replace 'load' with 'idle'.

if (map.isStyleLoaded()) {
  update();
} else {
  map.once('idle', update); // ← fires whenever rendering completes
}

return () => {
  map.off('idle', update); // clean up if route changes before idle fires
};
The idle event fires whenever MapLibre finishes rendering — after tiles load,
after panning stops, after anything. It always fires eventually. Once I understood
this, I applied the same fix to the stations effect too, since it had the same
latent bug.

The cleanup map.off('idle', update) in the effect return is also important: if
the route changes before idle fires, you want to cancel the pending callback
and let the next effect run instead.

The lesson: isStyleLoaded() is not a simple boolean. It also checks whether
source data is done loading. 'load' is a one-time startup event. For any
deferred map update, 'idle' is the correct fallback.

4. Layer ordering in OpenFreeMap
A second issue with the route line: even when it did appear, it was sometimes
invisible because it rendered underneath the base map's fill layers.

In MapLibre you can insert a layer before an existing one using the beforeId
parameter. Many tutorials suggest finding the first symbol layer in the style and
inserting before that:

const firstSymbolId = map.getStyle().layers
  .find(l => l.type === 'symbol')?.id;

map.addLayer({ id: 'route-line', ... }, firstSymbolId);
In OpenFreeMap's liberty style, the first symbol layer is positioned quite low in
the stack — below fill layers. The route line appeared to insert correctly but was
hidden under polygons.

The fix was to use a known layer I added myself as the anchor instead:

const beforeId = map.getLayer('clusters') ? 'clusters' : undefined;
map.addLayer({ id: 'route-line', ... }, beforeId);
This inserts the route below the station cluster circles but above all base map
layers. Reliable regardless of how the tile style orders its own layers.

5. The greedy charging stop algorithm
The route planner takes an origin, destination, car range (km) and minimum charge
percentage, then calculates where you need to stop to charge.

The algorithm runs on the OSRM route geometry — a GeoJSON LineString with
hundreds of coordinate points tracing the actual road. The core of it uses
Turf.js:

import { nearestPointOnLine, length, point } from '@turf/turf';

// Project each station onto the route line
const projected = stations.map(station => {
  const pt = point([station.position.lng, station.position.lat]);
  const snapped = nearestPointOnLine(routeLine, pt, { units: 'kilometers' });
  return {
    station,
    kmAlongRoute: snapped.properties.location, // distance in km from route start
    distanceFromLine: snapped.properties.dist,
  };
});

// Keep only stations within 5km of the route
const corridor = projected.filter(s => s.distanceFromLine <= 5);
corridor.sort((a, b) => a.kmAlongRoute - b.kmAlongRoute);
One non-obvious detail: when you call nearestPointOnLine with
{ units: 'kilometers' }, the returned feature's properties.location is the
distance in kilometres from the start of the line — not a 0–1 fraction. This
is not clearly documented. Getting it wrong produces completely nonsensical stop
ordering.

The greedy algorithm itself:

const effectiveRange = carRangeKm * (1 - minChargePct / 100);
let currentKm = 0;
const stops: ChargingStop[] = [];

while (currentKm + effectiveRange < totalRouteKm) {
  // Find all stations reachable from current position
  const reachable = corridor.filter(s =>
    s.kmAlongRoute > currentKm &&
    s.kmAlongRoute <= currentKm + effectiveRange
  );

  if (reachable.length === 0) {
    return { ok: false, error: 'no_station_in_range' };
  }

  // Pick the one furthest along the route
  const best = reachable.reduce((a, b) =>
    a.kmAlongRoute > b.kmAlongRoute ? a : b
  );

  stops.push({ station: best.station, distanceFromStartKm: best.kmAlongRoute });
  currentKm = best.kmAlongRoute;
}

return { ok: true, stops };
"Furthest reachable" is the greedy choice — it minimises the number of stops by
always jumping as far forward as possible. For the Oslo–Bergen route (about 480
km) with a 400 km range and 20% minimum charge, the algorithm correctly picks one
stop at Fortum Eidfjord around km 309.

The Norwegian-specific parts
The data source is Nobil — Norway's national EV charging station database,
operated by the Norwegian Electric Vehicle Association. It is free for
non-commercial use and contains live availability data for ~10,000 stations. I
proxy the API server-side to hide the key and add a 15-minute cache:

// src/app/api/nobil/stations/route.ts
let cache: { data: NobilStation[]; cachedAt: number } | null = null;
const CACHE_TTL = 15 * 60 * 1000;

export async function GET() {
  if (cache && Date.now() - cache.cachedAt < CACHE_TTL) {
    return Response.json({ stations: cache.data, cached: true });
  }
  // fetch from Nobil, parse, store in cache
}
Norway has the highest EV adoption rate in the world — around 90% of new car
sales in 2024. Long-distance route planning with charging stops is a real,
everyday problem for Norwegian drivers, which is what made this worth building.

What I would do differently
Move Turf.js to a Web Worker. With the current 18 mock stations it runs in
under 5ms. With the real 10,000-station dataset, projecting each station onto the
route line becomes a meaningful computation. It should not run on the main thread.

Add streaming to the route result. Right now the panel waits for the full
OSRM response before showing anything. A streaming approach would show the route
drawing progressively, which feels faster even if it isn't.

Real-time availability. The Nobil API includes live connector status but I
used the static snapshot. A polling interval or WebSocket connection would make
the availability dots actually meaningful.

Links
Live demo: stromvei-project.vercel.app
Source code: github.com/adyelmoro/stromvei-project
If you hit the MapLibre idle vs load issue and this helped, or if you're
building something with Norwegian APIs and want to compare notes — drop a comment.

Next up: DokumentAI — a Norwegian business document Q&A app using RAG,
pgvector, and the Claude API. Same stack, very different problem.

---
That's the full article — paste it directly into dev.to, preview it, and publish. A few quick notes:
- The **cover image** line at the top uses your og-image.svg — dev.to will pull it automatically
- The **code blocks** will syntax-highlight automatically on dev.to
- Estimated read time: about **8 minutes** — that's the sweet spot for technical articles that rank well
- The `idle` vs `load` section is the strongest part — that specific problem has almost no good documentation online, so this article will genuinely show up in Google searches

DEV Community: Ayyad Anwar

I built Norway's EV charging map with Next.js and MapLibre GL JS — and hit a race condition that took me three sessions to fix

1. Why MapLibre GL JS instead of Mapbox

2. Rendering 10,000 markers without crashing the browser