Some of the old behavior is kept, but that may actually make things a bit weird in terms of behavior, so I could use @Pginer-WMF and @jmatazzoni's input here:

The filters that we're "not touching" from the current RC page, for example the "Namespace", the "Tags" and the pagination, all refresh the page. This doesn't really work for what we're doing with the filter drop-down that doesn't refresh the page, but rather pulls information from the API and refreshes only the list itself (not a hard-refresh of the entire page)

This means one of two options:

1. (Probably prefered) We intercept the actions on those inputs, either by replacing them outright with OOUI elements or by (meh) grabbing their DOM elements and interrupting the currently setup event to refresh the actual page.
2. We leave the behavior as-is, which means some filters refresh the page and some don't.

I think #1 is prefered, but it also means that if we put those filters outside so we "don't touch them" then it defies the point. We will have to do something there anyways, and being outside the main UI makes them more of a 'hack' than an actual system to listen to. Do we want to keep that? Do we want to replace them with OOUI widgets? Is the design the same?

We can also decide we are using JavaScript for some of the filters and not others (allowing others to refresh the page with the URL that defines the other filters?) but then we'd have to decide which ones follow which behavior. For example, I think it would make more sense to have the pagination completely through JavaScript, but perhaps the "Show new changes starting from..." could be non-JS in the MVP, and turned JS only later.

Ideally, the entire page will use filters that aren't refreshed, but if we take them out of the main filter list, we need to understand their behavior more so the architecture of the code works. Are they "rigid" (do we allow adding filters to that area of the search, like we will in the filter drop down? that's something the current behavior allows, but it also makes things more complicated for other extensions and coders to "pick" where to put filters)

So if all filters are inside the filter drop down, we know that the code just pulls in the data and arranges it in there. If we split them up, we need to make a determination about which filters appear where. There are, currently, other extensions that add filters to RecentChanges (like Wikidata and ORES, most notably) -- do we assume any extension adding filters should format them for the drop down, or do we have another area of the page - under "namespace" and "tags" where they can attach themselves to - and if they do, do they refresh the page or do we define an AJAX way to do it?

Let me know if any of these questions need clarification.

Just for organization sake, these are the three filters added in production by extensions:
'hideWikibase' (added by Wikidata), 'hideReviewed' (added by FlaggedRevs) and 'hidenondamaging' (added by ORES)

We are going to replace the ORES one, but we have to take into account that other extensions are adding filters through hooks. We don't have to use the same hook for the new JS feature, necessarily, since we will also probably have to redo the way these filters are defined if they appear in the filter (like definition of i18n messages and such) -- but we definitely need to be aware that (a) they exist and (b) we allow external extensions to add whatever filter they need to the list of filters.

We could leave a section outside the drop-down filter for those filters, and they could just refresh the page when selected (current behavior) but we need to figure out how to let extension developers define where they go.

For example - the code may live, right now, in ORES, but the feature is potentially ORES-independent (and will work eventually in the future for wikis that don't have ORES enabled, giving them the other base filters) -- that means that ORES will ahve to add its filters to the drop-down, and not the box outside the drop down. We can do that by defining some variable for filters noting whether they're inside or outside of the filter (similar to 'prioritized' in Notifications?)

Whichever we do we need to make a decision on what we support.

Change 319251 had a related patch set uploaded (by Mooeypoo):
[wip] RecentChanges Dynamic Filters

https://gerrit.wikimedia.org/r/319251

Thanks for your input @Mooeypoo, here are some considerations in this area that may be helpful:

• New filters should be reflected in the URL. That allows vandal fighters to bookmark a filter targeting "damaging edits by unregistered users" or the Teahouse to craft a link pointing to a filtered Recent Changes showing "newcomers acting in good-faith making bad edits". I guess this can be captured as a hash parameter if we want to manipulate on the client side, which may make it possible to update the existing link-based filters to include the current state too. In any case, the idea is that the user should not lose the state when clicking the "refresh" button, clicking to an external link and going back, or clicking in another filter.
• There are two kinds of existing filters. Pagination and date selection are based on links. If we consider replacing these by OOUI components it would be better to replace them with a dropdown as illustrated in the prototype. Namespace and Tag selection, are based on a form submission so we may include additional information as part of the form. For namespaces and tags, our long term goal is to integrate those in the new filtering entry point but we still have some aspects to figure out.
• New filters are extensible The idea for the new filter system is to be scalable. Extensions should be able to indicate filters by providing the needed information about the group (name and possible help link) and the filters (name, description and info on incompatibilities between filters in the group). We probably need to define what to do with the extensions that provide filter extensions with the old format.

Are those helpful to inform the technical decisions? Is there any other detail that may help?

Change 320332 had a related patch set uploaded (by Mooeypoo):
[super-atomic-WIP] Adding filters to RecentChanges

https://gerrit.wikimedia.org/r/320332

Change 326064 had a related patch set uploaded (by Mooeypoo):
[wip] RCFilters UI: Read preferences as base state

https://gerrit.wikimedia.org/r/326064

Change 326208 had a related patch set uploaded (by Mooeypoo):
RCFilters UI: Add 'remove' and 'restore defaults' to filter list

https://gerrit.wikimedia.org/r/326208

Change 320332 merged by jenkins-bot:
Adding new interface for review filters to RecentChanges

https://gerrit.wikimedia.org/r/320332

Change 319251 abandoned by Mooeypoo:
[wip] RecentChanges Dynamic Filters

Reason:
Unnecessary experiment, overriden in other commits.

https://gerrit.wikimedia.org/r/319251

Change 326064 merged by jenkins-bot:
RCFilters UI: Read default states of filters

https://gerrit.wikimedia.org/r/326064

Change 326208 merged by jenkins-bot:
RCFilters UI: Add 'remove' and 'restore defaults' to filter list

https://gerrit.wikimedia.org/r/326208

@Pginer-WMF - just a side not (feel free to ignore). Your initial design, that you mention in view current prototype, places the filter feature right above the results which makes easier (in my opinion) for users to see that the filters give them the results they want.

Of course, since we keep many RC old options, the RC page' look is different for now, but it still look cleaner when the filters are placed right above the result set. The 'Recent changes options' area is quite large and it's challenging to constantly switch the attention (and move eyes) from results to filters and vice versa.

The screenshot illustrates the case when the filters are above the result set.

In T144448#3023150, @Etonkovidova wrote:

@Pginer-WMF - just a side not (feel free to ignore). Your initial design, that you mention in view current prototype, places the filter feature right above the results which makes easier (in my opinion) for users to see that the filters give them the results they want.

Ideally we want to have a single filter area and not two of them. In the long term, the idea is to integrate more of the old filters into the new system, making it more lightweight and connected to the list of results. In the short term, removing the borders around the old filter area to make it look more unified would help.

We generally don't put these epic tracking tasks on the quarterly board. Moving it back to Triage.

In T144448#2760907, @Mooeypoo wrote:

Just for organization sake, these are the three filters added in production by extensions:
'hideWikibase' (added by Wikidata), 'hideReviewed' (added by FlaggedRevs) and 'hidenondamaging' (added by ORES)

Have we solved the question concerning "hideReviewed"? I have a question about it here.