AkkomaGang/akkoma-fe

Fork 64

WIP: Add regex filter support #427

Draft

norm wants to merge 2 commits from norm/pleroma-fe:regex-mute-filter into develop

norm commented

2024-12-18 04:47:51 +00:00

Contributor

This makes any filter that starts and ends in forward slashes act as a
regex filter instead of a simple substring filter.

Currently doesn't support trailing flags unlike actual JS regexes, so
modifiers should be used instead for that functionality:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Regular_expressions/Modifier

Fixes #273

This makes any filter that starts and ends in forward slashes act as a regex filter instead of a simple substring filter. Currently doesn't support trailing flags unlike actual JS regexes, so modifiers should be used instead for that functionality: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Regular_expressions/Modifier Fixes https://akkoma.dev/AkkomaGang/akkoma-fe/issues/273

norm added 1 commit 2024-12-18 04:47:51 +00:00

Add regex filter support

ci/woodpecker/pr/woodpecker Pipeline was successful

Details

105154a42b

This makes any filter that starts and ends in forward slashes act as a
regex filter instead of a simple substring filter.

Currently doesn't support trailing flags unlike actual JS regexes, so
modifiers should be used instead for that functionality:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Regular_expressions/Modifier

norm commented

2024-12-18 04:49:46 +00:00

Author

Contributor

Noticed one comment in #273 suggests using the ~r/regex/ syntax instead. Don't mind either way, so I'd like thoughts on the syntax or if there should be some other way to denote a regex based filter.

Noticed one comment in https://akkoma.dev/AkkomaGang/akkoma-fe/issues/273 suggests using the `~r/regex/` syntax instead. Don't mind either way, so I'd like thoughts on the syntax or if there should be some other way to denote a regex based filter.

Oneric reviewed 2024-12-18 20:15:54 +00:00

Oneric left a comment

Member

I don’t really mind either syntax, but perhaps one point in favour of ~r/ is it allows trailing flags while still being neraly unabigously intended as a regex just from the front part

Since non-regex mutes are case-insensitive and it’s possible to reënable case sensitivity via modifier, i think it makes sense to let regexes ignore case by default too

Finally, and this will be a bit more effort, recreating regexes for each post is probably not a good idea. It would be good to pre-compile them just once when settings are loaded or the mute list updated

I don’t really mind either syntax, but perhaps one point in favour of `~r/` is it allows trailing flags while still being neraly unabigously intended as a regex just from the front part Since non-regex mutes are case-insensitive and it’s possible to reënable case sensitivity via modifier, i think it makes sense to let regexes ignore case by default too Finally, and this will be a bit more effort, recreating regexes for each post is probably not a good idea. It would be good to pre-compile them just once when settings are loaded or the mute list updated

norm commented

2024-12-18 21:14:00 +00:00

Author

Contributor

One thing I'm having trouble with trying to solve is whether I should keep the raw value of the regexes/words in the config or convert from the parsed version when loading the settings tab.

Just storing the regexes in the muteWords store causes them to apprear like /this/i instead of ~r/this/ when reopening settings.

One thing I'm having trouble with trying to solve is whether I should keep the raw value of the regexes/words in the config or convert from the parsed version when loading the settings tab. Just storing the regexes in the `muteWords` store causes them to apprear like `/this/i` instead of `~r/this/` when reopening settings.

Oneric commented

2024-12-19 00:15:30 +00:00

Member

Since settings are synced to/from the server, i think it’s best for the setting itself to remain as the original textual representation and the parsed version stored outside the synced settings

👍 1

norm added 1 commit 2024-12-19 03:45:50 +00:00

Move regex creation to filtering tab logic

ci/woodpecker/pr/woodpecker Pipeline was successful

Details

ef6f8586c2

norm changed title from ~~Add regex filter support~~ to WIP: Add regex filter support

2024-12-19 03:45:55 +00:00

norm commented

2024-12-19 04:07:04 +00:00

Author

Contributor

Where would be a good place to have a global store of things to not get synced to the server?

Oneric commented

2024-12-21 15:08:05 +00:00

Member

I looked at how the frontend handles stores again and:

the entirety of $store.mergedConfig is passed to the server on Sync, here nothing precompiled can occur.
- values inside mergedConfig are set by setOption dispatches inside the settings module
As an example for adding a new setdisplayBackground dispatch to the users store, you can look at #371

Regexes need to recompiled at least after either new/iniital settings are received from the serve, or the setting was edited in the filtering tab. The current code doesn't account for the former.
To avoid spreading recompile actions over seeral places, it might be best to add a new compiledMuteWords value to the store associated with the status parser. If it’s already set this isused directly, otherwise muteWordHits can compile the config value and cache it to compiledMuteWords.
Then a cache invalidation step can be added to the setOption implementation though i don't know Vue well enough to immediately know whether dispatches work cross-modules/substores or how to otherwise communicate the need for recompile to the status parser (i.e. either setting the compiled version back to undefined or toggling a separate dirty flag)

I looked at how the frontend handles stores again and: - the entirety of `$store.mergedConfig` is passed to the server on Sync, here nothing precompiled can occur. - values inside `mergedConfig` are set by `setOption` dispatches inside the settings module - As an example for adding a new `setdisplayBackground` dispatch to the users store, you can look at #371 Regexes need to recompiled at least after either new/iniital settings are received from the serve, or the setting was edited in the filtering tab. The current code doesn't account for the former. To avoid spreading recompile actions over seeral places, it might be best to add a new `compiledMuteWords` value to the store associated with the status parser. If it’s already set this isused directly, otherwise `muteWordHits` can compile the config value and cache it to `compiledMuteWords`. Then a cache invalidation step can be added to the `setOption` implementation though i don't know Vue well enough to immediately know whether dispatches work cross-modules/substores or how to otherwise communicate the need for recompile to the status parser *(i.e. either setting the compiled version back to `undefined` or toggling a separate dirty flag)*