Add function to inserter to stopTrigger

[john-traas]

Add's a function to the inserterFactory called stopTrigger which the consumer can access via the TextEditor (TriggerFunction) interface.

Fixes: https://github.com/Lundalogik/crm-feature/issues/4474

[github-actions]

Documentation has been published to https://lundalogik.github.io/lime-elements/versions/PR-3305/

[adrianschmidt]

(I know this PR is still WIP, I just happened to see it.)

This change should be part of the first commit, not a separate commit 🤗

[john-traas]

I'll fix that up 🤗

[civing]

Are you okey with the interface @adrianschmidt ?

[adrianschmidt]

Yeah, I've got no problem with it 😄

Maybe it ought to be documented? But it's still @alpha, so not a show-stopper I guess 🙂

[civing]

Within the text-editor in lime-elements, while the popup is open and there is an active trigger, the default behaviour for TAB - ENTER - ARROW_UP - ARROW_DOWN should be prevented.

I think the consumer should handle this cases. I talked to @jgroth and if we configure the event to capture we can prevent certain keyboard events to ever reach the text editor. I will create a PR that updates the example.

[civing]

Within the text-editor in lime-elements, while the popup is open and there is an active trigger, the default behaviour for TAB - ENTER - ARROW_UP - ARROW_DOWN should be prevented.

I think the consumer should handle this cases. I talked to @jgroth and if we configure the event to capture we can prevent certain keyboard events to ever reach the text editor. I will create a PR that updates the example.

You can find an example here. I don't think this PR are needed.

[john-traas]

Within the text-editor in lime-elements, while the popup is open and there is an active trigger, the default behaviour for TAB - ENTER - ARROW_UP - ARROW_DOWN should be prevented.

I think the consumer should handle this cases. I talked to @jgroth and if we configure the event to capture we can prevent certain keyboard events to ever reach the text editor. I will create a PR that updates the example.

You can find an example here. I don't think this PR are needed.

I would still like to add a specific function to stop the trigger that the consumer can access that isn't tied directly to the functionality of creating a mention.

I think it will be useful when handling some keyboard navigation cases such as the user pressing ESC to close the popup without selecting anything.

[civing]

Within the text-editor in lime-elements, while the popup is open and there is an active trigger, the default behaviour for TAB - ENTER - ARROW_UP - ARROW_DOWN should be prevented.

I think the consumer should handle this cases. I talked to @jgroth and if we configure the event to capture we can prevent certain keyboard events to ever reach the text editor. I will create a PR that updates the example.

You can find an example here. I don't think this PR are needed.

I would still like to add a specific function to stop the trigger that the consumer can access that isn't tied directly to the functionality of creating a mention.

I think it will be useful when handling some keyboard navigation cases such as the user pressing ESC to close the popup without selecting anything.

Fully agree!

[civing]

I'm okey with the PR. Just waiting for a go from @adrianschmidt

[adrianschmidt]

External API approved 😊

[lime-opensource]

🎉 This PR is included in version 37.71.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀