-
Notifications
You must be signed in to change notification settings - Fork 4
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
base: john/20316-nested-object-support
Are you sure you want to change the base?
Location details: crashes list #1640
Conversation
columns={locationCrashesColumns} | ||
initialQueryConfig={locationCrashesQueryConfig} | ||
localStorageKey="locationCrashesQueryConfig" | ||
contextFilters={locationIdFilter} |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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. 👍
There was a problem hiding this comment.
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}> |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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[] = [ |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 pagecrash_timestamp
- so that we have a UTC timestamp to operate on
There was a problem hiding this 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} |
There was a problem hiding this comment.
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}> |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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[] | |||
} | |||
|
|||
/** |
There was a problem hiding this comment.
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]); |
There was a problem hiding this comment.
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
There was a problem hiding this 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!
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?
Testing
URL to test: Local
Steps to test:
# from /database hasura migrate apply hasura metadata apply
Ship list
main
branch