The dark side of allow_duplicates & making callbacks sequential |

Dash Python
,
1

Hello!

I always felt that allow_duplicate was an option to use with some caution. :slight_smile:
But didn’t know how to explain. Today I was inspired from a question on the forum to investigate this further.

In the article, I explore one bad consequence of using allow_duplicates=True, and how to mitigate it.

The article is about callback design, sequential callbacks and a relevant use case of Patch().

I hope it will open the discussion to some callback design strategies.
Let me know what you think about it!

— Fran

2 Likes
2

Hello @spriteware,

I believe that you’ve made a strawman argument by using something like this. It is more efficient to use the values as a state and a submit button. XD

The power of allow_duplicates is allowing the same output to be targeted from different things in the app, things that wouldn’t be entered at the same time or even on the same screen. For example, sending notifications to a single div container from multiple pages or buttons.

Coming from front end, I prefer the granulated control of set_props and allow_duplicates because it gives more targeted control over the elements.

To elaborate, it was quite confusing and ridiculous to have an app that kept growing for inputs and trying to keep the notifications separate when they were all in one callback. Even using pattern-matching it was a beast.

2 Likes
3

The title is maybe exaggerated :grin:

I do agree with you. It’s a very good thing that allow_duplicates exist, for some cases.

However, I think the callback normal behavior (an output updated by only one callback) is a good idea to enforce a good & maintainable logic. Just like circular dependencies, were forbidden at first, and now possible in some ways.
Or “suppress_callback_exceptions”, which is certainly useful but error-prone.

I think it’s something “to use with caution”. Especially for beginners.

Thanks for adding your input, I really appreciate :folded_hands:

4

The article is labeled as experienced though. :winking_face_with_tongue:

It was an interesting take, and I hope there is a sequel of the benefits of allow_duplcate and how to avoid the pitfalls.

5

I created a blog for beginners and end up writing stuff beginners don’t care about :joy:

Joke aside, maybe it could be interesting to write another one to clarify “when to use and when not to use allow_duplicate”.

2 Likes
6

Yes! This would be very helpful :100:

1 Like
7

I second that. When to use and when not to use allow_duplicate would be a good article.

8

For those in the thread, maybe there’s some opportunity here to refine our documentation on duplicate callback outputs (Duplicate Callback Outputs | Dash for Python Documentation | Plotly). I’m happy to provide feedback to the team – we have a few examples of when/why to use duplicate callback outputs but could certainly change or improve them!

1 Like
9

Actually, now that there are so many advanced callbacks, it would be great to have an overview section describing the purpose of the different callbacks and when to use them.

10

Maybe in fact “Advanced callbacks” is a bit of a misnomer and discourages use; many of these patterns are applicable even to “simple” apps. Definitely IA that could be improved.