add extra wait for callbacks in queue

[byronz]

after the discussion with @alexcjohnson about the incident of dash-daq PR on dash docs, this PR adds one extra wait in visit_and_snapshot API to make sure all the callbacks in the queue get fired. tested with the local snapshots and also dash-docs tests, the results are positive.

https://percy.io/plotly/dash-docs/builds/2904660
https://percy.io/plotly/dash/builds/2904645

[alexcjohnson]

FYI the PR that sparked this push for more robust percy snapshots is https://github.com/plotly/dash-docs/pull/676

This strategy looks great - I didn't know about self.redux_state_rqs, that's really nice to have!

Just the one comment above, then I think this will be good to go.

BTW I had to approve one spurious percy diff here that seems to be frequently changing, chapter-1-again (I've also seen chapter-1 fail similarly). I think it's somehow autosizing the graph differently in different runs? If that's it, we can 🔒 it by changing this line:

dash/tests/integration/callbacks/test_layout_paths_with_callbacks.py

Line 125 in c4db2ef

"layout": {"title": value},

to have fixed height & width like:

"layout": {"title": value, "width": 500, "height": 400}

[byronz]

This strategy looks great - I didn't know about self.redux_state_rqs, that's really nice to have!

it's in the dash_page.py which is not documented, we should add a section for that part later

[alexcjohnson]

Oh actually, one more concern: what if some existing cases are snapshotting pages that don't even have callbacks? I guess we could look at store.getState().dependenciesRequest.content.length - if that's 0, don't wait for anything to show up in requestQueue?

[byronz]

Oh actually, one more concern: what if some existing cases are snapshotting pages that don't even have callbacks? I guess we could look at store.getState().dependenciesRequest.content.length - if that's 0, don't wait for anything to show up in requestQueue?

In the context of dash docs (where we use mostly this API) there is always at least one request like the home page.

In the context of an app, you are right that no callback, no requestqueue, but I'm also wondering the purpose of using this API in this case. isn't a simple percy_snapshot more straightforward?

[alexcjohnson]

isn't a simple percy_snapshot more straightforward?

Oh... right, I forgot about the visit_and_snapshot vs percy_snapshot distinction - in fact if it were robust (against not even being a dash page, for example what if you get a wekzeug debug page) I could see this being part of percy_snapshot - perhaps with the ability to turn it off in case you actually want to run ahead of a response for some reason.

[byronz]

isn't a simple percy_snapshot more straightforward?

Oh... right, I forgot about the visit_and_snapshot vs percy_snapshot distinction - in fact if it were robust (against not even being a dash page, for example what if you get a wekzeug debug page) I could see this being part of percy_snapshot - perhaps with the ability to turn it off in case you actually want to run ahead of a response for some reason.

we don't have window.store outside the scope of dash apps. :)

[alexcjohnson]

Love it, wait_for_callbacks is easy, clear, and explicit.
Add a CHANGELOG entry, then 💃