On a basic display page, I am implementing a modal that triggers an asynchronous backend mutation which will provide updates on the asynchronous operation succeeding via a graphql subscription.
In the page, I was considering defining the model of the modal as InUse InputData | NotInUse, which would be reset to NotInUse when the operation has finished communicating either successful completion or failure after retries. The state seems to span beyond the modal, so do people usually model it by focusing on the operation instead of the modal? For example, is it typically modeled as NotInUse | EnteringData ... | AwaitingResponse ... | ResultReceived?
My 2c: hard to tell what is the best option here from the info provided. Generally speaking if you need more granularity because the UI needs to reflect the, for example, Awaiting response phase you may want to be more specific in your model too.
I’d lean towards the second way you’ve described, modelling the operation. Your problem is similar to the one that the “RemoteData” package is addressing, so you might want to check that out for inspiration: RemoteData - remotedata 6.0.1
The main page has button which opens the modal. Once the dialog opens, it has input box and a button for submitting graphql mutation. Once the mutation is fired, it gets an immediate response from backend that the request was accepted. We close the modal as soon as the request is sent.
The main page has an outcome information alert for the outcome of the asynchronous work triggered by the graphql mutation. After the initial request is accepted, the alert says “your request was submitted”. Later on, a graphql subscription gets updates about the ultimate success or failure of the operation. As those updates come in, the alert communicates the final result.
If someone closes the modal without submission, I discard the input.
I had considered webdata. I am leaning towards something like:
type AsyncWebData = NotRequested | BuildingRequest r | Loading r | RequestReceived r | Failure e r | Success d