How to handle async errors in Flux?

Question

I've been working with Flux and I'm really enjoying, but I have one point where I cannot figure what would be the best solution. I made an app that handles a list of orders, and each order in the list is divided in different components that can have read/edit mode (basically changing into a small form) and trigger an update (list of products in the order, shipping costs, etc).

All works fine except for the case where I have to handle exceptions from the server on the order update (e.g. the user changed one of the product quantities but there are not enough in stock, I want the component showing the form for that specific product for that specific order show an inline message, so I have to deliver the error message to a very specific component. The list can have up to 50 orders and each order is composed of 4-5 components that can trigger the update, so I can have around 200 components that could be potentially interested in an ORDER_UPDATE_FAILED action.

The only two options I can think about are:

1. Make the component call the API update synchronously so it can retrieve the error if it happened (the updated order would be sent as payload of an ORDER_UPDATED action and keep its flow through normal Flux flow: dispatcher, store, trigger update). But I know this breaks a bit the Flux philosophy

2. Make the update asynchronously and create an ORDER_UPDATE_FAILED, and the Store having the logic to put transform in the error in an object that can be identified by an Order Part Component (thinking about orderID + errorID). This would keep the unidirectional cycle of the data and the asynchrony of the actions but it feels too complex and cumbersome and adds some more issues:

   a) If the error is stored in the Store, the component has to notify the store when the error is no longer valid, which may not be able to do always).

   b) If the user clicks on save without changing a value and the component becomes in "loading state", even if the call is successfull the order stays the same, so no rerender to get out of the "loading state".

Has anyone found a more elegant way to solve this issue?

Answer 1

I think option 1 makes sense and is easier to manage as long as the error is only relevant within the scope of that component. I've been using this approach to display errors on form submission for things like user registration, where I know the only place I'll need the error message is directly on the form ("that username is already taken"). I look at this kind of error message as part of the form/component itself, more local state than application state. This sounds a lot like your situation, so I would say this is the better option.

Option 2 would be more robust to the possibility that the error might become relevant in more than one place in the future. But if you're confident that this is unlikely to happen, I don't see an advantage to the increased complexity compared to option 1.