The RCFilters URL represent the state of the system, including highlight states. It's already quite big, but the more filters and features we add, the bigger it gets.
Beyond the issue of having super long URLs that are annoying to copy/paste, having such long URLs is wasteful and is hard to debug.
However, there are a couple of challenges with the URL that must be overcome:
- The URL represents the state; we can't have it be ambiguous.
- Different users should be able to share URLs and get the exact same result, regardless of what they have in their default settings.
Up until now, we took the above two points to say that the URL should always be complete and represent everything, so even things like "param=0" can override a "param=1" that user B has in their defaults.
But the URL is getting pretty big, and there shouldn't be a need for it. I've come up with an idea to fix this problem, but it carries a couple of technical and product implications that should be hashed out.
The provided patch gets rid of all parameters that are set to either empty or 0. Instead, we store an object representing the empty state of all parameters, and the model receives a merging between the URL and the empty state -- hence, it receives everything. Before we push the state to the URL, we once again remove anything that equals 0 or is empty.
This means a few things:
- On load, the system evaluates the URL and decides whether there are any relevant parameters. If there are, it loads the state from the URL. If there aren't, it applies defaults.
- Potential issue: If the url has ?highlight=1 then you get an empty filter set with highlight enabled. Do we ignore highlight/nsinvert for the purpose of checking whether valid parameters exist in the URL, or is this an acceptable outcome?
- If I have defaults, whether they come from my wiki settings or a default saved query, the URL will adjust itself to present them. This means I can load RecentChanges, have the URL normalize automatically so I can copy/paste that URL to give to someone else and they see the same.
- Note: Got rid of merging defaults everywhere. Default state should be loaded in initialization (if valid) or on user request. Otherwise, it should not be inserted into anything.
- URLs may look confusing to users, because of the way the filters work. If you only selected "Page edits" for example, the URL will change to show "hidenewpages=1&hidecategorization=1&hideWikibase=1&hidelog=1" (all the others in the group as 'hide' true) -- this isn't really a blocker, but we need to be aware of that.
- There is no way to get an empty filter set unless you enable 'highlight' (and even that may change, depending on bullet #1) -- is that okay? You can still remove all filters with the trash can, but if you load an empty URL it will prefill with defaults, so you can't load a URL that will give you an empty filter set as default.
We should make sure that all scenarios of ambiguity are solved or are known. Are the above issues okay, or should be fixed, etc.
Proposed fix attached below. It's marked as 'wip' so it doesn't get merged before at least solving bullet #1 and #4.