Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Importing new areas works only on the native version today. For #1009 and other reasons, it could be nice to do this on the web too, even though it'd be slow and someone would have to re-import the map every single session, even when switching apps.
The complication is that we can't just include the extra dependencies in all of the app executables; it would increase initial loading time, even for the common case of only using pre-imported maps. On native, we split out a
cli
binary and call it as a subprocess. The approach in this PR is the same -- we can dynamically load a JS+WASM module and bring in the extra dependencies.This PR is a draft because it's still not working. The two big problems:
When I try to turn a
Map
into bincoded bytes to pass back to JS, it freezes and I can't figure out why. For some reason, serializing aRawMap
works fine, so we could do theRawMap->Map
step back inmap_gui
without needing extra dependencies. But bizarrely, deserializing breaks. The number of bytes passed back is the same, but the actual bytes themselves seem to change. Is it somehow an endianness or 32/64-bit issue, even though both ends are using wasm32?Reading the clipboard contents for the GeoJSON boundary isn't obvious. The WASM support for it requires some experimental flag, and it's async. I found https://docs.rs/quad-wasmnastics/latest/quad_wasmnastics/ as possible reference.
Many other cleanups still needed, but first I just want to get this working