Add failing test for custom regex that contains trigger

[mxstbr]

What did you change (functionally and technically)?

I want to add mentions to my input which show @max and also send @max to the server. I thought the custom regexp feature introduced in #255 would help me achieve that, but it only seems to work if the custom regex does not include the trigger.

I would love for this to work, any ideas what the necessary change would be?

[jfschwarz]

The problem is not related to the custom regexp. You seem to confuse the display and id attributes/placeholders. It's important to understand that the data prop passed to the <Mention/> element is used exclusively when the user hits the trigger char and selects a mention.

Parsing the markup value and turning it into the readable plain text value happens without reading from data. You could use the displayTransform in a different way to fix your test:

<MentionsInput
    value="@one and @two"
    markup="@__id__"
    regex={/@(\S+)/g}
    displayTransform={id => data.find(d => d.id === id).display}
>
    <Mention trigger="@" data={data} />
</MentionsInput>

[mxstbr]

In our specific case, id and display are equal. Our data looks like this:

[{
  id: 'brian',
  display: 'brian'
}, {
  id: 'bryn',
  display: 'bryn'
}]

For some reason, the setup in the tests breaks when used in our app. Do you want me to create an isolated reproduction instead of this test?

[jfschwarz]

Do you want me to create an isolated reproduction instead of this test?

Sure. This would be helpful.

[mxstbr]

The latest commit changes the test case to better reflect our production setup. Does that help narrow down the possibilities?

[mxstbr]

You can also see the actual, production code and workaround in withspectrum/spectrum#4588, although I doubt it is helpful without understanding the whole app 😅

[jfschwarz]

Your adjusted test does not fail anymore ;)

[mxstbr]

Okay, here is an isolated reproduction: https://codesandbox.io/s/yk48y80m2x

Note how the suggestions disappear after typing the first character. If I change the markup option to @[__id__] this does not happen anymore.

What am I doing wrong?

[jfschwarz]

Thank you, the repro helped. I got the problem now.

We apply the string matching for the trigger character only on the substring between the caret position and the end of the previous mention. In your case, as soon as the user types the first character after the @ we have a valid mention in the value, so the trigger char string matching then only starts after that markup of that mention. (see: MentionsInput.js#L619 / MentionsInput.js#L631)

It could be an option to simply apply the trigger regexp onto the entire substring from the start of the value to the caret position. 🤔

[mxstbr]

I am not sure I follow entirely as I do not know the codebase at all, so whatever you say is the right idea I can look at implementing if you don't get around to it! 👍

[jfschwarz]

On second thought, using the same value for markup and display purposes comes with some problems (even with the solution I had in mind):

It means, that while typing characters after the @ to filter the suggestions this word would already be treated as a complete mention. Thus, pressing backspace would remove the entire word instead of only the last character of the search string.

The component basically works as a pure function of value and caret position. I'd like to avoid introducing a state for tracking unconfirmed mentions as this would introduce significant complexity. Without this state, there would be no way to distinguish whether we're looking at an unterminated search or an actual, user-confirmed mention. With your current workaround, you effectively have a "lock-in" of mentions on submit, which might actually be the best approach.

Your workaround might still turn unconfirmed mentions into confirmed ones, when we map a value of "@[brian] and @b" to "@brian and @b" on submit and then back to "@[brian] and @[b]". (This could be mitigated by checking if the IDs are valid inside the mapping function.)