Autocomplete issue when insert template has markup about tribute HOT 11 CLOSED

from tribute.

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.

from tribute.

@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.

from tribute.

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.

from tribute.

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

from tribute.

@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

from tribute.

@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.

from tribute.

@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?

from tribute.

@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!

from tribute.

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

from tribute.

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

from tribute.