Reduce public API surface

Posted a few things in the MR. Working on additional feedback.

Actually, I think we need to remove any option/method until we actually have a use case for it. I also think it will end up being better documented because we can take the time to document and add code examples each method/option when we introduce it.

Adding additional options/methods to the API won't change the major version so it shouldn't be very disruptive to users and since there are already many, many options available it'll be a small work to enable each thing.

this doesn't break the core patch too much, need to get around to make the extra (unsupported) options work for the jquery shim.

working on it alongside the core patch #3076171: Provide a new library to replace jQuery UI autocomplete

I guess it looks good:

Object has 2 things:

destroy()
id
// @deprecated, only for shim purpose
_internal_object

Options supported:

      path
      list
      cardinality
      minChars
      separatorChar
      firstCharacterIgnoreList
      createLiveRegion
      autoFocus
      allowRepeatValues

      minCharAssistiveHint
      inputAssistiveHint
      noResultsAssistiveHint
      moreThanMaxResultsAssistiveHint
      someResultsAssistiveHint
      oneResultAssistiveHint
      highlightedAssistiveHint

The rest is filtered out and can't be set on autocomplete init.

fixed, working a bit on the documentation and adding tests for the supported options

actually tests should be done in #3230678: Write tests

and the docs is in #3211252: Generated Readme

All right it's all about incremental improvements for now :)

How was the list of options supported in #10 decided? I have some questions:

1. I think there would be value in supporting options that allow customizing classes used on elements. They are helpful especially when integrating with a system that is using a pre-existing design system. Am I missing some other way to achieve this?
2. I also think customizing z-index is pretty useful. If we are setting the z-index in the style property like we currently do, I think we should provide an API for changing it too. Overriding style attribute values in CSS is not ideal.
3. Why is the the search delay option removed? Being able to modify that based on API performance can be useful.
4. Is there another way to disable the autocomplete than via the disabled option?

I'm trying a different approach than we're used to in Drupal, which is to not introduce a feature unless someone says: I need this.

The shim is a special case that shouldn't influence the architecture of the library, it's internal Drupal-stuff. So nothing that only the shim need will be explicitly supported.

I agree that classes could be good to have, template support would be even better so people can change everything they need (maybe a dl makes sense for the autocomplete results in some cases), but I want to have the opportunity to discuss this instead of our default stance of "let's get this in it might be useful for someone at some point". Same thing for delay, z-index, etc.

We are trying to make the whole Drupal ecosystem migrate to this library and we can make some guesses on the needs based on what exists in contrib. Wouldn't it be enough to justify a feature if there are multiple examples in the contrib eco system where a feature is needed?

I'm afraid that if we make it too difficult to upgrade to this library, people will choose to continue using jQuery UI which is not safe. Ideally, people would come and tell what is missing from the library for them to upgrade, but I'm not sure that's how it works in practice, especially when there's the option to revert back to jQuery UI.

If what you mean is that we find examples, and have a quick conversation with folks about their need sure. Let's not assume what their needs are based on a specific implementation. We don't know the tradeoffs they made to their initial needs because of limitations/biais in the implementation.

It's going to take work but it's the price for making something better than what exists currently. Otherwise we're just rewriting existing code and keeping the same biais and asking people to make the same tradeoffs again. If that's what we do, I'd rather just maintain jQuery UI and not think about this too much.