Would an embeddable or headless Maputnik editor be useful?

[deniial00]

I've been looking into using Maputnik inside a larger application, where the host app owns things like routing, loading and saving styles, and possibly the surrounding UI.

I put together two rough POCs to see what this could look like.

Embeddable React editor

This version wraps the existing Maputnik editor in a React component. The host provides the style and handles persistence, while Maputnik keeps control of most of the editor UI.

feature/embeddable-editor

Headless editor core

The second version moves style state and editor operations into a small framework-independent core, with React hooks on top. The sample uses the same core in two ways: once with existing Maputnik components, and once with a custom shadcn UI.

feature/headless-editor-core

The headless experiment came from a question that came up while building the first POC: for deeper integrations, is it more useful to reuse the whole editor, or to provide the editing model and let the host build its own UI?

Both branches are still experiments. I'm not proposing a finished API at this point. Before taking either approach further, I'd like to understand whether this is something others would use and whether it belongs in Maputnik itself.

This could also make it easier to add style editing to applications built around Martin (maplibre/martin#852) or similar tile-serving stacks. The host could keep control of sources, authentication and style storage, while using either the complete Maputnik editor or only the headless editing building blocks.

A few questions:

• Would you use Maputnik as part of another application or product?
• Would a complete editor component be enough, or would you need headless APIs and hooks?
• Which parts should Maputnik own, and which parts should stay with the host application?
• Have you already tried integrating Maputnik somewhere? If so, what was difficult?

Any feedback on the general direction would be useful. The implementation details can change; right now I'm mainly interested in whether the use case exists.

[HarelM]

If you have a UI that edits a style I don't think you need maputnik, you can simply use maplibre-gl-js itself, can't you?

Regarding embedding maputnik in other applications, I think that making it generic with the relevant look and feel of the host application is a lot of work, and I'm not sure it will really look good.
Having said that, I'm guessing you might want that, but in that case I would consider just using maputnik's whole screen mode as I don't really see how it would fit into another app, which in this case just allowing to surf to it is probably enough.

In any case, I think a better problem statement might be worth defining here...

[deniial00]

Currently, we don't provide end users with the ability to modify a project's style directly. Supporting CI/branding and general look-and-feel would not be a major issue in itself. At the moment, however, project styles are edited manually using a JSON editor within the web app and then persisted to the database.

On top of that, we have made quite a few custom extensions to the style.json format, including additional attributes and support for 3D objects via Three.js. We also dynamically merge a base style.json with project-specific styling, such as additional layers and sources as well as project-level overrides.

That said, I realize that even with headless components, we would still need to customize them quite extensively to fit our requirements. Given how niche our use case is, we're probably better off building a fully custom solution from scratch rather than trying to adapt an existing component system.