Middleware that acts as NavigatorObserver

[brianegan]

Middleware that acts as NavigatorObserver

[brianegan]

Kent! Stop finding all the tough edge cases!!! :P Jokes, of course, really interesting problem, thanks for writing in :)

I'll be honest, even though you've provided a really good description, I feel like I don't have enough of a handle on your problem to give you solid advice because it's a tricky one with Edge cases I probably don't understand. But let me try...

The hard part was figuring out where to dispatch these actions and finding a way to somewhat guarantee that transactions will remain balanced. Initially, I just sprinkled them through my views. It worked, but was terrible and I'm pretty sure there were some edge cases that I'd missed.

Since the above does look complex, and I could also see edge cases creeping in, could you test your views to ensure they're firing the right actions at the right times?

Or could you perhaps elaborate on why it was terrible? I'd be interested in hearing the problems it created.

Since it seems starting / stopping these actions is related to showing / hiding Widgets, that still feels like the cleanest way given my limited knowledge.

[kentcb]

Haha! I'm very grateful that I have you to bounce ideas and questions off, Brian. Feeling a bit lonely as the only flutter/redux/Dart dev at my company...

Perhaps this diagram I whipped up provides a better visualization for my scenario:

So you can see that items consist of sub-items. Users can add or edit items, and add or edit sub-items within those items. At any point in the process, they could bail out by hitting the back button, and what that does is contingent upon where they are in the process. Moreover, because the data has multiple levels to it (items and sub-items), I can simply take a single snapshot. Otherwise, a user might start editing an item, start editing a sub-item within that item, then bail out on editing that sub-item. Doing so should roll back only the sub-item changes, not the entire item.

Anyway, the point is that whilst I have all this working, it's a bit icky to me. Also, not evident from the above diagram (it was getting too busy!) is the fact that items (and sub-items) can also be deleted via a swipe gesture. When this happens, a transaction is started, the (sub)item is deleted, and a snackbar is shown with an UNDO action. If the user hits UNDO, the transaction is rolled back. If the snackbar is dismissed for any other reason, the transaction is committed. Alas, I had to drive this part of the process from the UI rather than middleware, since I simply couldn't find a sane way to do otherwise.

Not sure if I've made things clearer here or worse 🙃 No real expectations for an answer or anything. I guess I just wondered whether I might be overlooking some simpler way of achieving this and having the code for it all in one spot as middleware.

[brianegan]

Heya @kentcb -- even with the detailed breakdown, still not quite sure I could come up with a good solution without sitting down with ya for a bit and hacking away at it! I can't think of anything obvious, as it does seem like there's some tricky logic in there and it would be tough to give an obvious solution without working through all the corner cases :)

[kentcb]

Yep, totally understand @brianegan. Thanks for having a look anyway. I'm more or less happy with how my code is functioning - I'm just not certain it's the best design. I've chalked it up as potential tech debt and moved on.