Implement GeoJsonSource for web

[dellisd]

Description

This is a pass at implementing a source for the web version. The js bindings behave somewhat differently from the native/mobile bindings in the sense that the underlying source implementation objects can only really be created using a reference to the Map object. (This will also apply to layers when those are implemented).

I've tried to get around this by "binding" the source implementations to the maplibre-compose object after the source has been added to the map, but this means that some method calls won't work until the source has been added to a map which I fear will introduce some lifecycle headaches when trying to call these methods.

It's also possible this might not end up being an issue in practice, but I haven't been able to test those behaviours yet.

Similarly, many maplibre-gl-js functions return Promises while their native/mobile equivalents are synchronous calls. This effectively makes them impossible to implement under the current APIs.

I wanted to open this PR sooner than later to raise this potential issue in case there are other thoughts (or maybe this has already been raised before?)

Test plan

TBD

Checklist

To your knowledge, are you making any breaking changes?

No

Have you tested the changes? On which platforms?

• Web: Chrome 143.0.7499.170

[sargunv]

Thanks for working on this!

I've tried to get around this by "binding" the source implementations to the maplibre-compose object after the source has been added to the map, but this means that some method calls won't work until the source has been added to a map which I fear will introduce some lifecycle headaches when trying to call these methods.

I'm a bit short on time to dig into this deeply, but this sounds relevant to the future planned decoupling of the style manager from the map in order to support the snapshotter (#266). Snapshotter is native-only, but since the API is tightly coupled to the map on web, that'll be harder to do.

Will have to think more about approaches to deal with it. My initial, unvalidated line of thought:

• on maplibre-gl-js, the style definition (JSON) is a separate object from the Style instance itself
• for the snapshotter on native, we only really need the style definition
• similarly, our Composeable style manager primarily (entirely) updates the paint/layout properties of the style - the definition.
• so, most likely, we should separate the concept of a style definition from a style instance, and couple only the latter to a map. This'd be a major refactor, and might be tricky to get right on native
• I don't want to make the native code too awkward just to support JS. If it can be done with a reasonable end state, I think a major refactor is worth it. But if the refactor leads to a really weird implementation for Native, I'd rather drop JS support

[sargunv]

Short term, my intention is to make progress towards JS by just working on fleshing out the bindings first, without the maplibre-compose integration (#243)

Map lifecycle management needs a rethinking anyway (see all the weirdness around SafeStyle, and the dispose issues on desktop (#716) so it's good we're hitting these constraints now so we can consider them when rethinking the map lifecycle.

Also relevant:

• consider decoupling the map lifecycle from the map view #550
• Some ask earlier about initializing map state outside Compose, like in a view model, for which I can't find the discussion now

[mtpdog]

@sargunv Could you please clarify why the layer (e.g. SymbolLayer) needs 'source' as a parameter not a sourceId? The same source could theoretically be used to draw several layers. My understanding is that it would be better to split Source and Layer instances and handle them separately (update source data in one place and layer rendering in another) with only a sourceId being kept as a layer-to-source link. I believe this is how it is done in Native.

[jgillich]

@mtpdog You can reuse sources with multiple layers. Also I believe this question is off-topic here

[sargunv]

underlying source implementation objects can only really be created using a reference to the Map object

circling back, since #834 this is now also true on desktop, and will soon be true on ios and android through #572. and the native api is much more under our control than it was before, so there's a good chance we can reshape things to be convenient for compose and for a common api.

not 100% sure yet if the web variant will end up on maplibre-native-ffi too. it's technically possible but the toughest integration, and maplibre gl js is still the ideal fit for web.

will spend some time diving into ml-gl-js's api surface now that I've redone native, hopefully can align things in a way that gets web unstuck finally.

[sargunv]

superseded by #848