[feature request] more flexible expanded_callback

[sdementen]

The expanded_callback is great yet it suffers from some inconveniences:

1. if a single callback is transformed from a standard callback to an expanded_callback, I need to change all the other callback signature to add a **kwargs argument
2. in an expanded_callback, if I only need to get the user or the request, I still need to add a **kwargs to catch all the remaining arguments (that I will not use in the function leading my IDE to show that the kwargs is not used)

I would suggest to remove the frontier between callback and expanded_callback by:

• calling callbacks decorated with app.callback as usual (not injecting the **kwargs) => fix issue 1 above
• kwargs not mandatory in expanded_callback: => fix issue 2 above
  • if kwargs given, then all extra arguments are sent to the callback (as today)
    def my_callback(a,b,c,**kwargs): ==> kwargs receives all the extra arguments
def my_callback(a,b,c, user, **kwargs): ==> user reseive the user, kwargs receives all the remaining extra arguments
  • if one or more extra arguments are given in the callback, then only these are sent
    def my_callback(a,b,c,user, request): ==> only user and request are added by dpd

I have pushed #304 to implement this.

As a 2nd step, I would prefer to explicitly configure the app to use either dash_dispatch (no extra arguments) or direct dispatch (dpd manages dispatch, used for expanded_callbacks), the latter being the default as it provides essential features for Dash in Django.
If direct dispatch, then all callbacks are considered expanded_callbacks and uses the logic above.

The only backward incompatibility would be that the app are per default with "expanded_callbacks" enabled and if the user was previously only using standard callbacks AND used one of the name of the extra arguments in one of its callback (it would raises a TypeError("my_callback() got multiple values for argument 'user'") for instance if he was already naming one of its callback parameter 'user')

[GibbsConsulting]

Thanks for your contribution. This is now part of release v1.6.0

[sdementen]

You're welcome! Thank you for the release.
Btw, for the pattern IDs, there is still the "state saving" for such properties that should be adapted (discovery of property + saving changes).
Would you have some test already in place for the state management sono can built on that?