What is a good way to handle callback with long list of multi-layer inputs

Dash Python
1

Hi Dash Community:

I have been struggling on the question below for a while, can you please take a look?

Suppose the users want to choose a regression type as below:
image

After each choice, I give additional parameters given a regression type:
OLS regression: start_date, end_date
Lasso regression: start_date, end_date, regulation parameter
Logit regression: start_date, end_date, response type

Given this two layer of choices, I will simply generate a graph. Disregard the details, you can see, I am trying to compute an output given 8 inputs.

There are several approaches:

  • I can write if-else switch statements to handle the 8 inputs, by determining which regression type triggered the callback. However, as you can see, this is almost unlikely work if, say, I add another 10 regression types.
  • I can also leverage this: Duplicate Callback Outputs | Dash for Python Documentation | Plotly, which seems fine but with some caveats ( for instance, the order is not determined ).
  • I can also introduce a store component that stores the second layer of choices (as a dictionary ), but this wouldn’t have fundamental differences.

Is there a better way to handle situation like this? Thank you so much.

2

Hello @entropy_l,

What you could do is put them into a table and loop through the rows.

If the row has a value, then you make the regression adjustments to your output, if not, it passes without doing anything.

Also, for the regressions, you can make a dictionary with the functions that you want to happen to the dataset or whatever. This way, the actual callback would be relatively small.

Id actually use AG grid, because you could allow the person to drag the rows into a different order, if this even mattered. But you could also have a hidden column with the regression type to make it even easier to parse out.

1 Like
3

I think the simplest approach would be to,

  1. Create a drop down to identify the model of choice
  2. Create components for all possible model options, setting them all initially hidden
  3. Add a callback to set visibility of relevant options based on the model choice
  4. Add a callback with the model choice + all options as inputs (or state, and a “run” button as input, if you don’t want instant updates)
1 Like
4

Thank you so much @Emil and @jinnyzor. Currently, I am indeed using the method mentioned above.

  • Have a dropdown of first step model choice
  • Once the choice is given, I return a “children” of components to take inputs of parameters as a list.

Now, the problem is really here: 1. Add a callback with the model choice + all options as inputs (or state, and a “run” button as input, if you don’t want instant updates)

Unless I implement as a way to allow duplicate output ( which is fine. ), the callback inputs list will be long, as it will take: model choices an inputs for each model choices. As the list of models grows, it cannot be handled. ( for instance, taking to the extreme, say, I have 100 models and each have 3-5 parameters )
I have tried several ways, including using “Store”. However, it cannot avoid to have callback inputs to grow. The only way seems working is using duplicate callback outputs.
Happy to hear more of your thinking and thanks both!

5

I think a table would allow you to have the different options without the need to do all of those things. Unless you went with pattern-matching of course.

But with a table you’d have the flexibility of the person selects what they want to run and you could have the other parameters listed out into columns ( potentially).

1 Like
6

Thanks @jinnyzor. I agree with you. Never thought about implement it similar to excel table but what you said ignites me. I was just thinking how to do that in Ag Grid.

In this case, Pattern matching won’t help, right? As the parameters of each model ( imagine its a dictionary ), won’t have the same key, and each model can have different number of parameters.

Thank you.

7

Yes, you could do that.

The issue I think you’ll run into is how to give the different parameters to be populated.

You can either display them in columns 1-5 or something. Or, upon selection, a modal pops up and they fill in the data, which is stored in the rowData, but you can’t see it.

You could also use a dictionary with keys based upon the selected option which then takes the arguments and calls the specific function. Which you could just pass the selected row to the function and get your output.

Pattern-matching could work, but you’d probably end up with something similar to the columns that are unassigned/assigned only by position.

1 Like
8

Thanks.
I just started to implement above with the Ag Grid. I will post if it turns out to be good. Thank you!

1 Like
9

So I tried to refactor my code — effectively, wrap up the second layer of inputs to Ag Dash grid.
Although haven’t finished all, I think this is the best solution so far:

  • One thing I want to get from the dash component such as selection, is to constraint the parameters. It looks like AgGrid has a lot of features through the CellEditors to achieve the same & also have the dropdown which is very similar to regular components.
  • This is better than the dcc.store approach with duplicate callback outputs, as the duplicate callbacks don’t control for orders.

One thing I asked in a different thread is that the aggrid table is not persistent. However, I think this is fine and there is a workaround available.