Filter and Show Projects list by Council District

TylerMatteo commented 3 months ago

Acceptance Criteria

[x] When user selects a CCD from the Filter by District menu and clicks the "Go to Selected District" button, user is navigated to new /city-council-districts/<cityCouncilDistrictId>/capital-projects route and sees the content panel with the paginated list of projects
[ ] ~~Projects on the map are filtered to only those that overlap with selected CCD. For projects that partially fall outside the CCD, all parts of the project should still be visible.~~ Moved to scope of #62
[ ] ~~Selected CCD boundary is highlighted (figma)~~ Moved to scope of #62
[x] List of projects is paginated, with pagination arguments stored as query params. See Page schema from the underlying API for reference. Preserve other existing query params, such as those for keeping track of filter menu state.
[x] User can click on a project to navigate to the nested route for that project: /city-council-districts/<cityCouncilDistrictId>/capital-projects/<managingCode>/<capitalProjectId>
[ ] User can dismiss the project list detail panel to return to root / route

Designs

desktop and mobile

Out of scope

Data export for projects within the CCD. Disregard "Export" button in figma designs for the purposes of this Issue.

TangoYankee commented 2 months ago

Blocked by #18 and nycplanning/ae-zoning-api#251

TylerMatteo commented 2 months ago

Partially blocked by #28, but work could begin on the detail panel by manually navigating to the /city-council-districts/<cityCouncilDistrictId> route.

TangoYankee commented 2 months ago

@TylerMatteo

Would it be more precise to make the route /city-council-districts/<cityCouncilDistrictId>/capital-projects and not just /city-council-districts/<cityCouncilDistrictId>?

We're showing capital projects within a city council district, not details about the district itself. This would complement the route we use for a specific capital project- /city-council-districts/<cityCouncilDistrictId>/capital-projects/<managingCode>/<capitalProjectId>

TangoYankee commented 2 months ago

When user selects a CCD from the Filter by District menu, user is navigated to new

Is navigation to the list of capital projects prompted by selecting the from the menu? If so, what is the purpose of the "Go to Selected District" button?

TangoYankee commented 2 months ago

List of projects is paginated, with pagination arguments stored as query params. See Page schema from the underlying API for reference.

The linked Figma designs are showing numbered pages. Are there updated designs which reflect that we don't know beforehand how many pages there are? I worry this will cause confusion for the person working on this ticket.

TangoYankee commented 2 months ago

User can dismiss the project list detail panel to return to root / route

Should the query parameters be kept? For example, if you've selected Community District 37, should the query parameters still be 'districtType=cd&districtId=73'

TylerMatteo commented 2 months ago

When user selects a CCD from the Filter by District menu, user is navigated to new

Is navigation to the list of capital projects prompted by selecting the from the menu? If so, what is the purpose of the "Go to Selected District" button?

By "selects a CCD", I meant actually clicking the button. I'll clarify.

TylerMatteo commented 2 months ago

@TylerMatteo

Would it be more precise to make the route /city-council-districts/<cityCouncilDistrictId>/capital-projects and not just /city-council-districts/<cityCouncilDistrictId>?

We're showing capital projects within a city council district, not details about the district itself. This would complement the route we use for a specific capital project- /city-council-districts/<cityCouncilDistrictId>/capital-projects/<managingCode>/<capitalProjectId>

Yep, typo. Fixed above.

TangoYankee commented 2 months ago

I am looking at the panel for the list of capital projects in the desktop version. Would it make sense to make it taller?

TangoYankee commented 1 month ago

@TylerMatteo and @pratishta

I was interacting with the draft in the QA environment. I realized that placing the offset and limit in the URL also means that users can easily edit these values. When the limit is changed from 7, or the offset is changed from a multiple of seven, the app may end up in an odd state- like being on page "3.5".

I was thinking about two approaches to address these odd states: 1) Add checks of the "offset" and "limit" values to enforce their validity. This respects the acceptance criteria but adds complexity to the implementation 2) Replacing these query parameters with a single "page" query parameter. The enforcement for this is much simpler- merely checking whether the value is an integer greater than 0. However, it is a change to the acceptance criteria.

Either approach adds a wrinkle to the scope of the ticket. As such, if we do want to make these adjustment, it may make sense to push the changes to a follow-up ticket.

pratishta commented 1 month ago

Replacing these query parameters with a single "page" query parameter. The enforcement for this is much simpler- merely checking whether the value is an integer greater than 0. However, it is a change to the acceptance criteria.

This is the approach I was going to suggest with something like ?skip=14 for page 2 as the query param. I think offset and limit are not useful terms and difficult for users to navigate anyway if we're trying to design around the routes and history.

TangoYankee commented 1 month ago

difficult for users to navigate

Good point. If this is creeping into UX territory, maybe it would behoove us to get input from the design fellows?

pratishta commented 1 month ago

User can dismiss the project list detail panel to return to root / route

Does this happen when we click on the up chevron?

If so, do we preserve the query params for the filter menu (?districtType=ccd&districtId=23) or no we reset to /?

pratishta commented 1 month ago

After stand up today, we've reached a few decisions:

"Replacing these query parameters with a single "page" query parameter." --> We'll go with the page=1 param
"do we preserve the query params for the filter menu" --> We will preserve filter menu query params
How do we filter projects on the map? --> We'll likely have new geojson endpoints for CCD and CD to use as a mask for the Deck layer

NYCPlanning / ae-cp-map