After doing a minimal test of WASM to JS bindings, I'd suggest this is the first "real" project to attempt.
The OSRM parser is just parsing (string) data into our standardized data model. It's also a full "object", so it should be a good representative of future work.
You'll need to ensure all data models (Route etc.) are accessible from JavaScript as well. It looks like there are two approaches to this. Some things can be exposed with a #[wasm_bindgen] attribute, but others (ex: with collections; probably many of our types) will need to use serde. This page documents how to do it in serde: https://rustwasm.github.io/docs/wasm-bindgen/reference/arbitrary-data-with-serde.html. It's nothing out of the ordinary, and we already conditionally derive this anyways for testing on many types.
Completion criteria:
[ ] Ability to create an instance of OsrmResponseParser from JavaScript with configurable polyline precision
[ ] Ability to parse a string response. It doesn't need to be anything fancy; just a demo JS + HTML where a hard-coded string gets parsed and the result logged to the console or something. Here are several example strings
After doing a minimal test of WASM to JS bindings, I'd suggest this is the first "real" project to attempt.
The OSRM parser is just parsing (string) data into our standardized data model. It's also a full "object", so it should be a good representative of future work.
You'll need to ensure all data models (
Routeetc.) are accessible from JavaScript as well. It looks like there are two approaches to this. Some things can be exposed with a#[wasm_bindgen]attribute, but others (ex: with collections; probably many of our types) will need to useserde. This page documents how to do it in serde: https://rustwasm.github.io/docs/wasm-bindgen/reference/arbitrary-data-with-serde.html. It's nothing out of the ordinary, and we already conditionally derive this anyways for testing on many types.Completion criteria:
OsrmResponseParserfrom JavaScript with configurable polyline precision