Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Feat] Add SSR support or safe usage of AdvancedMarker and DOM-dependent components

Aperta
#810 5 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
react, typescript
Ambito
frontend, web-dev

Direzione di ricerca

Inizia leggendo gli entry point AdvancedMarker, MapControl e APIProvider menzionati nell’issue, quindi riproduci il loro comportamento in una configurazione SSR e hydration. Decidi quale comportamento compatibile con SSR o esclusivo del client supportare, aggiungi la copertura per il rendering lato server e l’hydration e documenta l’utilizzo consigliato per i framework SSR.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Target Use Case

We are using @vis.gl/react-google-maps in a project that renders pages using server-side rendering, and then hydrates them on the client.

However, the current package assumes a browser environment by default — for example, components like AdvancedMarker use ReactDOM.createPortal and interact with the DOM, which causes SSR crashes when the page is pre-rendered on the server.

We are currently forced to wrap these components in client-only guards like:

if (typeof window !== 'undefined') {
  return <AdvancedMarker ... />;
}
const [isClient, setIsClient] = useState(false);

useEffect(() => {
  setIsClient(true);
}, []);

return isClient ? <AdvancedMarker ... /> : null;

It would be helpful if the library could offer a built-in way to make components like AdvancedMarker SSR-safe or optionally lazy-loadable so that SSR apps don’t crash or require workarounds.

Adding SSR support (or safe lazy loading) would benefit anyone using React frameworks like Next.js, Remix, or custom SSR setups that render Google Maps on the server and hydrate them client-side.

This is especially important for:

  • SEO-sensitive apps
  • Performance-focused web apps
  • Sites with server-rendered landing pages that contain maps

It would also reduce the need for wrapping AdvancedMarker and other DOM-dependent components in custom client-only guards, simplifying code and avoiding errors during hydration.

Proposal
  1. Provide a ssr: false or clientOnly: true prop on components like AdvancedMarker or APIProvider that tells them to skip rendering during SSR.
  2. Internally guard browser-only operations in DOM-based components like AdvancedMarker by checking typeof window !== 'undefined' before calling ReactDOM.createPortal.
  3. Document a recommended pattern or wrapper component for SSR users, such as a ClientOnly wrapper like:
function ClientOnly({ children }) {
  const [isClient, setIsClient] = useState(false);
  useEffect(() => setIsClient(true), []);
  return isClient ? children : null;
}
  1. Optionally provide a utility from the package itself:
import { ClientOnly } from '@vis.gl/react-google-maps';
// or
<AdvancedMarker ssr={false} ... />

Even a small guard inside AdvancedMarker (as well as MapControl) would prevent runtime crashes and improve compatibility across frameworks.

Lingua principale
TypeScript
Stelle
1.9k
Fork
195
Merge medio
2g 11h
PR unite (30g)
14

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di visgl/react-google-maps

Tutte le issue di visgl/react-google-maps

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.