:wave::skin-tone-3: Is there any example/code I c...
# orbit-mvi
l
👋🏼 Is there any example/code I can take a look at about
snackbars
and stacking them? Showing multiple snackbars in sequence, perhaps with different layout/color/text on them, actionable buttons, etc (the more complex the examples are, the better)
👀 2
v
Please bear with my curiosity... is this something to be done at the UI side and not with orbit/view-model? Can you add a bit more context on what exactly we are planning to do here 🤔
l
No, I want to check how sending multiple events on the
sideEffect
which stacks (so the snackbar is not dismissed before another one is sent) works
b
I might be a bit late, but Google doesn't recommend the "side effect" pattern, instead in your case they'd recommend keeping a list of snack bars to show in your State and have the UI notify your the VM whenever one is displayed so it can be removed from the list
l
You’re not late! Appreciate the support, would you be able to provide a link to Google’s resource pointing this out?
However this pattern if not careful would convert Snackbars to Toasts i.e being present in the wrong screen, wrong time blob stuck out tongue So you might have to clear any existing snackbars before navigating to the next screen.
@Benoît I do agree with you on the Google against "side-effect" pattern thingy. But in this case I think they did it just to manage Snackbar processing at one place -- the root scaffold, and any of the child screens can shoot a Snackbar without any extra boilerplate. Feel free to correct me, If I'm wrong.
b
@Luca Nicoletti I think it was in that video

https://www.youtube.com/watch?v=CQzuFZjiUMs

Not sure though
@Vishnu Ravi I think the reason they don't recommend using side effects if because the UI has no choice but to receive them all at once, and they can build up while the UI isn't visible. Also, the business logic has no way of knowing that the UI actually received a side-effect, which can be an issue
v
Okay... Got it 👍
One quick check, the Orbit docs say... "Side effects are cached if there are no observers, guaranteeing critical events such as navigation are delivered after re-subscription" Would this solve the above problem?
b
The fact that they're cached is also an issue, for example you might receive multiple snack bar effects at once, in which case you probably want them to be shown one after the other but with the side effect being sent as a Flow, you'll essentially show everything at once, or within a few milliseconds of each other. Ideally you'd want a buffer, which would be in your state if you don't use side effects There are ways around it, but it's just simpler not to use side effects and put everything in the state. I personally use them, but I understand why Google doesn't recommend them
v
I do agree with your points and the fact that we might need a buffer in these cases.
...but it's just simpler not to use side effects and put everything in the state
This is where I feel like something is off. For instance, in a large application with navigation that involves a backstack. Every time I receive a one-off event, after consuming these... and just before navigating to the next screen, I have to constantly remind myself to do the following 1. Clear my buffers (or mark the entries as consumed as and when it happens) 2. Mark any navigation events as consumed. 3. Reset other parameters that may repeat any strict one-off events.
I personally use them, but I understand why Google doesn't recommend them
Same here. Appreciate that you shared your thoughts here 🙏 PS: Here's a relevant thread in the pinned message section, for those who are reading through this and trying to grab some context.
I just found out that there is an official recommendation to handle navigation (with backstack) without using any 'side-effect' 😌. There's additional work to be done on the UI, to handle my previous concerns... but it does makes sense and better than using a disposable effect. @Luca Nicoletti Sorry for hijacking your post. Thought it would be worth discussing this here since we were talking about side-effects.