Skip to content

Conversation

@Duckapple
Copy link

In scenarios where you deploy your own web app, with sveltekit or not, using the window object is fine, since you control everything about the page.

However, in browser extensions, we can't expect to populate the window object, since we might collide with the underlying page or other extensions. If the versions are mismatched, and you depend on something older or newer than the others, your extension and the page might break in unexpected ways!

This PR allows you to Bring Your Own Mapbox, by providing the library directly to the component. By providing the library yourself, you completely avoid using the window object, which in turn lets the underlying page do whatever it wants without being bothered by your extension.

In scenarios where you deploy your own web app, with sveltekit or not,
using the window object is fine, since you control everything about the page.
However, in browser extensions, we can't expect to populate the window object,
since we might collide with the underlying page or other extensions.

This PR allows you to Bring Your Own Mapbox, by providing the library directly
to the component.
@Duckapple
Copy link
Author

An alternative API would be to put the mapbox library in a context, where the setContext could be exposed as API for the consumer of this package. That way, the user still has very granular control, without having to prop-drill or import the library whenever they use a map.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant