Refactor frontend filter logic so it's unified in one place.
As of #626 the concept of "what a filter is" is spread across multiple places:
getComparisonForFilter()
ListingFilterState
FrontendListingFilterStateKeys
ListingFilterKeys
the encode/decode methods
the various enums with options for the filters
To reduce the chance of hard-to-debug issues, we should refactor this logic into a ListingFilterStateManager class that can hold all this in one place.
It could an internal list of filters and their states, and have methods like
getBackendFilterArray()
getFrontendFilterQuerystring()
a constructor that takes a frontend querystring as the parameter
a constructor that returns a blank set of filters
Work toward this was completed by @elenm in #484, but was set aside so complexity around the interaction between the seniorHousing and communityType filters could be resolved independently.
Refactor frontend filter logic so it's unified in one place.
As of #626 the concept of "what a filter is" is spread across multiple places:
To reduce the chance of hard-to-debug issues, we should refactor this logic into a ListingFilterStateManager class that can hold all this in one place.
It could an internal list of filters and their states, and have methods like
getBackendFilterArray()
getFrontendFilterQuerystring()
Work toward this was completed by @elenm in #484, but was set aside so complexity around the interaction between the seniorHousing and communityType filters could be resolved independently.