Autocomplete issue when insert template has markup

[dgrubelic]

As you will be able to see from the last image, i'm using div with contenteditable="true".

First you need to setup selectTemplate to look something like this:

{
   selectTemplate: function (item) {
      return '<span class="handle">' + item.original.username + '</span>';
   },

   values: [
      { name: 'Allen Iverson', username: 'alleniverson' },
      { name: 'Basketball HOF', username: 'Hoophall' }
   ]
}

.editor { color: #000; } 
.handle { color: #1b95e0; }

How can we reproduce this bug?

1. Start mentioning "Basketball HOF"
2. Mention someone
3. "Backspace" delete handle to look like this: @hooph
4. You see autocomplete list again, hit enter to mention @Hoophall again
5. Continue typing

What did you expect to happen?
I expected to have text with black colour again. (see image)

What happened instead?
I got all text blue. (see result image and markup)

[dgrubelic]

You can preview the problem here: https://plnkr.co/edit/AV1ru1uYDbttp5mx62SF?p=preview

Just open file script.jsand:

1. Uncomment line 13.
2. Comment line 14.

[mrsweaters]

Ah interesting, one quick workaround for this while I look into some potential solutions is to set contenteditable="false" on your element.

{
   selectTemplate: function (item) {
      return '<span class="handle" contenteditable="false">' + item.original.username + '</span>';
   },

   values: [
      { name: 'Allen Iverson', username: 'alleniverson' },
      { name: 'Basketball HOF', username: 'Hoophall' }
   ]
}

The side effect is that the entire node gets deleted, but there is no way to corrupt the markup. Let me know if this works for you.

[dgrubelic]

This is not a solution for me since it introduces a bed UX pattern for users. Sorry... :)

[achambers]

@mrsweaters What’s the status of this bug? I’ve come across it also. You can end up with an fully nested element if you keep editing the mention which is totally undesirable.

Is there any love being given to this issue?

Where might one start to look in order to patch this? Il happy to do so myself if you could give me a steer

[mrsweaters]

@achambers This is still an issue unfortunately. This will involve making delete more aware of the selection context on backspace/delete and tribute aware of whether or not your selection is part of a matched node.
https://github.com/zurb/tribute/blob/master/src/TributeEvents.js#L220

• We need to know if we are in an already matched node so that we don't accidentally nest matches.
• When you backspace and start typing again and then select a match, it should fill in the match and then jump out of the current element and insert the caret after.
• If there is no match and you continue typing, and you are in the context of a selectTemplate node, we should move you out of the node.

I think that covers most of the edge cases.

[achambers]

@mrsweaters Yep, that pretty much sums up my take on it. So, my question to you now is in what capacity are you using this lib? This seems like a pretty fundamental bug where you can’t edit a mention without considerable unwanted DOM.

I’m only asking as I’m building mention capabilities in to my app and have started out with at.js which doesn’t fill me with confidence. I came across Tribute and started spiking it out to see if it will fit our needs. It definitely fills me with more confidence than at.js does and fixes a few of the bugs I’ve seen with it but also feels potentially like it is missing a couple of fundamental concepts like this one.

Is it fair to say Tribute is early stage and not yet used in Production in anger?

Please don’t get me wrong, I’ve got a much better feeling about Tribute than at.js but am trying to weigh up perusing with Tribute and potentially putting my time in to helping get it where I need it to be, or rolling my own.

Could you give me some context?

[mrsweaters]

@achambers The landscape was pretty bleak when I was looking for a solution. We are using this in production but under a very restricted use case; we match IDs similar to Github issue references. We have no plans of abandoning this project.

I have been looking for someone to help maintain the library as the needs of the project currently outweigh my available time. If you are interested in contributing, that would be great.

[achambers]

The landscape is indeed bleak by the looks of it ;) My time is also in short supply but I’ll take a look this week and if I can easily contribute a few things that are mutually beneficial then I will indeed. Going to dedicate tomorrow to diving in a bit deeper so you’ll hear from me soon no doubt.

…

On Mon, 20 Nov 2017 at 19:47, Jordan Humphreys ***@***.***> wrote: @achambers <https://github.com/achambers> The landscape was pretty bleak when I was looking for a solution. We are using this in production but under a very restricted use case; we match IDs similar to Github issue references. We have no plans of abandoning this project. I have been looking for someone to help maintain the library as the needs of the project currently outweigh my available time. If you are interested in contributing, that would be great. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#33 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAZb1DemkeJbdp16PAKhKQ41Ms5ZNXrdks5s4ddsgaJpZM4KEs6o> .

[mrsweaters]

@achambers Just checking in. Were you able to take a look at improving the backspace functionality? Let me know if you hit any roadblocks or where I could help!

[achambers]

Mate, I never had the chance to further explore Tribute due to time constraints unfortunately.

[mrsweaters]

Closing as this is pretty old. Thank you for your help!