Drawing Library is deprecated and and starting from May 2026 it will no longer be available

[GianlucaBassi]

Description

https://developers.google.com/maps/deprecations?utm_source=devtools&utm_campaign=stable#drawing_library_deprecated_as_of_aug_8_2025

Google Maps has deprecated the Drawing Library, and starting from May 2026 it will no longer be available. How will this affect this library?

Steps to Reproduce

a warning is displayed on console when using drawing-manager that says:

Drawing library functionality in the Maps JavaScript API is deprecated. This API was deprecated in August 2025 and will be made unavailable in a later version of the Maps JavaScript API, releasing in May 2026. For more info, see https://developers.google.com/maps/deprecations.

Environment

• Library version: "@vis.gl/react-google-maps": "^1.5.1"

Logs

Drawing library functionality in the Maps JavaScript API is deprecated. This API was deprecated in August 2025 and will be made unavailable in a later version of the Maps JavaScript API, releasing in May 2026. For more info, see https://developers.google.com/maps/deprecations.

[usefulthink]

I moved this to the discussions / Q&A section, as it's neither a bug-report nor a feature request

We are aware of this, and I personally appreciate the move. I'm not yet sure if this includes removing the "editable" property for the polygon/polyline/circle/... classes, but from reading it, I'd think that they might stay around.
So the "drawing" library would only affect tha DrawingManager class, and we can very much do without that.

The least we will do is to migrate our editor-example to use an external library like the excellent terradraw instead of the now deprecated library. We have to see if there are other ways to make integrating an editor like that easier for users of this library.

[usefulthink]

So if the "editable" functionality stays around, we'd only have to re-implement the drawing-manager and the controls and we could still use google.maps.Polygon for this. If that is removed as well, we'll have to look for other libraries that implement this functionality. For now the best choice here seems to be terrdraw, but others might emerge.

The nice thing about terradraw is that its implementation works with all map-renderers, and it looks like it would be good place to add contributions to (for example adding support for polygons with holes).

[charlieforward9]

migrate using Terradraw, but at the moment it doesn’t support complex polygons (with holes) which I've currently implemented using this library. I just hope the migration won’t turn out to be too costly.

I added hole support in editable-layers/DrawPolygonMode a few months ago.

I am interested in using 3D tiles rendered through Google Maps for performance benefits, but a big question I have is if the editable-layers will drape properly like they would native to deck.gl.

[usefulthink]

As of now, there is no way to add any sort of dynamic overlay over the 3D Tiles rendered via <gmp-map-3d> (if that's what you mean by 'rendered through Google Maps'), so any deck.gl overlays will be out of the question for now.

The only options to integrate anything into Google's 3D renderer are the built-in elements: polygon/polyline/model3d/marker...

I think, to properly integrate more complex visualisations, there would have to be a way to either directly add 3d-geometry to the renderer or to have a texture-buffer we can write to that is then draped over the terrain.

[usefulthink]

The other thing is, I would love to have an example using deck.gl editable layers together with @vis.gl/react-google-maps.
Haven't looked into it since it still was named nebula.gl – glad to hear it's still (sort of) alive. I'll keep this in my backlog for when I have some time to spend...

[charlieforward9]

to properly integrate more complex visualisations, there would have to be a way to either directly add 3d-geometry to the renderer or to have a texture-buffer we can write to that is then draped over the terrain

I let my agent give a crack at this and did not have much luck - its a complicated problem. I would see the visualiation on a shared context, but camera interaction would not respond properly, nor would draping.

I found this during the hunt: mapbox/mapbox-gl-js#12040 maybe related?

[GianlucaBassi]

Hi @usefulthink ,
just checking in, do you have any updates on this issue?
Thanks in advance!

[usefulthink]

Yes! My colleague @mrMetalWood rewrote our example without using the deprecated DrawingManager (see here c3a4161) and created a new example using TerraDraw instead: https://github.com/visgl/react-google-maps/tree/main/examples/terra-draw

Running examples: https://visgl.github.io/react-google-maps/examples/drawing and https://visgl.github.io/react-google-maps/examples/terra-draw

[GianlucaBassi]

That’s great! Thanks for the update, I’ll definitely take a look at the examples to integrate the changes.

[charlieforward9]

I wonder what the fate of editable-layers is given the strong support and sponsor backing terradraw has.

If a Google is deprecating their drawing tools, and visgl package already uses TerraDraw in examples out of the box, should we have a conversation of having TerraDraw create a deck.gl adapter and archive the editable-layers module? Or is there not feature parity between these packages?

This works around the scary idea I have expressed for porting editable-layers into deck.gl - just passing it along to a better scoped maintainer.

Could this open a conversation to invite TerraDraw into OpenJS Open Visualization? visgl? Just throwing ideas on the wall.

CC @eKerney @ibgreen @chrisgervang @JamesLMilner

[chrisgervang]

The Mapbox drawing library already existed when Nebula.gl (now deck.gl editable-layers) was created - yet they felt it didn't support their use cases at the time.

As I recall, their motivation included overcoming performance issues with the geojson and html techniques other libraries implemented - and adding more advanced draw modes. The other drawing libraries were focused on very simple use cases.

I believe Nebula's use cases included editing large basemap datasets (think, loading an entire cities road network all at once as an editable layer) and making complicated edits.

I haven't dug into terradraw's implementation to see how feature sets compare but I have used it and appriciate how it's compatible with many libraries.

So, I do think it'd be great to have a terradraw deck.gl adapter but I'd push back on the idea that they're of equal capability until we look closer at their implementations.

[eKerney]

@chrisgervang Glad to see support for continuing to move forward with editable-layers. It's has a slow but steady momentum, and I think the details such as separate implementations for Geo vs Cartesian modes, and only importing turf when essential, support the continued quality and performance of the library. @charlieforward9 does a great job reviewing PRs and thinking through long-term implications before updates are merged.

@usefulthink I'm using Google Maps JS primarily for work, and I'd like to "extrude" a few hours towards adding an editable-layers example to @vis.gl/react-google-maps.

[usefulthink]

@eKerney that's awesome! Do you need any assistance with that? I think you should be able to just point your agent to this page and start there: https://visgl.github.io/react-google-maps/docs/guides/writing-examples – But if there are any questions, feel free to open a new feature-request for the demo and take the discussion there.

[eKerney]

@usefulthink here's a basic example using editable-layers with react-google-maps and a DeckGLOverlay. Opencode assisted with a patchDeckEvents() function to intercept user events and vertex dragging by listening to raw DOM events. Will work on am example using the template provided this week.

edit-react-google-maps.mp4

[usefulthink]

Awesome, looking forward to it! Also, we're friends with AI tools here as long as it is human-reviewed :D