Autocomplete appends value instead of label in element

Where does the value end up when this patch is applied? Is it still in $form_state (either userInput or the field value)?

This would be a huge improvement for UI/UX!

I did NOT apply this patch on 8.8. I DID change this one line of code on my 8.7 install.

All this patch does is set the field value in the form to the autocomplete label, and then you lose the actual value entirely. It creates the new problem of not having the value you need (i.e., the id reference for a node, term, entity, etc.,).

Unless something has changed from 8.7 to 8.8 that renders the above moot, this is a regression imo. Otherwise please ignore me.

EDIT: The workaround I've been using is creating a hidden field in the form to store the autocomplete value, with the same key as the autocomplete field and with "_value" appended. The custom selectHandler checks for that form field and fills the value there instead if it's found, and then will insert the label into the actual autocomplete field. It's by no means a foolproof or comprehensive solution, and I feel it could be improved. But it is much much better UI/UX for our user's than what is in core.

// override drupal.autocomplete object with custom functions
  if(typeof Drupal.autocomplete !== "undefined") {
    // use custom customSelectHandler
    Drupal.autocomplete.options.select = customSelectHandler;
  }


  /**
   * Override drupal selectHandler function
   *
   * @param {jQuery.Event} event
   *   The event triggered.
   * @param {object} ui
   *   The jQuery UI settings object.
   *
   * @return {bool}
   *   Returns false to indicate the event status.
   */
  function customSelectHandler(event, ui) {
    var valueField = $(event.target);
    if($('input[name='+event.target.name+'_value'+']').length > 0) {
      valueField = $('input[name='+event.target.name+'_value'+']');
      // update the labels too
      const labels = Drupal.autocomplete.splitValues(event.target.value);
      labels.pop();
      labels.push(ui.item.label);
      event.target.value = labels.join(', ');
    }
    const terms = Drupal.autocomplete.splitValues(valueField.val());
    // Remove the current input.
    terms.pop();
    // Add the selected item.
    terms.push(ui.item.value);

    valueField.val(terms.join(', '));
    // Return false to tell jQuery UI that we've filled in the value already.
    return false;
  }

@joegl see #2174633-360: View output is not used for entityreference options

That's a really long issue thread, and as far as I can tell from reviewing the thread and patch, it's specifically about entity reference fields. It doesn't appear to affect the core implementation of the JQuery UI autocomplete in regards to forms and render arrays in custom modules, which is what this patch affects.

We are not using entity references, views, or entity autocompletes in our custom module. We are using our own routes and matching methods. The code in this patch, which effects the global JQuery UI selectHandler function for Drupal Core, would completely break all our forms with autocomplete's and custom routes, as we would not have the value from the autocomplete available to us anywhere in the form, because the label is being inserted where the value currently is.

Unless I am seriously missing something, I don't see how that specific issue is relevant to the global JQuery Autocomplete implementation. (I am entirely open to being wrong though lol)

Sadly, this problem is "by design" because that's how jQuery UI Autocomplete works: it displays the labels in the autocomplete dropdown and it needs the values in the textfield form element.

The issue referenced by @plach in #3 has an idea for how to overcome this UX annoyance, and #3076171: Provide a new library to replace jQuery UI autocomplete makes it go away completely because Awesomplete inserts the labels into the textfield :)

Closing as a duplicate of #2881892: UX: Hide entity ID in autocomplete widget.

Sadly, this problem is "by design" because that's how jQuery UI Autocomplete works: it displays the labels in the autocomplete dropdown and it needs the values in the textfield form element.

I do not fully agree with this, as you can see from my own example code in this very issue. jQuery UI Autocomplete is flexible enough, it's the drupal core implementation of it that appears to demand the value be placed into the textfield. I believe there is an avenue for holding the value for autocomplete fields elsewhere in the $form_state, possibly a dynamically generated hidden field, instead of in the textfield itself, and then pushing the label into the textfield for UI/UX purpose. As long as the way the autocomplete value is stored is standardized within Drupal forms, there should be a way to implement this with jQuery UI Autocomplete.

I also want to re-open this, as it's separate from #3076171: Provide a new library to replace jQuery UI autocomplete, which explicitly addresses the autocomplete functionality for Drupal entity autocompletes, whereas this issue more generally applies to the current core implementation of the global JQuery UI Autocomplete object, and will affect every single autocomplete field, not just Drupal entity/term/node reference fields.

I was reading the wrong issue. This probably does belong with #3076171: Provide a new library to replace jQuery UI autocomplete. This issue addresses the most specific problem and motivation for that issue though.

currently i am working on it ...

Sounds like this is effectively postponed on #3076171: Provide a new library to replace jQuery UI autocomplete