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

Location details: crashes list #1640

Open
wants to merge 10 commits into
base: john/20316-nested-object-support
Choose a base branch
from

Conversation

johnclary
Copy link
Member

@johnclary johnclary commented Dec 23, 2024

Associated issues

This PR adds the crashes list to the location details page. I decided to combine the CR3 and non-cr3 crashes into a single table. This feels like a nice improvement over the dual table experience in the old VZE. What do you think?

Screenshot 2024-12-23 at 3 17 05 PM

Testing

URL to test: Local

Steps to test:

  1. Start your local stack - you'll need to apply migrations and metadata for this one
# from /database
hasura migrate apply
hasura metadata apply
  1. Navigation to a location details page and check out that new crashes list. try searching and sorting. Nice!

Ship list

  • Check migrations for any conflicts with latest migrations in main branch
  • Confirm Hasura role permissions for necessary access
  • Code reviewed
  • Product manager approved

@johnclary johnclary added the WIP Work in progress label Dec 23, 2024
@johnclary johnclary changed the base branch from main to john/20316-nested-object-support December 23, 2024 19:17
columns={locationCrashesColumns}
initialQueryConfig={locationCrashesQueryConfig}
localStorageKey="locationCrashesQueryConfig"
contextFilters={locationIdFilter}
Copy link
Member Author

@johnclary johnclary Dec 23, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

new contextFilters prop that let's us pass in this location ID filter . The main challenge here is that the primary queryConfig gets saved in local storage, and we don't want to include the location_id filter in the local storage config, because it's a dynamic value.

I thought about a few a different ways to approach, but this seemed simple enough for now. I believe this is the only place in the app where we'll need to use this new feature.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it took me a second to wrap my head it, but, when I thought about the filter being about crashes in the context of a location, it clicked. I like the name, and I feel like it is straightforward to tie what I see in the network request to the code. 👍

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you mention in your comment the need for the location_id filter to be dynamic unlike the query config thats saved in local storage? i feel like reading your comment here was super helpful but i might have been confused if i just was looking at the code

@@ -53,7 +53,7 @@ export default function TableAdvancedSearchFilterMenu({
<Row className="p-2 bg-light">
{queryConfig.filterCards.map((filterCard) => {
return (
<Col key={filterCard.id}>
<Col key={filterCard.id} xs={12} md={3}>
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

keeps those filter cards from growing too wide

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably not a huge concern, but, in the Crashes list view, I noticed that some of the filter switches become hidden behind the list below when they go full-width at smaller widths. I don't think anyone is using that small of a screen but wanted to mention if it was relevant.

Copy link
Member Author

@johnclary johnclary Dec 31, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah yes—there's some questionable CSS working on this filter menu that i hoped you wouldn't notice. here's another short thread about this menu, too. i will open a follow-up issue to get this UI straightened out 🙏

edit:


const columns = locationCrashesColumns.map((col) => String(col.path));

const locationCrashesFiltercards: FilterGroup[] = [
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the old VZE has a lot of advanced filters on the cr3 crashes table. i'm a bit skeptical we need all of them. i will check with Xavier.

i'd also like to check in with some of our non-VZ users who access this page. we have a few power users identified from the ACC research.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding a few columns to this view:

  • record_locator - so that we can link to the crash details page
  • crash_timestamp - so that we have a UTC timestamp to operate on

Copy link
Contributor

@mddilley mddilley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tested this and everything worked as expected, and I like the combined table! I think the filters cover any case where someone would want to see only CR3 on non-CR3. I often used to forget to scroll all the way down, and I remember that causing a regression or two in the past. Feels like an upgrade to me! 🙌 🚀

columns={locationCrashesColumns}
initialQueryConfig={locationCrashesQueryConfig}
localStorageKey="locationCrashesQueryConfig"
contextFilters={locationIdFilter}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it took me a second to wrap my head it, but, when I thought about the filter being about crashes in the context of a location, it clicked. I like the name, and I feel like it is straightforward to tie what I see in the network request to the code. 👍

@@ -53,7 +53,7 @@ export default function TableAdvancedSearchFilterMenu({
<Row className="p-2 bg-light">
{queryConfig.filterCards.map((filterCard) => {
return (
<Col key={filterCard.id}>
<Col key={filterCard.id} xs={12} md={3}>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably not a huge concern, but, in the Crashes list view, I noticed that some of the filter switches become hidden behind the list below when they go full-width at smaller widths. I don't think anyone is using that small of a screen but wanted to mention if it was relevant.

Copy link
Contributor

@mddilley mddilley Dec 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i tested the down migration, saw the expected error in the graphql response from the missing record location and timestamp columns, and then ran the up again to restore the UI functionality. All of this works! 💯


const typename = "atd_txdot_locations";

/**
* Hook which returns builds a Filter array with the `location_id` param.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo here, maybe just "Hook which returns a filter array.."

@@ -20,6 +20,7 @@ interface TableProps<T extends Record<string, unknown>> {
columns: ColDataCardDef<T>[];
initialQueryConfig: QueryConfig;
localStorageKey: string;
contextFilters?: Filter[]
}

/**
Copy link
Contributor

@roseeichelmann roseeichelmann Dec 31, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what is the general opinion of docstrings in our new VZ typescript codebase? i think it would be helpful to have descriptions for these params here. here are the official typescript doc specifications. seems like the main difference from JSDoc is that it doesn't use type annotations bc that would be repetitive

useMemo(() => {
return buildQuery(queryConfig);
return buildQuery(queryConfig, contextFilters);
}, [queryConfig]);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i see the eslint error here about contextFilters being missing in the dependency array

Copy link
Contributor

@roseeichelmann roseeichelmann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I reallyyyy like how you combined the two tables and simplified the filters for now. Looks and works so good!

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

Successfully merging this pull request may close these issues.

3 participants