default sort by closest to user

[jacobvenable]

related to #465

Description

When retrieving resources by category or subcategory, the client app sorts the results by what is open. https://github.com/CodeForBoulder/upswyng/blob/ebd9dcf6190ce4baab16dc7027eda10626ff936f/packages/web/src/components/CategoryResults.tsx#L48

We should add another sorting step that sorts the resources to display those closest to the user first. This could either be done client-side (with another sorting function) or we could update the api to do both of these sorting options server side.

If we want to move this logic to the server, we will need to make a new endpoint (something like /api/v2/resources) where the client can send in a bunch of query params and get the specific results they are looking for.

interface ResourcesV2Params {
  category?: string;
  subcategory?: string;
  coordinates?: string;
  /** we may not need this yet but if we ever expand outside of Boulder this could be nice */
  localtime?: string;
  /** optional - but one day soon we may need to paginate these results */
  page?: number;
}

Checklist

• [ ] Decide if this logic should live client-side or server-side.
• [ ] when retrieving resources by a category and sub-category, and the user provides their coordinates (OR we apply the sorting client-side and leave the API as it is), the list of resources provided is sorted in the following order by default:

1. resources that are open sorted by those closest to the user
2. resources that are closed sorted by those closest to the user

• [ ] when retrieving resources by a category and sub-category, and the user does not provide their coordinates, the list of resources is not sorted by proximity to the user (OR we just leave the API as it is)

Tech Notes

• This sorting could be used in other lists, so it may make sense to create a central sortByProximity utility.
• Neither of the current category/subcategory endpoints currently support accepting a user's coordinates
• front-end hook handling category request
• front-end hook handling sub-category request
• Category API Route
• Category Model
• Subcategory API Route
• Sub-category Model

[amites]

started looking into this

[amites]

it's a rabbit hole to sort this server side with mongo

nosql is not known for it's ability to handle joins well

I'm stashing an attempt that gets close but still takes a lot of massaging but feels like a dead end

going to add a client side sort by distance util and apply it