Populate values in drop downs based on previous user selections

@komalc I don't think there is a need to worry about the performance. Though you might have 10 dropdowns, every time you interact with a dropdown you will be invoking one query rule and resetting the other dropdowns to null values. That is if you consider dropdown 1, its saveInto consists of modifying the second dropdown data(choiceLables, choiceValues) by invoking a query rule,resetting its 'value' and resetting the rest of the 8 (3,4,5,6,7,8,9,10) dropdowns(choiceLables, choiceValues, and their associated values). If you consider dropdown 2, its saveInto consists of modifying the third dropdown data(choiceLables, choiceValues) by invoking a query rule,resetting its 'value' and resetting the rest of the 7(4,5,6,7,8,9,10) dropdowns (choiceLables, choiceValues, and their associated values) and this goes on and on. Simply speaking at a time, you will invoke only one query as per the scenario you have described. If you take some care while coding, such as avoiding with(), effectively using saveInto so that queries will be made on-demand, getting only two columns(identifiers for choiceValues and text values for choiceLabels) using query entity etc, I think that should be fine.

I might be missing something but above are my thoughts are at the moment on the traditional approach from the performance perspective and let's see what other says about it.

Another approach you can give thoughts about is, build an entity (either a table or view) in the database which consists of all the possible combinations. When it comes to interface, provide the search criteria on the desired columns and get a minimal number of records(maybe 10 or 20 at a time) at a time and query the data afresh only when the user paginates. This also has an upper hand over traditional approach as there is a possibility of exploring many combinations without actually need to working through all the dropdowns in a cascading manner.

If I am not wrong, in your case, it may be more about flexibility rather than performance.

@komalc I don't think there is a need to worry about the performance. Though you might have 10 dropdowns, every time you interact with a dropdown you will be invoking one query rule and resetting the other dropdowns to null values. That is if you consider dropdown 1, its saveInto consists of modifying the second dropdown data(choiceLables, choiceValues) by invoking a query rule,resetting its 'value' and resetting the rest of the 8 (3,4,5,6,7,8,9,10) dropdowns(choiceLables, choiceValues, and their associated values). If you consider dropdown 2, its saveInto consists of modifying the third dropdown data(choiceLables, choiceValues) by invoking a query rule,resetting its 'value' and resetting the rest of the 7(4,5,6,7,8,9,10) dropdowns (choiceLables, choiceValues, and their associated values) and this goes on and on. Simply speaking at a time, you will invoke only one query as per the scenario you have described. If you take some care while coding, such as avoiding with(), effectively using saveInto so that queries will be made on-demand, getting only two columns(identifiers for choiceValues and text values for choiceLabels) using query entity etc, I think that should be fine.

I might be missing something but above are my thoughts are at the moment on the traditional approach from the performance perspective and let's see what other says about it.

Another approach you can give thoughts about is, build an entity (either a table or view) in the database which consists of all the possible combinations. When it comes to interface, provide the search criteria on the desired columns and get a minimal number of records(maybe 10 or 20 at a time) at a time and query the data afresh only when the user paginates. This also has an upper hand over traditional approach as there is a possibility of exploring many combinations without actually need to working through all the dropdowns in a cascading manner.

If I am not wrong, in your case, it may be more about flexibility rather than performance.