You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
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 orpyo3
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.
The text was updated successfully, but these errors were encountered: