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:

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. 

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:

Christopher Kennedy wrote:

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. 

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



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?

Christopher Kennedy wrote:

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:

  • In my PC and net its working fine but I know isn't the proper db that you are using
  • Do you really need a 2 web block, filter and list? if not, remove it, put everything together and remove client variables(not sure here but the client variable is in the place of session variables and session update db in every request, not sure about client) and add local variable filtering direct the getRequest, this way you avoid to call event every time you need to filter
  • GetEmployees table: 
    • you have a 5000 max record and no filter, using in 3 dropdown search, reduce to 50 or even less, add a filter to search the table according to your typing, add logic to search just after 3 chars, just return the attribute you need(id, first name, last name)
  • GetRequest:
    • you have twice this filter: Client.Request_PriorityId = NullIdentifier() or Sample_Request.Priority = Client.Request_PriorityId
    • you may try to remove the first wildcard from the search keywords: Sample_Request.RequestName like "%" + Client.Request_Keyword to Sample_Request.RequestName like Client.Request_Keyword, this will reduce the time of search but you need to know the beginning of the search of will fail, eg: search word = red Audi, if the search is "red" you will find "red audi", but if you search is "audi" you will not find the record, there are pros and cons with this kind of search
  • Last but not least, index the fields you need to search, you will notice a huge improvement on the search


Hope I could help you

Best regards

Carlos Lessa


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. 

  • The reason I put the filter in a WB was so I could easily swap out the filter for one not using the Dropdown Searches. It also allows me to use that filter on another page (like Dashboard where same filter applies). I have put everything together like you suggested, issue persists. 
  • I know you didnt have much time to look at the oml, but not sure what you mean by the employees table. In the oml the GetEmployees aggregate is used to provide a list for the Dropdown Search widget. Isnt the point of the Dropdown Search that it will filter the list based on what I have typed? I couldnt find another event to add any filtering logic to the GetEmployees aggregate. This however doesnt seem to be an issue for normal Dropdown widgets, they just produce a very long list but performance is still good. In my use case I have set the max records of the aggregate which supplies the table to be 10 to keep the possibility of that causing the issues to a minimum.
  • In my use case, All entities have indexing set up for all foreign keys and also for Label and IsActive as these are most searched for. 

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

Chris


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.