[Enhancement] Switch to decoded URL params for tracking project list view state

[johnclary]

On the project list, we currently base64-encode advanced search params into the browser URL. We should switch to using decoded search params, because:

• It is a better user experience to be able to see legible URLs
• The current base64-encoded URLs are very, very long, and can actually exceed the maximum length supported by our API gateway.

---

Notes on current implementation:

• Logging what is returned from useMakeFilterState is helpful to see the filter state as it is updated. There is data stored in each filter that comes from PROJECT_LIST_VIEW_FILTERS_CONFIG and FiltersCommonOperators
• The encoded data is put together in handleFilterFieldMenuClick in the Filters component
• It is possible that updating the PROJECT_LIST_VIEW_FILTERS_CONFIG[fields] array to be an object might make it easier to access some of these values by name or label
• Worth taking another look at the need for the filters UUIDs added in generateEmptyFilter

Example of current config that is encoded and stored in filter query string:

// Some of the top level key/value pairs come from PROJECT_LIST_VIEW_FILTERS_CONFIG
{
    "cfc6e3aa-5edf-4be2-a77a-d1315ccac3cb": {
        "id": "cfc6e3aa-5edf-4be2-a77a-d1315ccac3cb",
        "field": "project_sponsor",
        "operator": "string_equals_case_sensitive",
        "availableOperators": [
        ...this is a copy of config available in `FiltersCommonOperators`
        ],
        "gqlOperator": "_ilike",
        "envelope": null,
        "placeholder": "Project sponsor",
        "value": "COA ATD Transit Enhancement",
        "type": "string",
        "label": "Sponsor",
        "lookup_table": "moped_entity",
        "lookup_field": "entity_name"
    }
}

[mddilley]

Going to start by figuring out the reason for the uuids. My first thought is that it is a way to keep filters on the same column from merging in the gql abstract code. We build the project list view query differently now so hopefully we can avoid that dependency.

Some inspiration

• https://marmelab.com/react-admin/List.html#filter-query-parameter
• https://marmelab.com/react-admin-helpdesk/#/tickets?displayedFilters=%7B%7D&filter=%7B%22customer_id%22%3A%22ccb36ea0-92eb-49a2-93e2-2d23e0f74f04%22%2C%22product_id%22%3A%22add57351-1e7c-4391-af42-298c6a3b70bd%22%7D&order=DESC&page=1&perPage=25&sort=updated_at
• https://refine.dev/docs/examples/persistQuery/

[mddilley]

Update to keep me on track

I'm focusing on the the filters state defined in useAdvancedSearch first, and I've whittled down the data that needs to be set in the URL params to 3 fields:

• column (field) name like project_team_members (this lets us access config set in PROJECT_LIST_VIEW_FILTERS_CONFIG for each column)
• value like chris
• operator like string_contains_case_insensitive (FiltersCommonOperators is composed of k/v pairs where the key is this operator value and the values are the pieces needed to build the GraphQL query)

I've been able to build the needed query from these three details, and, now, I need to update the logic to set and get the URL params to only rely on the same three. My goal is to demo this in the next dev sync.

I'll keep down this path, and I think a second PR could take on paring down the internal state the Filter component which is called filterParameters. We could follow the same pattern of only storing what is needed to piece together the rest for the UI updates.

[johnclary]

sounds good @mddilley! happy to pair / rubber duck anytime it would be helpful.

[mddilley]

@johnclary I walked through each field and operator to make sure nothing broke, and I tripped over some quirks. I'm dropping notes here for now, but I can help make some issues too if you feel like any of these need attention soon.

• Searching “” (double quote characters) for a string type like Name breaks the UI (WSOD)
• We’ve been better about making sure empty strings are not stored in the database from forms. We still have some lingering code that handles the special cases that not always receiving null from the database created before the fixes.
  • See specialNullValue keys in FilterCommonOperators.js
  • Lead is blank → no results even when removing lead from a project (we are not reliably filtering for projects with no lead)
  • Sponsor is blank → no results even though the is not blank returns less than the total records (we are not reliably filtering for projects with no sponsor)
  • Partners is blank is a good example of one that is working
  • Funding source is blank also works as expected
• When you filter a field with lookup values, if you change the operator after setting the lookup option in the value dropdown, the value resets in the option field. Text inputs do not reset when changing the operator.
• Task orders begins with 24ART21102 works for a project with only that one task order. Using ends with does not work (1 result in staging for begins, 0 results in staging for ends)
  • also ****is 24ART21102**** doesn’t return any results