Bloc: Firestore todos example optimistic result

[edmbn]

I have been reading all the examples inside the website (https://bloclibrary.dev) but there is something I don't see so I would like to discuss if it's intended or could be a better solution on the docs.

The Firestore todos example never manages errors for request, add or update todos. Imagine the case, could be very usual, that someone needs a bloc to request for todos information and have different states, for example: requestTodosSuccess, requestTodosInProgress, requestTodosFailure. After todos are retrieved successfuly we would like to add or update them as the Firestore example does. The problem I see is that if we need to add or update this todos and also manage states to handle add/update success or error cases we shouldn't use the same bloc right?

Its very nice to have all this todos logic in a single bloc but in this example error or success states are never handled. So if we need to paint some widgets or show AlertDialogs for example, based on todosRequest or todosUpdate, should we create a different bloc to manage only the add/update todos? or is there a way to have all this logic on a single bloc like the example but being able to identify where the error comes from (request todos or update todos)?

Thank you all for your time.

[narcodico]

Hi @edmbn 👋

It all depends on how your feature should be presented to the user.

If you're adding/updating a todo from a new screen you might very well use a new TodoBloc.

If your executing your operations inline and you want to use the existing bloc then you can have a TodosFailure state that you can use to replace the screen when something goes wrong before todos are loaded and also a failure object on the loaded state for when things go wrong after todos are loaded(since you don't want to replace existing todos once they're loaded just because some error occurred).
When adding/updating a todo you don't really need a success state since firestore will push the updates through your existing subscription. Unless you're planning on showing a success snackbar but that's a different story and you can incorporate it within the loaded state(even on your base state if required) or try and use a separate bloc for this particular situation, both being feasible.

To identify where the error comes from is quite straightforward, you just have to throw specific app exceptions from your repository, e.g.: TodosException or AddTodoException.

Hope this answers couple of questions you have. 👍

[edmbn]

Yes!! But but If I change the state to reflect a possible update todo error I will lose the state loadSuccess that was holding my List of todos. I know I could have a single factory state holding everything but I thing this could get very big and unreadable.

What I still miss in this Firestore todos example is all error handling and its not the same a loadError, updateError... In the example it loads everything and yields a TodosLoaded for every case, but what if an update fails?

I would really like to have everything in a single bloc but I can't see how, because if I loaded all the todos correctly but update todos fails I don't want to change my state to TodosError because my previous todosSuccess was holding the list. All in the same page, while still showing all the todos loaded I want to handle error to be able to show an alertDialog or a Flushbar with update error message.

[narcodico]

Like I mentioned, once todos are loaded, you’d handle errors through a failure property on the loaded state and you’d use this prop to show some error alert dialog.

[edmbn]

I see what you mean but I really don't like the idea of holding errors on a loadSuccess state. It will make the code difficult over time, with some blocs onSuccess state holding data, some blocs onSuccess state holding data and errors. I think the example is great but was thought on a optimistic way. If you want to take care of errors and success for both load todos and update/add todos I think you must create separate blocs, what do you think?

[narcodico]

It’s all about how your features look like and what data needs to be present on screen at all times. Like I said, both approaches are feasible, it’s up to you to decide.

[edmbn]

Yes that's right, we'll thank you so much for discussing this with me. Hopefully it will help others too.