Params and range params

paramsAndRange.js

// GraphQL Schema with regards to applied filters : 
//     appliedFilters{
//       name
//       rank
//       values{
//         displayName
//         urlLabel
//         code
//         count
//       }
//     }


// example of current way query builder outputs range params : 
const current = [
    {
        "name": "creator",
        "rank": 1,
        "values": [
            {
                "displayName": "Carl Auböck",
                "urlLabel": "carl-aubock",
                "count": 403
            }
        ]
    },
    {
        "name": "price",
        "rank": 2,
        "values": [
            {
                "displayName": "price",
                "urlLabel": "[44 TO 3142]",
                "count": null
            }
        ]
    }
];

// Kostas' proposal : 
const proposal = [
    {
        "name": "creator",
        "rank": 1,
        "values": [
            {
                "displayName": "Carl Auböck",
                "urlLabel": "carl-aubock",
                "count": 403
            }
        ]
    },
    {
        "name": "price",
        "rank": 2,
        "values": [
            {
                "displayName": "min",
                "urlLabel": "44",
                "count": null
            }, 
            {
                "displayName": "max",
                "urlLabel": "3142",
                "count": null
            }
        ]
    }
];


/* 
Which direction should we take? I would argue that we should stick with the way this currently works. 

Things to consider : 
- currently we have a data structure that supports multiple filter values per filter, where each filter value has a display name, url-label, count, and optionally a code
- Kostas' proposal would have us split each range param into 2 filter values, each with a display name of min or max, and a URL label of the individual number
- I would argue that the proper URL label is the full param we pass to the service - ie. [x TO y] 
- this keeps things consistent with how other filters work - namely that the 'url-label' is the string value we put into the URL bar

Upsides to considering this as 2 separate values for the price filter : 
- setting a value can be done individually from the client - ie. when a user enters a min value in an input box / slider, etc, we simply apply the min filter

Downsides to considering this is 2 separate values for price filter : 
- GraphQl has to have an understanding of all range queries and break up [x TO y] into 2 structured filters
- query builder has to do the same thing, and any other pieces of infrastructure must have the same logic.

Downsides to considering it as 1 value : 
- we have to write a little helper to apply range values that puts the brackets and delimiter (TO) around the min / max values
- any other clients that use graphQL search browse will have to do the same thing.

Upsides to 1 value : 
- more consistent API with clearer meaning of displayName and url-label
- less work overall, even though Kostas already did a lot of it - we barely have to modify link builder, graphql, and query builder
- less chance of messing up a range query if there we don't have to mess around with min / max and combining / separating those filter values

Other notes : 
- either way we have to account for the fact that ranges aren't multi select like other filters
- ie. when applying the value, we must remove older entered values first. ie. there can only be one price filter of [x TO y] at once, multiple don't make sense
- the current way we have this, the displayName doesn't make much sense. For example with the current price range the displayName is "price" 
- I suggest we change the displayName for rangest to formatted nulbers like "1 - 1,000"
*/