documentationfor yFiles for HTML 2.6

Adding and Editing Labels

GraphEditorInputMode supports interactively adding and editing labels. The most prominent options to control label editing are presented in the Adding and Editing Labels section. You can further customize the process of adding or editing labels by overriding the shouldAddLabel and shouldEditLabel methods. For example, you could disallow adding or editing specific labels under certain circumstances. The following example shows how to ensure that label owners have no more than a single label by restricting adding labels appropriately:

/**
 * @param {!ILabelOwner} item
 * @returns {boolean}
 */
shouldAddLabel(item) {
  // the item is an ILabelOwner
  const owner = item
  // don't allow more than one label
  return owner.labels.size < 1
}
shouldAddLabel(item: ILabelOwner): boolean {
  // the item is an ILabelOwner
  const owner = item
  // don't allow more than one label
  return owner.labels.size < 1
}

Furthermore, you can use the following two events to achieve very similar results to overriding the above methods:

Customization events related to label adding and editing
Event Occurs when …​
LabelAdding…​ a label is about to be added.
LabelEditing…​ a label is about to be edited.

They allow you to change the label editing process completely by calling appropriate methods on their event argument. That argument, a LabelEditingEventArgs instance, offers various properties to customize editing labels. For example, to achieve the same result as the overloaded shouldAddLabel method above, you can also use the following event listener:

graphEditorInputMode.addLabelAddingListener((source, args) => {
  if (args.owner && args.owner.labels.size >= 1) {
    args.cancel = true
  }
})

Apart from the cancel property you can also set a different style, label layout parameter, or even redirect the editing process to a completely different label.

GraphEditorInputMode offers a number of other events that allow you to react to certain stages in label editing:

Related events
Event Occurs when …​
LabelAdded…​ a label has been added.
LabelTextEditingStarted…​ the text editor is about to be opened for adding or editing a label.
LabelTextChanged…​ a label has been edited successfully.
LabelTextEditingCanceled…​ text editing has been canceled.
ValidateLabelText…​ text editing has been committed (usually by pressing Enter ↵). You can use this event to validate the text to apply to the new or edited label. You can set the cancel property to true to prevent setting an invalid label text. This results either in a new label not being added, or an existing label not changing its text. You can also change the text to a different value to implement validation that does not reject new values, but rewrites them.

The LabelAdding and LabelEditing events offer quick and easy customization for all items. To change behavior only for certain label owners or labels, you can also decorate the lookup with a custom implementation of IEditLabelHelper. This interface defines two callback methods that are functionally identical to the LabelAdding and LabelEditing events on GraphEditorInputMode.

While the overall process of adding and editing labels is handled by GraphEditorInputMode, the actual text editor is managed by TextEditorInputMode.

Most prominently, TextEditorInputMode displays a div element containing a textarea which you can obtain from its editorContainer property and customize as necessary. For example, you can implement custom validation code that rejects typed characters during editing (as opposed to the GraphEditorInputMode.ValidateLabelText event which can only reject a label text after the user pressed Enter ↵) by adding a suitable keypress to the container:

Customizing label editing by only allowing numeric input
const editorContainer = graphEditorInputMode.textEditorInputMode.editorContainer
editorContainer.addEventListener('keypress', (e) => {
  if (e.keyCode >= 48 && e.keyCode <= 57) {
    // prevent numeric input
    e.preventDefault()
  }
})

TextEditorInputMode also provides a number of events to listen to:

Related events
Event Occurs when …​
EditingStarted…​ editing starts, but before the text area is displayed.
EditingCanceled…​ editing has been canceled.
TextEdited…​ label editing has stopped, before the text area is hidden.

The LabelEditingEventArgs used in GraphEditorInputMode’s LabelAdding and LabelEditing events as well as IEditLabelHelper’s methods provides the textEditorInputModeConfigurator property which you can use to configure the TextEditorInputMode for a given label.

CSS Transition or Animation for the Input Element

The text input element has different CSS classes during entering or leaving the DOM with which CSS transitions or animations can be defined.

The transition or animation can be disabled separately by not defining any of the related CSS classes which are explained in the following sections.

Enter Phase

The following CSS classes are present when the input element is added to the DOM:

  • yfiles-labeleditbox-container-entering This CSS class is present during the entire enter phase and can be used to define CSS transition or animation functions. It is removed when the enter transition or animation ends.
  • yfiles-labeleditbox-container-enter Initializes the start state of the input element. The class is added before the element is inserted in the DOM and removed just after the element was added to the DOM.
  • yfiles-labeleditbox-container-enter-to Defines the end state of the input element. This class is added when yfiles-labeleditbox-container-enter is removed, i.e. just after the element entered the DOM, and it is removed when the CSS transition or animation ends.

By default, yFiles comes with a simple fade transition for the enter phase of the input element:

.yfiles-labeleditbox-container-enter {
   opacity: 0;
 }
.yfiles-labeleditbox-container-enter-to {
  opacity: 1;
}
.yfiles-labeleditbox-container-entering {
  transition: opacity 0.1s ease-in;
}

Alternatively, you could also define a CSS animation, e.g.

@keyframes fade {
  from { opacity: 0 }
  to { opacity: 1 }
}
.yfiles-labeleditbox-container-entering {
  animation: fade 0.1s ease-in;
}

Leave Phase

The following CSS are present when the input element leaves the DOM:

  • yfiles-labeleditbox-container-leaving This CSS class is present during the entire leave phase and can be used to define CSS transition or animation functions. It is removed when the enter transition or animation ends.
  • yfiles-labeleditbox-container-leave Initializes the beginning of the leave state of the input element. The class is added when the leave phase begins and is removed just a frame later, when yfiles-labeleditbox-container-leave-to is set.
  • yfiles-labeleditbox-container-leave-to Defines the end state of the input element before it is removed from the DOM eventually. This class is added when yfiles-labeleditbox-container-leave is removed and it is removed when the CSS transition or animation ends. The transitionend or animationend event also defines when the element is removed from the DOM.

By default, yFiles comes with a simple fade transition for the leave phase of the input element:

.yfiles-labeleditbox-container-leave {
  opacity: 1;
}
.yfiles-labeleditbox-container-leave-to {
  opacity: 0;
}
.yfiles-labeleditbox-container-leaving {
  transition: opacity 0.1s ease-out;
}

Alternatively, you could also define a CSS animation, e.g.

.yfiles-labeleditbox-container-leaving {
  animation: fade reverse 0.1s ease-out;
}