The last refresh snackbar is hiding the Personal Search button for a few seconds

[teolemon]

What

• The last refresh snackbar is hiding the Personal Search button for a few seconds
• Can we make them aware of each other ?

Part of

• 🔍 Search (tracker) #991

Screenshot/Mockup/Before-After

[stephanegigandet]

Why don't we automatically trigger the refresh (while still showing the cached results in the mean time) instead of showing a message?

[monsieurtanuki]

@teolemon I guess that a floating action button is supposed to work correctly with a snackbar, so using a FAB would be the solution.

@stephanegigandet This is not my cup of tea to systematically refresh data as I live in the energy save mode (apps and IRW). But that's not the first time we talk (and disagree) about that, so let's go forward!
Assuming that your suggestion is coded, I cannot fully picture how this would work:

1. obviously, like now, we check if we've got a version of the data in the database
2. if so, we display the version of the data from the database
3. and in the current version of the app, we display the snackbar, with the possibility to have the data refreshed from the back-end

We could imagine displaying the database data while downloading fresher data. My questions are:

1. assuming that the user stays on the personal search result page, how are we supposed to display the fresher data? Without explanation (which can be strange for the end user if data suddenly changes)? With a snackbar saying "btw we've just refreshed the data"? (possibly with a "don't show this message again" checkbox)
2. if the end user changed the page (e.g. went to a product page) and then goes back to just refreshed data, we should probably display again a warning
3. that would probably make sense to set a minimum duration between refresh

[stephanegigandet]

@monsieurtanuki All very good questions indeed. I can't think of very good answers for them, so let's keep the current behaviour.

[monsieurtanuki]

Let's focus on the OP: a floating action button that unfortunately doesn't move when there's a snackbar (in ProductQueryPage), but that should actually move according to the standard behavior.

Probable reasons:

• the floating action button is not a FloatingActionButton but an embedded FloatingActionButton - and maybe looses some of its superpowers
• the snackbar is displayed too early - or let's say not in the correct timing - compared to the FloatingActionButton display

[monsieurtanuki]

I've run some tests, and what I've found is that the problem probably lies in the multi-tabs system, where there is one main Scaffold and 3 "parallel" nested Scaffolds. The SnackBar / FloatingActionButton interaction is lost with those multiple Scaffolds. With just a single Scaffold, that works ok.

From https://stackoverflow.com/questions/60561552/multiple-scaffolds-for-each-page-inside-a-flutter-app:

It means that, usually, there should be one Scaffold for each page (more precisely, for each Route/screen), and that you should not nest Scaffolds.

I don't remember who coded the tabs navigation (maybe @M123-dev), but it looks like there is this side-effect regarding the SnackBar / FloatingActionButton interaction.

[monsieurtanuki]

That said, I've just found a fix for the snackbar / FAB interaction. About to PR...
Assuming that this is the only side-effect we will experience, we can survive with nested Scaffolds.