feat: add fields for V2 Busway screens #19
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Asana: https://app.asana.com/0/1185117109217413/1206932080790885
This is intended to account for the full range of configuration possible for v1 Solari screens, which is documented here. Reviewers should hold me to that 😄
Things to note:
I've added some documentation to the modules I touched, in an attempt to start writing down our expectations of how the configuration should make signs behave. Ideally this is not too detailed (it's not an implementation guide), or there will be drift between the documentation and reality if we change how an existing field is interpreted and forget to update the docs here.
Per discussion with @jzimbel-mbta, the
pill
field from the v1 config is omitted, as this information can be derived from the other fields (and DUP displays already do this, so we would not need to write the logic from scratch).The
filter
field ofSection
does not seem to be used in any active configuration, and was probably only added to accommodate busway screens in the future. Because of this I thought it should be okay to rename this tofilters
, nest the route-direction filtering inside it, and then that allows us to add the "minutes" filtering in a logical place. I'm not sure if changing the existing structure like this actually works, though (I expect it to quietly drop the old field the next time the configuration is serialized, but if that's not the case, this might need to change.)