Debugging the Google Maps Duplicate Loading Bug in React

ATAYERO CLINTON — Wed, 10 Jun 2026 18:38:32 +0000

Originally published on clintech.me

If you've integrated Google Maps into a React app and seen
Autocomplete randomly stop working, Directions silently fail,
or the API throw google is not defined on second render —
you've hit the duplicate loading bug.

Here's exactly what caused it in my case and how I fixed it.

The setup that broke things

While building delivery address flows at
POLOM — a production e-commerce platform —
I integrated Google Places Autocomplete across 20+ screens.

I had the Maps JavaScript API loading in two places:

A provider.tsx for global script loading across the app
A useLoadGoogleMaps hook inside a shared component

This caused race conditions. The Autocomplete and Directions
APIs were initialising before the script fully resolved in some
renders, silently failing in others. The failure wasn't
consistent, which made it harder to catch.

The fix

Step 1 — Remove the global load

Delete the script tag or next/script call in provider.tsx.
There should be exactly one place the Maps API loads.

Step 2 — Centralise in a hook

Move all loading logic into a single useLoadGoogleMaps hook
using dynamic loading. If you're on Next.js, next/script
with strategy="afterInteractive" inside the hook is the
right approach.

Step 3 — Guard before initialising

if (!window.google?.maps) return;

Check that the API is fully available before attempting to
attach Autocomplete or Directions. Don't assume the script
load event means every namespace is ready.

Step 4 — Scope your ref correctly

Bind the autocomplete instance to inputRef.current explicitly.
If the component remounts, re-initialise the binding — don't
assume the previous instance is still attached.

The result

One load, one source of truth, no race conditions. Autocomplete
and Directions worked consistently across all 20+ screens
without reinitialising on every render.

Security — the step most developers skip

Restrict your API key at the Google Cloud Console level:

HTTP referrers: whitelist your domain only (e.g. https://yourapp.com/*)
API restrictions: enable only the services you actually use — Maps JavaScript API, Places, Directions. Nothing else.

An unrestricted Maps key on a public frontend will get scraped
and abused. It happens faster than you'd expect.

I'm a frontend engineer open to remote EU roles —
connect on LinkedIn
if this was useful.

How I Built Multi-User Apps with Row-Level Security in Supabase

ATAYERO CLINTON — Wed, 03 Jun 2026 17:05:31 +0000

Originally published on clintech.me

When you move from toy projects to real products, the hard problem
isn't styling cards. It's isolation: how do you make sure each user
only sees their own data?

The wrong answer: filter by userId in React and hope no one cheats.

The right answer: Row-Level Security.

What RLS actually is

RLS is a Postgres feature that enforces access policies at the database
level — not the application level. Every query runs through your
policies before returning data.

CREATE POLICY "Users can see their own jobs"
ON jobs FOR SELECT
USING (user_id = auth.uid());

With this in place, even if someone opens DevTools and calls the
Supabase REST API directly with a valid token, they still only get rows
where user_id matches their own auth UID. The database is the
security gate, not your frontend.

How I applied this in ApplyCraft

ApplyCraft is an AI-powered job
tracker I built. Every job, note, and profile is scoped per user.
The policy pattern is consistent across all tables:

jobs.user_id = auth.uid()
job_notes.user_id = auth.uid()
profiles.id = auth.uid()

Even the server-side AI endpoint, which writes outreach copy back
to a job row, verifies ownership before touching the database.
No client-side key exposure, no trust in the frontend.

The mistakes that will burn you

1. Enabling RLS but leaving "allow all" policies

You've technically turned it on but effectively disabled it.
Every policy needs to be explicit.

2. Forgetting write policies

Easy to add SELECT and forget INSERT, UPDATE, DELETE.
Your app will silently fail on writes and you'll spend an hour
wondering why.

3. Trusting only frontend filters

If a table has unrestricted SELECT, any user can bypass your
UI and call the REST endpoint directly. RLS removes that
possibility entirely.

4. Not following the ownership chain on joins

If notes belongs to jobs and jobs belongs to a user, your
note policies should check ownership through that chain, not
just assume the foreign key is enough.

The difference between "multi-user UI" and "multi-tenant product"
is where security lives. Once the database enforces it, your
frontend gets simpler and your app gets much harder to abuse.

I'm a frontend engineer open to remote EU roles, connect with
me on LinkedIn
if this was useful.

DEV Community: ATAYERO CLINTON