Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reconsider Rust UI #12

Open
dabreegster opened this issue Jul 29, 2022 · 0 comments
Open

Reconsider Rust UI #12

dabreegster opened this issue Jul 29, 2022 · 0 comments

Comments

@dabreegster
Copy link
Owner

About half the code in this project is UI (as opposed to the data model + import). (And it's even more after removing temporary importing experiment code!) Much of the effort behind this project has been quickly throwing together bits of UI to visually + interactively debug the data importing process.

I don't think my workflow or the use of widgetry or even Rust has been ideal at all for this. This UI library was designed for different purposes; I used it in this project just because it's all that I know and could quickly make progress with.

Some pain points:

  • There's lots of data in this project, resulting in large 2D tables. People ought to be able to comfortably filter, sort, scroll through, copy rows out, etc. That sort of thing would be trivial with something like d3. But with widgetry, I have to build all of that from low-level / scratch.
  • An interactive shell / notebook environment would've been perfect for interactively debugging matching problems. I could write a Python one-liner to find an example vehicle that matches some too-long trip duration, and then call methods on that object to visualize its trajectory, look at ticketing events, etc. But instead I used print debugging, painstakingly built full UIs to do this kind of debugging, and always paid the penalty of compiling Rust.
  • The final multiday UI logically has a concept of "clicking a link" to jump to a different vehicle / route / stop / page. And there are many filters requiring bits of the UI to get recalculated. All of this has been done in an ad-hoc way that I'm not happy at all about. I have some ideas about how to organize this kind of thing better on top of widgetry, but also, it'd be very worthwhile for me to go learn how the same problems are solved in modern web frameworks.

What I'd've liked instead: write core importing logic in Rust, add a bunch of methods to different objects, but then be able to wire everything up and interactively write code using Python or Javascript. There'd be some common interactive dataviz bits defined there to do things like drawing a trajectory with mouseover for timing, and for drawing a variant with labelled stops. This could be done with wasm-bindgen for JS or pyo3 for Python integration.

I lack experience working with modern JS frameworks / libraries. It'd be great to spend some time experimenting there and revisit how part of this project could be done more easily.

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

No branches or pull requests

1 participant