跪拜 Guibai
← All articles
Frontend · Architecture · Design Patterns

A Library-Agnostic Geometry Editor That Runs Without a UI

By 岭南灯火 ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Frontend teams that embed drawing tools into dashboards, GIS apps, or canvas editors often hit a wall when the library's UI or map dependency can't be swapped. A Facade-and-adapter architecture makes the editor a drop-in component that survives library migrations and supports imperative, headless use.

Summary

Most map-drawing tools bind tightly to a single library and a fixed UI, making integration and customization painful. This design series lays out a library-agnostic geometry editor where the host application interacts only with a Facade, and all rendering passes through a swappable map adapter. Drawers and modifiers use the Strategy pattern, while elements gain hover and edit capabilities through marker interfaces, keeping the core logic free of framework-specific code. Two minimal sequence diagrams show the closed loops for polygon drawing and vertex dragging, with the host never touching the map library directly. The series spans seven articles covering the Facade, event flow, data objects, multi-mode coexistence, auxiliary editing handles, engineering conventions, and the underlying design patterns, each ending with guidance on when to apply or skip a technique.

Takeaways
All host interaction goes through a single Facade; drawing and editing logic never calls a map library directly.
Rendering is isolated behind a MapAdapter that translates core geometry into library-specific draw calls.
Drawers and Modifiers are composed via the Strategy pattern, so adding a new shape or edit mode doesn't ripple through unrelated code.
Elements acquire hover and edit behavior through Hoverable and Editable marker interfaces rather than base-class inheritance.
Hotkey and cursor controllers are optional modules assembled by the Facade, not baked into the core.
Each article in the series closes with concrete advice on when a pattern is necessary and when it can be omitted.
Conclusions

Separating the editor into a headless, UI-free core and a rendering adapter turns it from a widget into a library — a distinction most map-drawing tools never make.

The design treats the host and the map library as external peers, giving the editor exactly two touchpoints: an imperative API and a coordinate contract. That constraint is what makes cross-library support possible without abstraction leaks.

Ending each article with 'when not to use this' is a rare discipline in technical writing; it signals that the patterns are chosen for specific integration pain, not for architectural purity.

Concepts & terms
Facade pattern (in this editor)
A single entry-point class that the host application talks to. It assembles internal controllers (drawers, modifiers, hotkey manager) and exposes only imperative commands and events, hiding all internal structure.
MapAdapter
The outermost layer that translates the editor's core geometry operations into calls on a specific map library (Leaflet, Cesium, MapLibre, etc.), enforcing a coordinate contract so the core stays library-agnostic.
Hoverable / Editable markers
Interfaces applied to geometry elements to grant them hover detection or vertex-editing capabilities, avoiding deep inheritance hierarchies and keeping the data objects otherwise stateless.
Source: juejin.cn ↗ Google Translate ↗ Backup ↗