Start 'Street Explorer' test browser for viewing tests

[BudgieInWA]

Works towards #22, closes #13 by introducing a trunk serve slippy map with controls, that (will hopefully soon) shows the test data from tests/.

TODO

• Allow trunk to read the tests dir to list test cases and load test case files
• Add GeoJSON from a test file to the map (as proof of concept)
• Generate the test list at build time, link to the .json files

CC @droogmic @dabreegster

[dabreegster]

Heads-up, you'll need to rebase against 3fac825, which simplified build deps a bit. It should be straightforward.

It's awesome to see this come along! I'm curious how you find yew; does it work well as a way of writing web apps? If you were using pure JS or TypeScript, what would your typical tech stack of choice be?

[droogmic]

rust nightly?

[droogmic]

I suggest just encoding this using https://github.com/a-b-street/osm2lanes/blob/main/rust-toolchain.toml

[BudgieInWA]

rust beta seems to be working for me, if I understand my setup right, so I'd like to stay there if possible. I'll add the rust-toolchain.toml.

[droogmic]

Apologies for the delay, I missed your ping for my attention :)

I suggest already preparing the continuous deployment to github.io, even if still unfinished.

[droogmic]

I suggest just encoding this using https://github.com/a-b-street/osm2lanes/blob/main/rust-toolchain.toml

[droogmic]

I'll start working at dropping the dependencies you need out of the bottom of osm2lanes :)

[droogmic]

Heads-up, you'll need to rebase against 3fac825, which simplified build deps a bit. It should be straightforward.

It's awesome to see this come along! I'm curious how you find yew; does it work well as a way of writing web apps? If you were using pure JS or TypeScript, what would your typical tech stack of choice be?

+1 on this, as I am not a web / full stack dev. I approached yew as a systems software engineer.

[BudgieInWA]

It's awesome to see this come along! I'm curious how you find yew; does it work well as a way of writing web apps? If you were using pure JS or TypeScript, what would your typical tech stack of choice be?

Through circumstance more than anything, I have worked a lot with React in Meteor projects. I like the declarative style of React, and being consistent with the flow of data.

Looking at the osm2lanes source, yew looks pretty neat. The "event -> message -> state transition -> view calls" workflow seems sensible to me, and being in rust land will bring advantages, right? Like being able to call the impl directly.

The first hurdle will be for me to learn how to interface with existing JS. It looks like I could write the bindgen translation thingo to call into L.OSM.DataLayer, or openFile or whatever function I want to write? A big part of this tends to be sticking together different pieces, so having some JS land code might be appropriate alongside the yew app, but idk.

[dabreegster]

being in rust land will bring advantages, right? Like being able to call the impl directly.

Calling the impl directly isn't one, IMO. We need to make sure the APIs are easy to call in a variety of languages, so more people will actually use them. Calling directly from JS isn't that bad -- see https://github.com/a-b-street/osm2lanes/blob/main/osm2lanes-npm/src/lib.rs and https://github.com/a-b-street/osm2lanes/blob/main/osm2lanes-npm/web/index.html for an example of that. It just uses serde to turn the Rust result into JSON. If we want the resulting object in JS to have methods that call back to Rust, there's probably a way of doing that too, but I haven't got that far in the docs.

The first hurdle will be for me to learn how to interface with existing JS

Unless you specifically like yew or another Rust web framework, I wouldn't advocate for its use, especially if it's going to be hard to interface with things that're easier to do in JS anyway. Also a bit selfishly, I wouldn't mind watching along as you build a React/Meteor app to learn the "normal / modern" JS way of doing things.

[BudgieInWA]

... directly in JS, npm ...

Unless you specifically like yew or another Rust web framework, I wouldn't advocate for its use, especially if it's going to be hard to interface with things that're easier to do in JS anyway. Also a bit selfishly, I wouldn't mind watching along as you build a React/Meteor app to learn the "normal / modern" JS way of doing things.

Using osm2streets via its npm package would be ideal. Its a good demo of the package, which can trivially be added onto the existing client-side Test Explorer whatever the stack.

I will build the Explorer out as a vanilla JS "app", using unpkg, and consider introducing a build toolchain for the JS (maybe align with iD?) if and when it brings advantages, (like TypeScript, testing, etc.).

Maybe serving up test results becomes an API that the test explorer can fetch from. That way, diffs could be served, hot off the build server as the result of a PR check or something. So far, a directory of files is the whole API, so I'll let trunk bundle them, until we replace the dev server with something else.

Lots of the state is already managed by the L.Map and Graphvis instances, and the DOM, so with considered organisation, we shouldn't need too many more dependencies on the client. One "modern" way to go is to lean on the web standards, so lets try that. A framework is a good way to get a build toolchain, a server environment, and some form of communication -- as long as your goals match up with the frameworks features. Lets look towards a bog-standard HTTP API if we need one.

[BudgieInWA]

Apologies for the delay, I missed your ping for my attention :)

:)

I suggest already preparing the continuous deployment to github.io, even if still unfinished.

Yes, great idea! #26

[BudgieInWA]

I will leave these for the next PR:

• Generate the test list at build time to link to each test.
• Adding a writeup to the README showing it off and sharing future plans.