0

Okay so let me be clear about this, I have a user interface where a user can search for products based on their product title, and the way it's built is that you don't need to type the full exact title to get a match. Basically under the hood it uses '$regex' operator on the find method, so if I type /banana/ it retrieves any product that contains on the title the word banana.

The good part of this is that if I type: /^((?!banana).)*$/

It negates it, and returns any product that doesn't contain the word banana.

What I am trying to achieve is giving the negation feature to the user on a more friendly way instead of using the whole regex above.

So I thought about telling the user to use exclamation mark on the start of text and then under the hood replace it by this regex wrapper /^((?!banana).)*$/ . The problem is that I will lose functionality if there is any valid regex that starts by exclamation mark, because I will always be replacing the search tag with the negation wrapper. Does it make sense?

Thank you

TiagoM
  • 3,458
  • 4
  • 42
  • 83
  • 3
    Just provide a way to negate the whole match using `!/regex/.test(str)` – Wiktor Stribiżew Oct 02 '19 at 08:27
  • That actually makes sense, didn't thought about the option of negating outside the regex, thanks – TiagoM Oct 02 '19 at 08:32
  • 1
    You could let the user escape an exclamation mark – with `\!` or `"!foo"`, for example. Or provide a checkbox for negation, or something. There’s nothing perfectly intuitive for this and it seems kind of rare, so as long as you document it, it should be good enough. (But yes, implement it with negation if you can, not `(?!…).*`) – Ry- Oct 02 '19 at 08:33
  • 3
    *"What I am trying to achieve is giving the negation feature to the user on a more friendly way instead of using the whole regex above."* -- why do you ask the user to enter a `regex`, in the first place? Let her enter a string and for negation use a checkbox. Then use the pieces (the text and the status of the checkbox) to create the `regex` behind the scenes, in the code that does the search. This is why it is called "user **interface**". – axiac Oct 02 '19 at 08:39
  • I understand what you are saying @axiac but we are already using operators (>, <, >=, <=, !) on the search field, and the negation feature is already present using exclamation mark for other fields that are smaller like brand for example, that one doesnt use regex, it finds the exclamation mark and replaces it by operator $ne on the find method. Introducing checkbox on this stage would be a nightmare not only in the code but even for the user. Thanks for your input! – TiagoM Oct 02 '19 at 08:44
  • If you already have some search syntax, then...you have some way to parse it. And you should be parsing the search field and producing the search functionality from it - `>` and `<`, etc. are already not valid regex characters to do with comparison if somebody writes, say, `price > 100` you are *hopefully* not generating `/price > 100/.test("some value")`. So, there is still no reason to make the users put in raw regex - just parse the input into one if you want but keep the search syntax for users and the internal one separate. – VLAZ Oct 02 '19 at 08:50
  • `Can a regex expression on javascript be started with an exclamation mark?` - I don't understand why you can't just detect if the user input starts with `!` then wrap it to prevent errors? Unless the user can enter a series of regex related entries, in which case it gets much more complex and you'll have to parse it yourself and translate it to regex (as already suggested). – James Wilkins Oct 03 '19 at 00:23

0 Answers0