I am currently building Reactive web app and have noticed some odd performance behaviour when using the Dropdown Search widget.
The app consists of 2 screens and Ive replicated the issue on both.
1 List screen with filter using Client Variables to store the filter details. The filter inputs includes a button group, text inputs and dropdowns with 1000s of records each (Like Employee). This works well, typing is quick on the input fields and switching between the button group options is also quick. The buttons for filtering the data and resetting the client variables also work well.
However when I changed the Dropdown widgets to Dropdown Search widgets Ive noticed that although the Dropdown Searches work well, typing into the Text inputs is very slow as is swapping between options on button group. Resetting the filters also takes a ~10 seconds.
2 Job Detail screen, using a form with about a dozen different inputs. Similarly to the Filter the form is made up of button groups, text inputs and dropdowns with 1000s of records each (like Employee). obviously the UX is poor when the dropdown lists are so long. I changed these to use the Dropdown Search widgets, which work well, but the rest of the form becomes less responsive as a result.
I have reverted the filter and the form to use normal Dropdown widgets which has restored the performance of the screens.
I wonder if anyone else has experienced similar issues, or if theres anything I can do to resolve these issues.
Christopher Kennedy wrote:
Hi Christopher its possible to upload the oml?
I was doing a POC last week testing the performance of search and I have a search input, 2 dropdowns search, date range it's working well and fast
if you cant upload the oml try to replicate the screen with information that you can share
Best regards
Carlos Lessa
Carlos Lessa wrote:
Hello Carlos, I shall try to replicate it using the outsystems sample data, but would it be possible for you to share the oml file of the dropdown searches working, to see if i can spot any differences. I might be setting up the "selected value" incorrectly.
Hopefully have something for you by the end of the day!
Chris
I have done a bit of testing today.
I created a very similar page (attached), using the Outsystems Sample data.
Used a filter, and the same number of Client variables, with the same configuration of dropdown search widgets and other inputs. I had no issue with responsiveness of any of the fields here.
The Sample_Employees entity only contains ~65 records, where as in my app the Employee entity has ~1800. When I set the "Max records" of the attributes to 100 it gets better. However I have tested the amount of time it takes to finish loading all the aggregates for the filter and it doesnt appear to be the source of the slow down.
The weird thing is that the "slowness" isnt on the dropdown search field, as it works as expected. It seems to happen when a selection is made, or when typing into the normal text inputs or the "Active" button group or even the filter/reset button behaviour where Client Variables are set to Nullidentifier.
However if I go back to using just the regular DropDown widgets, same amount of data loaded in the aggregates and the same utilisation of client variables etc there is no issue.
I suspect it may be a bit of how the dropdownsearch widgets use the data or how they work on the page?
Hi Christopher, I didn't have enough time to check your oml but my first thoughts are:
Hope I could help you
Carlos,
The oml file I gave seemed to work fine, but the sample data (Sample_Employees, Sample_Request) only has 65 records max in each. I have included it because it is essentially the same set up as I have in my use case, however it does mirror how I have set up the filter etc.
The aggregate for the data is not refreshed until the "Filter" or "Reset" buttons are pressed, therefore entering text to the text inputs, or Selecting options in the dropdown are not filtering the data, only when the Button is pressed does it do it. The only thing that is happening when filling in the filter fields is setting the Client Variables.
I did manage to restore performance when I stopped using the Client Variables and instead used local variables for the screen.
In my use case I have also attempted to use the Dropdown Search widgets for the Form in the Details Screen. This also causes the form to be very unresponsive, even when only using one dropdown search widget. I even have the Dropdown search widget updating a local variable and it still causes the rest of the form to perform poorly.
After all the testing it seems like these Dropdown Search widgets shouldnt be used for Lists of anything more than 100 records, which in my opinion, limits their use.
I am still stuck looking for "input autocomplete" functionality like there is in Traditional Web.
Thanks for your help
Something I have somewhat stumbled upon with the Dropdown Search widget is to use a separate variable as the "selected Item"
So in the details screen where I use the Dropdown Searches, I use a separate variable instead of setting the selected item to the source of the form (eg for an employee form use "Employeeselecteditem" instead of "getEmployees.List.Current.Employee.FirstName")
I have done this on the List screen, which was using the client variable as the selected item.
Seems to have resolved the issue. Thanks for your help and time on the matter.