Customize displayed bus stops via a URL query #17

New issue

Open

opened 2026-10-03 07:36:00 +00:00 by tentype · 0 comments

tentype commented

2026-10-03 07:36:00 +00:00

Member

Objective

The current bus sign only shows stops 4407 (tepper) and stop 7117 (UC). We'd like to be able to customize this by passing the stops query parameter in the URL, like so:

https://bus-sign.scottylabs.org/?stops=4407,7117

That is, if stops=X,Y, then display stop X on the left and stop Y on the right. If stops is not defined, then default to 4407 and 7117.

Assume there are exactly two bus stops in the query parameter, separated by commas. If there is not exactly two, then reject it with some kind of error. (In the future, we'll make this more general but for now just focus on two)

Suggested Approach

The stops we pass into PRT's API are currently defined as a constant &str array STOPS in backend/src/lib.rs. You'll want to define a struct to deserialize the stops parameter and update get_predictions to accept the parameters rather than the constant. The Query extractor will probably be used here.

We cache API calls in the backend. If there are multiple requests to the backend with different stops, then this might cause the cache to repeatedly overwrite itself (which defeats the purpose of a cache!). Make sure that this is handled properly as well.

Next, you'll have to edit frontend/src/App.svelte to accept a new stops parameter (likely using the URLSearchParams interface) and display the corresponding data from the backend. The stops are defined as a constant right now, so you'll need to figure out how to change that to a parameter. For inbound vs outbound, use your own discretion (see if there's a way to differentiate between them based on the stop number, otherwise feel free to skip it). Just make sure that the default bus sign looks the same as usual.

Note to contributors

Take your time with this. While AI can probably one-shot the code, PLEASE try to do it by yourself for the learning experience. Try to use AI to explain things, not write code for you.

This video tutorial is lengthy, but it assumes no prior Rust experience. The first 20 minutes are dedicated purely to giving an overview Rust. The remaining parts of the video go over Axum, the web app framework we use.

You can also find resources linked on the CMU course 98-008: Intro to Rust Lang! Click on the materials dropdown of each lecture in the Schedules page (shameless plug)

The frontend should be a bit easier to pick up, but if you'd like, check out the official Svelte tutorial! In particular, you may find lifecycle hooks like onMount to be useful for this.

## Objective The current bus sign only shows stops 4407 (tepper) and stop 7117 (UC). We'd like to be able to customize this by passing the `stops` query parameter in the URL, like so: https://bus-sign.scottylabs.org/?stops=4407,7117 That is, if `stops=X,Y`, then display stop `X` on the left and stop `Y` on the right. If `stops` is not defined, then default to 4407 and 7117. Assume there are exactly two bus stops in the query parameter, separated by commas. If there is not exactly two, then reject it with some kind of error. (In the future, we'll make this more general but for now just focus on two) ## Suggested Approach The stops we pass into PRT's API are currently defined as a constant `&str` array `STOPS` in [backend/src/lib.rs](https://git.cmu.dev/ScottyLabs/bus-sign/src/branch/main/backend/src/lib.rs). You'll want to define a struct to deserialize the `stops` parameter and update `get_predictions` to accept the parameters rather than the constant. The [`Query` extractor](https://docs.rs/axum/latest/axum/extract/index.html) will probably be used here. We cache API calls in the backend. If there are multiple requests to the backend with different `stops`, then this might cause the cache to repeatedly overwrite itself (which defeats the purpose of a cache!). Make sure that this is handled properly as well. Next, you'll have to edit [frontend/src/App.svelte](https://git.cmu.dev/ScottyLabs/bus-sign/src/branch/main/frontend/src/App.svelte) to accept a new `stops` parameter (likely using the [`URLSearchParams` interface](https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams)) and display the corresponding data from the backend. The stops are defined as a constant right now, so you'll need to figure out how to change that to a parameter. For inbound vs outbound, use your own discretion (see if there's a way to differentiate between them based on the stop number, otherwise feel free to skip it). Just make sure that the default bus sign looks the same as usual. ## Note to contributors Take your time with this. While AI can probably one-shot the code, PLEASE try to do it by yourself for the learning experience. Try to use AI to explain things, not write code for you. [This video tutorial](https://www.youtube.com/watch?v=iPNEhKMIqNg) is lengthy, but it assumes no prior Rust experience. The first 20 minutes are dedicated purely to giving an overview Rust. The remaining parts of the video go over `Axum`, the web app framework we use. You can also find resources linked on the CMU course [98-008: Intro to Rust Lang](https://stuco.rs/)! Click on the materials dropdown of each lecture in the Schedules page (shameless plug) The frontend should be a bit easier to pick up, but if you'd like, check out the [official Svelte tutorial](https://svelte.dev/tutorial)! In particular, you may find [lifecycle hooks like `onMount`](https://svelte.dev/docs/svelte/lifecycle-hooks) to be useful for this.

tentype added the

good first issue

enhancement

labels

2026-10-03 07:36:00 +00:00

tentype changed title from ~~Customize displayed bus stops via the URL path~~ to Customize displayed bus stops via a URL query

2026-10-03 07:36:11 +00:00

tentype added

type/feature

and removed

good first issue

labels