-
Notifications
You must be signed in to change notification settings - Fork 127
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Flexible expanded callback #304
Flexible expanded callback #304
Conversation
- no obligation to adapt the signature of a callback when going from app.callback to app.expanded_callback - allow to specify the name of the specific extra parameters needed by the function (no need for **kwargs) to improve readability
@GibbsConsulting I wonder even if, with the introspection of the callback signature, the distinction between expanded_callback and callback is necessary anymore... Maybe a simple option at the DjangoDash(..., use_dash_dispatch=True|False) with a default to False would be cleaner. |
fix #306 |
… does not work with @wraps(...)
@sdementen yes, simplifying the callback/extended_callback approach is a great idea. Thanks for these contributions, most appreciated. |
Would using always the django dispatching be an option? Or do you think it is worth keeping the dash direct dispatch? |
- always use dpd dispatch (remove the _expanded_callbacks variable and expanded_callbacks arguments in __init__, remove use_dash_dispatch()) - refactor the callback inspection logic to get_expanded_arguments and test it explicitly - refactur callback_set to use [] instead of {} as default - expanded_callback = callback - fix bug in handling callback.expanded - update doc
I have integrated the expanded_callback functionality in the standard callback (now both functions are the same). It should be backward compatible with django dash app that are only using the normal arguments |
Other than any backwards compatibility issue, I cant see a reason for keeping the dash direct dispatch option. However, other than a possible extra overhead, which itself could not be large, I am unable to construct an immediate example of something that wouldn't work as a result of this change. |
Just for completeness’ sake, mentioning here #484, which, IIUC, is caused by this. |
allow a more flexible use of expanded_callback: