feat(pat-autosuggest): load more

[thet]

We can tell select2 to batch or not to batch.
If we batch, we can tell select2 how many items it should load per batch.

Please say how you would like to state these options in terms of pat-autosuggest attributes.

The text below is background information by Hannes.

pat-autosuggest currently does not have ajax batching support aka infinite scrolling.
It can only load a fixed number of items and not load more when the user scrolls down the list.

There is some batching support already prepared, but in it's current form this does not work.

This draft PR adds real batching support for ajax requests.
For the batching support to work, the backend also needs to support it, but more on that later.

We added two options to pat-autosuggest:

ajax-batch-size (default: 10) - This defines the number of items which should be loaded from the backend within one request. The default is 10 - this is the same number we currently have hard-coded in this Pattern.

ajax-batch-mode (default: fixed, possible other value: batched) - This defines if the batching/inifinite scrolling should be enabled or not. The default is fixed, which reflects the current behavior. When set to batched it will request more items if the user reaches the end of the selection list.

The logic to determine if more results should be loaded from the server is simple: If the number of items in the result is lower than the batch size no more results will be loaded. If the number is equal to the batch size, the next batch from the server will be requested. If there are no more items an empty list would be returned.

The server needs to support these request parameters for batching support (these are already submitted to the server):

• page (Integer): The page number of the batch. 1 for the first result set, 2 for the second and for forth.
• page_limit (Integer): The batch size. This is the same as the ajax-batch-size parameter.

The server needs to respond with an JSON array of objects with id and text as keys (This is already the case).
If there are no more results, the server needs to return an empty list.

@cornae, please give us feedback on adding this feature in general and the new options and possible naming suggestions in particular.

Ref: syslabcom/scrum#1638

For more information on this see:
https://select2.github.io/select2/#infinite

[thet]

@reinhardt adding your suggestion from the chat in here:

how about on and off as values for something like result-batching? Is that better than true and false?
otherwise we could call it ajax-result-grouping with values single (or full) and batched/batches

[pilz]

I noted on 11.June that @cornae wanted to contact @thet on the specifics of this PR to determine how to name the pattern attributes. Could you do this this week? The timeouts we get are causing repeated helpdesk requests from osha and are getting quite disruptive, so fixing this will have an immediately positive impact on our peace.

[cornae]

Usecases that we want to support with suggested properties design:

No batching, but AJAX (default)

data-pat-auto-suggest="
    ajax-url: https://bla.com/foo.json
  "

Or with an initial batch size that is not 10:

data-pat-auto-suggest="
    ajax-url: https://bla.com/foo.json
    max-initial-size: 20
  "

Batching with arbitrary size

Example for batching enabled with a batch size of 30 and an initial list size of 10:

data-pat-auto-suggest="
    ajax-url: https://bla.com/foo.json;
    ajax-batch-size: 30
  "

Example for batching enabled with a batch size of 20 and an initial list size of 30:

data-pat-auto-suggest="
    ajax-url: https://bla.com/foo.json;
    ajax-batch-size: 20
    max-initial-size: 30
  "

1. The presence of the property ajax-batch-size already indicates that batching is desired, analogue to how the presence of the property ajax-url indicates that AJAXing is desired. ajax-batch-size would be the only extra property needed for now. The default value of this property is 0.

Not for now

2. The property max-initial-size is not required right now, but might likely be required in the future, because tuning initial size and follow-up batch size individually is a common UID best practice to optimise the user experience.
3. The suggested properties design above does not facilitate a use case for having batching on the search result, but no batching on the initial list. I don't see use cases for this at the moment, but they might arise in the future. Should such a use case pop in the future, then extra properties such as ajax-batch-size-search and ajax-batch-size-initial could be added later.

[thet]

@reinhardt ready for review!

[thet]

@reinhardt finally implemented the specs as defined (did not carefully enough read them... :/ )

However, there is one case not covered by the specs - loading all items at once on the first page. Is this a use case we want to support?

Currently the code supports it:

• If you set max-initial-size to 0 all the items will be loaded on the initial page.
• On the other hand ajax-batch-size set to 0 will disable batching and only show the first page.

I think allowing to load all the items from the server at once without defining the max-initial-size to some ridiculous high number could be useful. Maybe a -1 would be better?
@cornae any input on that? If you want, we can discuss that tomorrow or handle it sometime in the future - it's not documented, so this behavior doesn't exist officially.

[cornae]

Yes, I’m available in the afternoon Op 17 dec 2024 om 19:12 heeft Johannes Raggam ***@***.***> het volgende geschreven: @reinhardt finally implemented the specs as defined (did not carefully enough read them... :/ ) However, there is one case not covered by the specs - loading all items at once on the first page. Is this a use case we want to support? Currently the code supports it: If you set max-initial-size to 0 all the items will be loaded on the initial page. On the other hand ajax-batch-size set to 0 will disable batching and only show the first page. I think allowing to load all the items from the server at once without defining the max-initial-size to some ridiculous high number could be useful. Maybe a -1 would be better? @cornae any input on that? If you want, we can discuss that tomorrow or handle it sometime in the future - it's not documented, so this behavior doesn't exist officially. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[reinhardt]

I don't have any strong opinions about any of it. I was just wondering why it was different than described.

That said, it might be a good idea to have a limit on the number of results. The reason we are working on this is, after all, that we got in trouble because there were too many entries.

On the other hand, a max-initial-size equal to 0 is a degenerate case - why would you want to do ajax but not be interested in any results? So I'm also fine with giving it a special meaning. You shouldn't set it to 0 without knowing what you're doing anyway.

[thet]

According to a chat with @cornae we can keep this PR as it is. Also max-initial-size set to 0 and loading all elements, as long this is not documented.
We might improve it further in the future, if needed.