Investigate debounce time

[louispt1]

We should investigate the debounce time for sending requests to the API. A longer debounce time could improve efficiency by batching multiple changes into a single request, reducing the number of calls made to the Engine. However, this comes at the cost of increased delay for processing single-input updates.

The goal is to find the optimal debounce time that:
1. Reduces excessive API calls when users make multiple updates in quick succession.
2. Minimizes delay to ensure a responsive experience for users who are updating a single input at a time.

Key Questions:
• How frequently are users likely to make quick successive updates, and how quick will they be?
• What is the perceived acceptable delay for users between input and response?

[mabijkerk]

In addition to debounce, we could investigate other options to smoothen the interaction of the user with the interface. Suggestions:

• Adding a "calculate" button, disabling it will allow the user to set sliders with the model running the calculations
• Re-calculations seems to be triggered by new charts (and slider changes of course), though sometimes users only want to set a new slider, without having to see the new slide. Perhaps something smart can be done here

[github-actions]

This issue has had no activity for 60 days and will be closed in 7 days. Removing the "Stale" label or posting a comment will prevent it from being closed automatically. You can also add the "Pinned" label to ensure it isn't marked as stale in the future.

[louispt1]

Note: this is where the updates are debounced in app.coffee

# Set the update in a cancelable action. When you
  # pull a slider A this method is called. It will call doUpdateRequest
  # after 500ms. When a slider is pulled again, that call will be canceled
  # (so that we don't flood the server). doUpdateRequest will get the dirty
  # sliders, reset all dirtyiness and make an API call.
  handleInputElementsUpdate: =>
    func = $.proxy(@doUpdateRequest, this)
    lockable_fn = -> LockableFunction.deferExecutionIfLocked('update', func)
    Util.cancelableAction('update',  lockable_fn, {'sleepTime': 100})

[mabijkerk]

Some ideas I can come up with:

• Switching slides now causes the entire model to reload, including dashboard items. This seems counter-intuitive: the dashboard items should only change when an input is changed. Can we make sure only the chart is actually updated?
• Switching slides seems to causes consecutive requests to load a chart. This seems inefficient: now you first have to wait for chart 1 to load, then the model will reload again to get chart 2. Can we prevent chart 1 from loading and always switch to the latest chart?
• Slider changes should always take precedence over chart loading. If you switch to a slide, change and input, you now first have to wait for the chart to load, only then is the new input request sent it seems. Can we prevent the chart from loading when an input is requested?
• Might be controversial, but the number of charts that we have is not that extensive. Should we fetch charts in the background when the model is otherwise idling? Or would this require to much caching?