I'm not exactly happy with this—but it does solve the UX problem. Its a one-off. We experience this problem...basically everywhere except moving elements, or creation/deletion on the modeling page.
Let's describe the problem:
Most of the stores are re-built per change set
We push to a new URL in the router that redraws the page
Which means components get re-mounted, which means the code that fired the request is not listening for the response
This solution:
Composes a function and sticks it on the change set store, which doesn't get destroyed
Even though the components get destroyed
And the middleware listener fires a function in that spot on the change set store, if it exists
Further annoyances:
the middleware doesn't have our ApiRequest type, just the bare AxiosResponse, so all the work we have done in typing is useless here.
any given operation we would do here is a subset of the onSuccess function. Basically, nav/selection changes but no data manipulation, because swapping to the new change set will pick up the new data for us.
I'm sure we can move the logic of the handler into the ApiRequest object. But... I'm not exactly sure how to resolve No2 cleanly (e.g. without having to go add code to every ApiRequest we care about... but maybe thats not horrible???)
I'm not exactly happy with this—but it does solve the UX problem. Its a one-off. We experience this problem...basically everywhere except moving elements, or creation/deletion on the modeling page.
Let's describe the problem:
This solution:
Further annoyances:
onSuccessfunction. Basically, nav/selection changes but no data manipulation, because swapping to the new change set will pick up the new data for us.I'm sure we can move the logic of the handler into the ApiRequest object. But... I'm not exactly sure how to resolve No2 cleanly (e.g. without having to go add code to every ApiRequest we care about... but maybe thats not horrible???)