Open nilshoerrmann opened 10 months ago
Actually, I think if data is coming from an API, suggestions should the fetched just in time when the user searches. So in our case the filter dialog would best be until the user starts typing the first letters to reduce the amount of options that needs to be displayed.
Maybe – for backwards compatibility reasons – this could be handled with a new type that dynamically provides the filter value:
icons:
label: Icons
type: tags
options:
type: live
url: '{{ site.url }}/icons?query={{ filter.value }}'
text: '{{ item.name }}'
value: '{{ item.name }}'
I am totally on board with the usefulness. But it's also not trivial as we would need to introduce two different architectures (preloaded, only loaded on the fly). Which is quite the overhead.
I think it's more realistic to refactor the fields in the midterm run to always only lazy-load their options.
Description
When loading options for a tags field from an API, all options are fetched on page load causing the panel to freeze if the received data is huge. My guess is the same applies to other fields with options (select, multiselect …).
Expected behavior
Dynamic options should only be loaded when the filter dialog is opened for the first time.
To reproduce
We are returning a list of icons from our assets folder via a custom route:
And are using this route as API endpoint for a tags field:
Your setup
Kirby Version
Kirby 4